ThreadPoolExecutor使用和思考(上)-執行緒池大小設定與BlockingQueue的三種實現區別

工作中多處接觸到了ThreadPoolExecutor。趁著現在還算空，學習總結一下。

 

前記：

 

1. jdk官方文件（javadoc）是學習的最好，最權威的參考。
2. 文章分上中下。上篇中主要介紹ThreadPoolExecutor接受任務相關的兩方面入參的意義和區別，池大小引數corePoolSize和maximumPoolSize，BlockingQueue選型（SynchronousQueue，LinkedBlockingQueue，ArrayBlockingQueue）；中篇中主要聊聊與keepAliveTime這個引數相關的話題；下片中介紹一下一些比較少用的該類的API，及他的近親：ScheduledThreadPoolExecutor。
3. 如果理解錯誤，請直接指出。

 

 

檢視JDK幫助文件，可以發現該類比較簡單，繼承自AbstractExecutorService，而AbstractExecutorService實現了ExecutorService介面。

 

ThreadPoolExecutor的完整構造方法的簽名是：

 

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

 

先記著，後面慢慢解釋。

 

===============================神奇分割線==================================

 

其實對於ThreadPoolExecutor的建構函式網上有N多的解釋的，大多講得都很好，不過我想先換個方式，從Executors這個類入手。因為他的幾個構造工廠構造方法名字取得令人很容易瞭解有什麼特點。但是其實Executors類的底層實現便是ThreadPoolExecutor！

 

ThreadPoolExecutor是Executors類的底層實現。

 

在JDK幫助文件中，有如此一段話：

“強烈建議程式設計師使用較為方便的 Executors 工廠方法 Executors.newCachedThreadPool()（無界執行緒池，可以進行自動執行緒回收）、Executors.newFixedThreadPool(int)（固定大小執行緒池）和Executors.newSingleThreadExecutor()（單個後臺執行緒），它們均為大多數使用場景預定義了設定。”

 

可以推斷出ThreadPoolExecutor與Executors類必然關係密切。

 

===============================神奇分割線==================================

 

 

OK，那就來看看原始碼吧，從newFixedThreadPool開始。

 

ExecutorService newFixedThreadPool(int nThreads):固定大小執行緒池。

 

可以看到，corePoolSize和maximumPoolSize的大小是一樣的（實際上，後面會介紹，如果使用無界queue的話maximumPoolSize引數是沒有意義的），keepAliveTime和unit的設值表名什麼？-就是該實現不想keep alive！最後的BlockingQueue選擇了LinkedBlockingQueue，該queue有一個特點，他是無界的。

 

 

ExecutorService newSingleThreadExecutor()：單執行緒。

 

可以看到，與fixedThreadPool很像，只不過fixedThreadPool中的入參直接退化為1

 

 

 

 

ExecutorService newCachedThreadPool()：無界執行緒池，可以進行自動執行緒回收。

 

這個實現就有意思了。首先是無界的執行緒池，所以我們可以發現maximumPoolSize為big big。其次BlockingQueue的選擇上使用SynchronousQueue。可能對於該BlockingQueue有些陌生，簡單說：該QUEUE中，每個插入操作必須等待另一個

執行緒的對應移除操作。比如，我先新增一個元素，接下來如果繼續想嘗試新增則會阻塞，直到另一個執行緒取走一個元素，反之亦然。（想到什麼？就是緩衝區為1的生產者消費者模式^_^）

注意到介紹中的自動回收執行緒的特性嗎，為什麼呢？先不說，但注意到該實現中corePoolSize和maximumPoolSize的大小不同。

 

 

 

===============================神奇分割線==================================

 

到此如果有很多疑問，那是必然了（除非你也很瞭解了）

 

先從BlockingQueue<Runnable> workQueue這個入參開始說起。在JDK中，其實已經說得很清楚了，一共有三種型別的queue。以下為引用：（我會稍微修改一下，並用紅色突出顯示）

 

 

所有 BlockingQueue 都可用於傳輸和保持提交的任務。可以使用此佇列與池大小進行互動：

• 如果執行的執行緒少於 corePoolSize，則 Executor 始終首選新增新的執行緒，而不進行排隊。（什麼意思？如果當前執行的執行緒小於corePoolSize，則任務根本不會存放，新增到queue中，而是直接抄傢伙（thread）開始執行）
• 如果執行的執行緒等於或多於 corePoolSize，則 Executor 始終首選將請求加入佇列，而不新增新的執行緒。
• 如果無法將請求加入佇列，則建立新的執行緒，除非建立此執行緒超出 maximumPoolSize，在這種情況下，任務將被拒絕。

排隊有三種通用策略：

1. 直接提交。工作佇列的預設選項是 SynchronousQueue，它將任務直接提交給執行緒而不保持它們。在此，如果不存在可用於立即執行任務的執行緒，則試圖把任務加入佇列將失敗，因此會構造一個新的執行緒。此策略可以避免在處理可能具有內部依賴性的請求集時出現鎖。直接提交通常要求無界 maximumPoolSizes 以避免拒絕新提交的任務。當命令以超過佇列所能處理的平均數連續到達時，此策略允許無界執行緒具有增長的可能性。
2. 無界佇列。使用無界佇列（例如，不具有預定義容量的 LinkedBlockingQueue）將導致在所有 corePoolSize 執行緒都忙時新任務在佇列中等待。這樣，建立的執行緒就不會超過 corePoolSize。（因此，maximumPoolSize 的值也就無效了。）當每個任務完全獨立於其他任務，即任務執行互不影響時，適合於使用無界佇列；例如，在 Web 頁伺服器中。這種排隊可用於處理瞬態突發請求，當命令以超過佇列所能處理的平均數連續到達時，此策略允許無界執行緒具有增長的可能性。
3. 有界佇列。當使用有限的 maximumPoolSizes 時，有界佇列（如 ArrayBlockingQueue）有助於防止資源耗盡，但是可能較難調整和控制。佇列大小和最大池大小可能需要相互折衷：使用大型佇列和小型池可以最大限度地降低 CPU 使用率、作業系統資源和上下文切換開銷，但是可能導致人工降低吞吐量。如果任務頻繁阻塞（例如，如果它們是 I/O 邊界），則系統可能為超過您許可的更多執行緒安排時間。使用小型佇列通常要求較大的池大小，CPU 使用率較高，但是可能遇到不可接受的排程開銷，這樣也會降低吞吐量。  

 

===============================神奇分割線==================================

 

到這裡，該瞭解的理論已經夠多了，可以調節的就是corePoolSize和maximumPoolSizes 這對引數還有就是BlockingQueue的選擇。

 

例子一：使用直接提交策略，也即SynchronousQueue。

 

首先SynchronousQueue是無界的，也就是說他存數任務的能力是沒有限制的，但是由於該Queue本身的特性，在某次新增元素後必須等待其他執行緒取走後才能繼續新增。在這裡不是核心執行緒便是新建立的執行緒，但是我們試想一樣下，下面的場景。

 

我們使用一下引數構造ThreadPoolExecutor：

 

 

 當核心執行緒已經有2個正在執行.

 

1. 此時繼續來了一個任務（A），根據前面介紹的“如果執行的執行緒等於或多於 corePoolSize，則 Executor 始終首選將請求加入佇列，而不新增新的執行緒。”,所以A被新增到queue中。
2. 又來了一個任務（B），且核心2個執行緒還沒有忙完，OK，接下來首先嚐試1中描述，但是由於使用的SynchronousQueue，所以一定無法加入進去。
3. 此時便滿足了上面提到的“如果無法將請求加入佇列，則建立新的執行緒，除非建立此執行緒超出maximumPoolSize，在這種情況下，任務將被拒絕。”，所以必然會新建一個執行緒來執行這個任務。
4. 暫時還可以，但是如果這三個任務都還沒完成，連續來了兩個任務，第一個新增入queue中，後一個呢？queue中無法插入，而執行緒數達到了maximumPoolSize，所以只好執行異常策略了。

 

 OK，此時任務變加入佇列之中了，那什麼時候才會新增新執行緒呢？

 

這裡就很有意思了，可能會出現無法加入佇列嗎？不像SynchronousQueue那樣有其自身的特點，對於無界佇列來說，總是可以加入的（資源耗盡，當然另當別論）。換句說，永遠也不會觸發產生新的執行緒！corePoolSize大小的執行緒數會一直執行，忙完當前的，就從佇列中拿任務開始執行。所以要防止任務瘋長，比如任務執行的實行比較長，而新增任務的速度遠遠超過處理任務的時間，而且還不斷增加，如果任務記憶體大一些，不一會兒就爆了，呵呵。

 

可以仔細想想哈。

 

例子三：有界佇列，使用ArrayBlockingQueue。

 

這個是最為複雜的使用，所以JDK不推薦使用也有些道理。與上面的相比，最大的特點便是可以防止資源耗盡的情況發生。

 

舉例來說，請看如下構造方法：

 

假設，所有的任務都永遠無法執行完。

 

對於首先來的A,B來說直接執行，接下來，如果來了C,D，他們會被放到queu中，如果接下來再來E,F，則增加執行緒執行E，F。但是如果再來任務，佇列無法再接受了，執行緒數也到達最大的限制了，所以就會使用拒絕策略來處理。

 

總結：

1. ThreadPoolExecutor的使用還是很有技巧的。
2. 使用無界queue可能會耗盡系統資源。
3. 使用有界queue可能不能很好的滿足效能，需要調節執行緒數和queue大小
4. 執行緒數自然也有開銷，所以需要根據不同應用進行調節。