一、序
我們今天就來借這個問題，聊聊線程池中維護的線程，它增長和回收的策略是什麼樣的？
二、線程池的策略
2.1 線程池的各項參數
當我們聊到線程池中線程的增長策略的時候，最抓眼球的就是它的核心線程數（corePoolSize）和最大線程數（maximumPoolSize），但是僅看這兩個參數是不夠全面的，線程數量的增長，還與任務等待隊列有關係。
我們先來看看 ThreadPoolExecutor 最全參數的構造方法：
簡單解釋一下各個參數是什麼意思：
- corePoolSize：核心線程數；
- maximumPoolSize：線程池的最大線程數；
- keepAliveTime：核心線程數之外的線程，最大空閒存活的時長；
- unit：keepAliveTime 的時間單位；
- workQueue：線程池的任務等待隊列；
- threadFractory：線程工廠，用來為線程池創建線程；
- handler：拒絕策略，當線程池無法處理任務時的拒絕方式；
這其中很多參數的配置，都是相互影響的。例如任務等待隊列 workQueue 配置不當，可能導致線程池中的線程，永遠無法增長到核心線程數（maximumPoolSize）配置的線程數。
2.2 線程池中線程的增長策略
看到這裡你應該就清楚了，線程池線程的增長策略，和 3 個參數有關係：
- corePoolSize：核心線程數
- maximumPoolSize：最大線程數；
- workQueue：等待任務隊列；
它們之前的關係是這樣的：
接下來我們看看理想情況下，線程池中線程的增長策略。
默認情況下，初始時線程池是空的，當有新任務來了時，線程池開始通過線程工廠（threadFractory）創建線程來處理任務。
新的任務會不斷的觸發線程池中線程的創建，直到線程數量達到核心線程數（corePoolSize），接下來會停止線程的創建，而是將這個新任務放入任務等待隊列（workQueue）。
新任務不斷進入任務等待隊列，當該隊列滿了時，開始重新創建線程處理任務，直到線程池中線程的數量，到達 maximumPoolSize 配置的數量。
到這一步時，線程池的線程數達到最大值，並且沒有空閒的線程，任務隊列也存滿了任務，這時如果還有新的任務進來，就會觸發線程池的拒絕策略（handler），如果沒有配置拒絕策略就會拋出 RejectedExecutionException 異常。
到這裡線程的增長策略就說清楚了，我們可以通過下圖來了解完整的流程。
其中比較關鍵的就是任務的等待隊列，無論等待隊列的實現結構是什麼樣的，只有在它滿的時候，線程池中的線程才會向最大線程數增長。但是一個能夠滿的隊列，它的前提是必須是一個有界隊列。
這就是文章開頭舉的例子暗藏的坑，我們回顧一下前面構造的線程池。
可以看到，這裡雖然最大線程數是大於核心線程數的，但是它的等待隊列配置的是一個 LinkedBlockingQueue，從名字上可以看出這是一個基於鏈表實現的阻塞隊列，而用它的默認構造方法構造時，其容量設定為 Integer.MAX_VALUE，可以簡單理解它是一個無界隊列。
這也就是為什麼說，這樣構造的線程池，核心線程數的配置參數，永遠都用不到，因為它的等待隊列永遠沒有滿的時候。
2.3 線程池中線程的收縮策略
線程池中執行的任務，總有執行結束的時候。那麼線程池當線程池中存在大量空閒線程時，也會有一定的收縮策略，來回收線程池中多餘的線程。
線程池中線程的收縮策略，和以下幾個參數相關：
- corePoolSize：核心線程數；
- maximumPoolSize：線程池的最大線程數；
- keepAliveTime：核心線程數之外的線程，空閒存活的時長；
- unit：keepAliveTime 的時間單位；
corePoolSize 和 maximumPoolSize 我們比較熟悉了，另外能夠控制它的就是 keepAliveTime 空閒存活時長，以及這個時長的單位。
當線程池中的線程數，超過核心線程數時。此時如果任務量下降，肯定會出現有一些線程處於無任務執行的空閒狀態。那麼如果這個線程的空閒時間超過了 keepAliveTime&unit 配置的時長後，就會被回收。
需要注意的是，對於線程池來說，它只負責管理線程，對於創建的線程是不區分所謂的「核心線程」和「非核心線程」的，它只對線程池中的線程總數進行管理，當回收的線程數達到 corePoolSize 時，回收的過程就會停止。
對於線程池的核心線程數中的線程，也有回收的辦法，可以通過 allowCoreThreadTimeOut(true) 方法設置，在核心線程空閒的時候，一旦超過 keepAliveTime&unit 配置的時間，也將其回收掉。
allowCoreThreadTimeOut() 能被設置的前提是 keepAliveTime 不能為 0。
2.3 查缺補漏
1. 等待隊列還會影響拒絕策略
等待隊列如果配置成了無界隊列，不光影響線程數量從核心線程數向最大線程數的增長，還會導致配置的拒絕策略永遠得不到執行。
因為只有在線程池中的工作線程數量已經達到核心線程數，並且此時等待隊列也滿了的情況下，拒絕策略才能生效。
2. 核心線程數可以被「預熱」
前面提到默認的情況下，線程池中的線程是根據任務來增長的。但如果有需要，我們也可以提前準備好線程池的核心線程，來應對突然的高併發任務，例如在搶購系統中就經常有這樣的需要。
此時就可以利用 prestartCoreThread() 或者 prestartAllCoreThreads() 來提前創建核心線程，這種方式被我們稱為「預熱」。
3. 對於需要無界隊列的場景，怎麼辦？
需求是多變的，我們肯定會碰到需要使用無界隊列的場景，那麼這種場景下配置的 maximumPoolSize 就是無效的。
此時就可以參考 Executors 中 newFixedThreadPool() 創建線程池的過程，將 corePoolSize 和 maximumPoolSize 保持一致即可。
此時核心線程數就是最大線程數，只有增長到這個數量才會將任務放入等待隊列，來保證我們配置的線程數量都得到了使用。
4. 線程池是公平的嗎？
所謂的公平，就是先到的任務會被先執行。這在線程池中，顯然是不公平的。
不提線程池中線程執行任務是通過系統去調度的，這一點就決定了任務的執行順序是無法保證的，這就是是非公平的。另外只從線程池本身的角度來看，我們只看提交的任務順序來看，它也是非公平的。
首先前面到的任務，如果線程池的核心線程已經分配出去了，此時這個任務就會進入任務隊列，那麼如果任務隊列滿了之後，新到的任務會直接由線程池新創建線程去處理，直到線程數達到最大線程數。
那麼此時，任務隊列中的任務，雖然先添加進線程池等待處理，但是這些任務的處理時機，是晚於後續新創建線程去處理的任務的，所以說僅從任務的角度，依然是非公平的。
三、小結時刻
本文我們聊到了線程池中，對於線程數量的增長和收縮策略。
在這裡我們簡單總結一下：
1. 增長策略。默認情況下，線程池是根據任務先創建足夠核心線程數的線程去執行任務，當核心線程滿了時將任務放入等待隊列。待隊列滿了的時候，繼續創建新線程執行任務直到到達最大線程數停止。再有新任務的話，那就只能執行拒絕策略或是拋出異常。
2. 收縮策略。當線程池線程數量大於核心線程數 && 當前有空閒線程 && 空閒線程的空閒時間大於 keepAliveTime 時，會對該空閒線程進行回收，直到線程數量等於核心線程數為止。
總之要謹記，慎用無界隊列。
最後，本文對你有幫助嗎？留言、轉發、點贊是最大的支持，謝謝！
在頭條號私信我。我會送你一些我整理的學習資料，包含：Android反編譯、算法、設計模式、虛擬機、Linux、Kotlin、Python、爬蟲、Web項目源碼。
閱讀更多 承香墨影 的文章
