見字如面,我是威哥,一個從普通二本院校畢業,從未曾接觸分布式、微服務、高并發到通過技術分享實現職場蛻變，成長為RocketMQ社區優秀布道師、大廠資深架構師，出版《RocketMQ技術內幕》一書，歡迎大家關注我，一起交流進步。
JAVA并發編程是大廠第一輪面試中的高頻面試題，而線程池又是其中的典型代表，本文將梳理關于線程池的工作機制，并提出靈魂之問：你對線程池的工作機制這么了解，那你在工作中是如何判斷一個線程池需要創建多少個線程的呢？
1、線程池基本工作原理與面試指南
1.1 java線程池的核心屬性
JAVA 線程池的核心屬性如下：
- int corePoolSize
核心線程數 - int maximumPoolSize
線程池最大線程數 - long keepAliveTime
線程保持活躍的時間 - TimeUnit unit
keepAliveTime 的時間單位 - BlockingQueue< Runnable > workQueue
任務擠壓隊列 - ThreadFactory threadFactory
線程創建工廠類 - RejectedExecutionHandler handler
拒絕策略
1.2 向線程池提交任務時線程創建過程
那當用戶向線程池提交一個任務的時候，線程池會如何創建線程呢？
- 首先線程池會判斷當前已創建的線程是否小于 corePoolSize (核心線程數)，如果小于，則無論已創建的線程是否空閑，都會選擇創建一個新的線程來執行該任務，直到已創建的線程等于核心線程數。
- 當線程池中已創建的線程數等于核心核心線程數時，用戶繼續向線程池提交任務時，此時會先判斷任務隊列是否已滿：
1）如果任務隊列未滿，則將任務放入隊列中。2）如果任務隊列已滿，則判斷當前線程數量是否超過了最大線程數量，如果未超過，則創建一個新的線程來執行該任務，如果線程池已創建的線程數量等最大線程數，則執行拒絕策略。
溫馨提示：所以如果線程池使用的隊列無界隊列，最大線程數會變得沒有意義。
1.3 線程池的拒絕策略、使用場景
JUC 默認提供了如下拒絕策略：
- AbortPolicy
拒絕，直接拋出 RejectedExecutionException，默認值。 - CallerRunsPolicy
由調用線程直接運行任務的 run 方法，即異步轉同步。 - DiscardOldestPolicy
丟棄任務隊列中最先進入的任務。 - DiscardPolicy
拒絕了，就不執行，“當沒事人事”樣。
拒絕策略觸發的條件：線程池使用的是有界任務隊列時，才有可能被觸發，當隊列已滿，并且線程池創建的線程已經達到了最大允許的線程池時。
默認情況下，通常使用 AbortPolicy 即可。
CallerRunsPolicy 異步轉同步在出現拒絕的情況下其實意義不大，沒有想出其合適的場景，因為需要執行拒絕策略的時候，已經處理變慢了，再同步執行任務，只會增加服務器的負載，不利于恢復問題。
DiscardOldestPolicy 這種策略，通常用于類似記錄軌跡，偶爾丟失點數據沒關系，但希望最新的數據能得到保存。
DiscardPolicy 策略，通常用來異步打印日志，直接忽略不執行，期望保存舊的數據。
1.4 如何選擇阻塞隊列
阿里內部的開源規范明確禁止使用無界隊列，如果使用無界隊列，任務會不受限制的往線程池中提交，有可能造成內存溢出。
如果使用無界隊列，最大線程數這個參數將會失效，因為永遠也不會創建多于核心線程數量的線程。
1.5 線程池工廠有何實際用處
ThreadFactory threadFactory，線程池工廠，在使用線程池時，強烈推薦使用自己定義的線程工廠，這樣能為線程池中的線程進行命名，方便跟大家使用 jsatck 命令查看線程棧時，能快速識別對應的線程。
1.6 keepAliveTime參數的作用
keepAliveTime ：通俗點來說，這個參數表示線程的最大空閑時間，即如果線程沒有在執行任務，能存活的時間。
默認情況下，該參數只針對超過核心線程數(corePoolSize) 的線程,可通過將allowCoreThreadTimeOut設置為true，則核心線程數也會因為空閑而被關閉。
２、如何為一個線程池設置合適的線程數量
目前根據我看過的一些開源框架，設置多少個線程數量通常是根據應用的類型：IO密集型、CPU密集型。
- IO密集型通常設置為2n+1，其中n為CPU核數
- CPU密集型通常設置為 n+1。
實際情況往往復雜得多，并不會按照這個進行設置，上面的公司通常適合框架設置IO線程的個數，例如netty,dubbo這種底層通訊框架通常會參考上述標準進行設置。
關于在實際業務開發中，如何為一個線程池設置合適的線程呢？
其實對于IO密集型類型的應用，網上還有一個公式：線程數 = CPU核心數/(1-阻塞系數)
引入了阻塞系數的概念，一般為0.8~0.9之間，
在我們的業務開發中，基本上都是IO密集型，因為往往都會去操作數據庫，訪問redis，es等存儲型組件，都會涉及到磁盤IO，網絡IO。
那什么場景下是CPU密集型呢？純計算類，例如計算圓周率的位數，當然我們基本接觸不到。
IO密集型，可以考慮多設置一些線程，主要目的是可以增加IO的并發度，CPU密集型不宜設置過多線程，因為是會造成線程切換，反而損耗性能。
接下來我們以一個實際的場景來說明如何設置線程數量。
一個4C8G的機器上部署了一個MQ消費者，在RocketMQ的實現中，消費端也是用一個線程池來消費線程的，那這個線程數要怎么設置呢？
如果按照 2n + 1 的公式，線程數設置為 9個，但在我們實踐過程中發現如果增大線程數量，會顯著提高消息的處理能力，說明 2n + 1 對于業務場景來說，并不太合適。
如果套用 線程數 = CPU核心數/(1-阻塞系數) 阻塞系數取 0.8 ，線程數為 20 。阻塞系數取 0.9，大概線程數40，20個線程數我覺得可以。
如果我們發現數據庫的操作耗時比較多，此時可以繼續提高阻塞系數，從而增大線程數量。
那我們怎么判斷需要增加更多線程呢？可以用jstack命令查看一下進程的線程棧，如果發現線程池中大部分線程都處于等待獲取任務，則說明線程夠用，如下圖所示：
如果大部分線程都處于運行狀態，可以繼續適當調高線程數量。
本期就介紹到這里了，希望對你有所幫助，同時也希望一鍵三連，給作者一些鼓勵。
分享筆者關于RocketMQ線上故障案例剖析的電子書，私信回復RMQPDF即可獲取。
