一、序

 

 

public static ExecutorService newThreadPool() { return new ThreadPoolExecutor( 30, 60, 60L, TimeUnit.MILLISECONDS, new LinkedBlockingQueue());}

 

 

 

 

我們今天就來借這個問題，聊聊線程池中維護的線程，它增長和回收的策略是什么樣的?

二、線程池的策略

2.1 線程池的各項參數

當我們聊到線程池中線程的增長策略的時候，最抓眼球的就是它的核心線程數(corePoolSize)和最大線程數(maximumPoolSize)，但是僅看這兩個參數是不夠全面的，線程數量的增長，還與任務等待隊列有關系。

我們先來看看 ThreadPoolExecutor 最全參數的構造方法：

public ThreadPoolExecutor( 
  int corePoolSize, 
  int maximumPoolSize, 
  long keepAliveTime, 
  TimeUnit unit, 
  BlockingQueue<Runnable> workQueue, 
  ThreadFactory threadFactory, 
  RejectedExecutionHandler handler) { 
  // ... 
} 

簡單解釋一下各個參數是什么意思：

• corePoolSize：核心線程數;
• maximumPoolSize：線程池的最大線程數;
• keepAliveTime：核心線程數之外的線程，最大空閑存活的時長;
• unit：keepAliveTime 的時間單位;
• workQueue：線程池的任務等待隊列;
• threadFractory：線程工廠，用來為線程池創建線程;
• handler：拒絕策略，當線程池無法處理任務時的拒絕方式;

這其中很多參數的配置，都是相互影響的。例如任務等待隊列 workQueue 配置不當，可能導致線程池中的線程，永遠無法增長到核心線程數(maximumPoolSize)配置的線程數。

2.2 線程池中線程的增長策略

看到這里你應該就清楚了，線程池線程的增長策略，和 3 個參數有關系：

• corePoolSize：核心線程數
• maximumPoolSize：最大線程數;
• workQueue：等待任務隊列;

它們之前的關系是這樣的：

 

 

 

 

接下來我們看看理想情況下，線程池中線程的增長策略。

默認情況下，初始時線程池是空的，當有新任務來了時，線程池開始通過線程工廠(threadFractory)創建線程來處理任務。

新的任務會不斷的觸發線程池中線程的創建，直到線程數量達到核心線程數(corePoolSize)，接下來會停止線程的創建，而是將這個新任務放入任務等待隊列(workQueue)。

新任務不斷進入任務等待隊列，當該隊列滿了時，開始重新創建線程處理任務，直到線程池中線程的數量，到達 maximumPoolSize 配置的數量。

到這一步時，線程池的線程數達到最大值，并且沒有空閑的線程，任務隊列也存滿了任務，這時如果還有新的任務進來，就會觸發線程池的拒絕策略(handler)，如果沒有配置拒絕策略就會拋出 RejectedExecutionException 異常。

到這里線程的增長策略就說清楚了，我們可以通過下圖來了解完整的流程。

 

 

 

 

其中比較關鍵的就是任務的等待隊列，無論等待隊列的實現結構是什么樣的，只有在它滿的時候，線程池中的線程才會向最大線程數增長。但是一個能夠滿的隊列，它的前提是必須是一個有界隊列。

這就是文章開頭舉的例子暗藏的坑，我們回顧一下前面構造的線程池。

public static ExecutorService newThreadPool() { 
  return new ThreadPoolExecutor( 
    30, 60, 
    60L, TimeUnit.MILLISECONDS, 
    new LinkedBlockingQueue<Runnable>()); 
} 

可以看到，這里雖然最大線程數是大于核心線程數的，但是它的等待隊列配置的是一個 LinkedBlockingQueue，從名字上可以看出這是一個基于鏈表實現的阻塞隊列，而用它的默認構造方法構造時，其容量設定為 Integer.MAX_VALUE，可以簡單理解它是一個無界隊列。

public LinkedBlockingQueue() { 
  this(Integer.MAX_VALUE); 
} 
 
public LinkedBlockingQueue(int capacity) { 
  if (capacity <= 0) throw new IllegalArgumentException(); 
  this.capacity = capacity; 
  last = head = new Node<E>(null); 
} 

這也就是為什么說，這樣構造的線程池，核心線程數的配置參數，永遠都用不到，因為它的等待隊列永遠沒有滿的時候。

2.3 線程池中線程的收縮策略

線程池中執行的任務，總有執行結束的時候。那么線程池當線程池中存在大量空閑線程時，也會有一定的收縮策略，來回收線程池中多余的線程。

線程池中線程的收縮策略，和以下幾個參數相關：

• corePoolSize：核心線程數;
• maximumPoolSize：線程池的最大線程數;
• keepAliveTime：核心線程數之外的線程，空閑存活的時長;
• unit：keepAliveTime 的時間單位;

corePoolSize 和 maximumPoolSize 我們比較熟悉了，另外能夠控制它的就是 keepAliveTime 空閑存活時長，以及這個時長的單位。

當線程池中的線程數，超過核心線程數時。此時如果任務量下降，肯定會出現有一些線程處于無任務執行的空閑狀態。那么如果這個線程的空閑時間超過了 keepAliveTime&unit 配置的時長后，就會被回收。

需要注意的是，對于線程池來說，它只負責管理線程，對于創建的線程是不區分所謂的「核心線程」和「非核心線程」的，它只對線程池中的線程總數進行管理，當回收的線程數達到 corePoolSize 時，回收的過程就會停止。

對于線程池的核心線程數中的線程，也有回收的辦法，可以通過 allowCoreThreadTimeOut(true) 方法設置，在核心線程空閑的時候，一旦超過 keepAliveTime&unit 配置的時間，也將其回收掉。

 

public void allowCoreThreadTimeOut(boolean value) { 
  if (value && keepAliveTime <= 0) 
    throw new IllegalArgumentException("Core threads must have nonzero keep alive times"); 
  if (value != allowCoreThreadTimeOut) { 
    allowCoreThreadTimeOut = value; 
    if (value) 
      interruptIdleWorkers(); 
  } 
} 

allowCoreThreadTimeOut() 能被設置的前提是 keepAliveTime 不能為 0。

2.3 查缺補漏

1. 等待隊列還會影響拒絕策略

等待隊列如果配置成了無界隊列，不光影響線程數量從核心線程數向最大線程數的增長，還會導致配置的拒絕策略永遠得不到執行。

因為只有在線程池中的工作線程數量已經達到核心線程數，并且此時等待隊列也滿了的情況下，拒絕策略才能生效。

2. 核心線程數可以被「預熱」

前面提到默認的情況下，線程池中的線程是根據任務來增長的。但如果有需要，我們也可以提前準備好線程池的核心線程，來應對突然的高并發任務，例如在搶購系統中就經常有這樣的需要。

此時就可以利用 prestartCoreThread() 或者 prestartAllCoreThreads() 來提前創建核心線程，這種方式被我們稱為「預熱」。

3. 對于需要無界隊列的場景，怎么辦?

需求是多變的，我們肯定會碰到需要使用無界隊列的場景，那么這種場景下配置的 maximumPoolSize 就是無效的。

此時就可以參考 Executors 中 newFixedThreadPool() 創建線程池的過程，將 corePoolSize 和 maximumPoolSize 保持一致即可。

public static ExecutorService newFixedThreadPool(int nThreads) { 
  return new ThreadPoolExecutor( 
    nThreads, nThreads, 
    0L, TimeUnit.MILLISECONDS, 
    new LinkedBlockingQueue<Runnable>()); 
} 

此時核心線程數就是最大線程數，只有增長到這個數量才會將任務放入等待隊列，來保證我們配置的線程數量都得到了使用。

4. 線程池是公平的嗎?

所謂的公平，就是先到的任務會被先執行。這在線程池中，顯然是不公平的。

不提線程池中線程執行任務是通過系統去調度的，這一點就決定了任務的執行順序是無法保證的，這就是是非公平的。另外只從線程池本身的角度來看，我們只看提交的任務順序來看，它也是非公平的。

首先前面到的任務，如果線程池的核心線程已經分配出去了，此時這個任務就會進入任務隊列，那么如果任務隊列滿了之后，新到的任務會直接由線程池新創建線程去處理，直到線程數達到最大線程數。

那么此時，任務隊列中的任務，雖然先添加進線程池等待處理，但是這些任務的處理時機，是晚于后續新創建線程去處理的任務的，所以說僅從任務的角度，依然是非公平的。

三、小結時刻

本文我們聊到了線程池中，對于線程數量的增長和收縮策略。

在這里我們簡單總結一下：

1. 增長策略。默認情況下，線程池是根據任務先創建足夠核心線程數的線程去執行任務，當核心線程滿了時將任務放入等待隊列。待隊列滿了的時候，繼續創建新線程執行任務直到到達最大線程數停止。再有新任務的話，那就只能執行拒絕策略或是拋出異常。

2. 收縮策略。當線程池線程數量大于核心線程數 && 當前有空閑線程 && 空閑線程的空閑時間大于 keepAliveTime 時，會對該空閑線程進行回收，直到線程數量等于核心線程數為止。

總之要謹記，慎用無界隊列。