ThreadPoolExecutor使用和思考(上)-線程池大小設置與BlockingQueue的三種實現區別

原文轉載自http://dongxuan.iteye.com/blog/901689

工作中多處接觸到了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有一個特點，他是無界的。

 

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

 

ExecutorService newSingleThreadExecutor()：單線程。

 

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

 

 

public static ExecutorService newSingleThreadExecutor() {
        return new FinalizableDelegatedExecutorService
            (new ThreadPoolExecutor(1, 1,
                                    0L, TimeUnit.MILLISECONDS,
                                    new LinkedBlockingQueue<Runnable>()));
    }

 

 

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

 

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

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

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

 

 

public static ExecutorService newCachedThreadPool() {
        return new ThreadPoolExecutor(0, Integer.MAX_VALUE,
                                      60L, TimeUnit.SECONDS,
                                      new SynchronousQueue<Runnable>());
    }

 

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

 

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

 

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

 

 

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

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

先不着急舉例子，因爲首先需要知道queue上的三種類型。

排隊有三種通用策略：

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

 

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

 

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

 

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

 

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

 

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

 

 

new ThreadPoolExecutor(
            2, 3, 30, TimeUnit.SECONDS,
            new <span style="white-space: normal;">SynchronousQueue</span><Runnable>(),
            new RecorderThreadFactory("CookieRecorderPool"),
            new ThreadPoolExecutor.CallerRunsPolicy());

 當核心線程已經有2個正在運行.

 

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

所以在使用SynchronousQueue通常要求maximumPoolSize是無界的，這樣就可以避免上述情況發生（如果希望限制就直接使用有界隊列）。對於使用SynchronousQueue的作用jdk中寫的很清楚：此策略可以避免在處理可能具有內部依賴性的請求集時出現鎖。

什麼意思？如果你的任務A1，A2有內部關聯，A1需要先運行，那麼先提交A1，再提交A2，當使用SynchronousQueue我們可以保證，A1必定先被執行，在A1麼有被執行前，A2不可能添加入queue中

例子二：使用無界隊列策略，即LinkedBlockingQueue

這個就拿newFixedThreadPool來說，根據前文提到的規則：

 寫道

如果運行的線程少於 corePoolSize，則 Executor 始終首選添加新的線程，而不進行排隊。

 那麼當任務繼續增加，會發生什麼呢？

 寫道

 

如果運行的線程等於或多於 corePoolSize，則 Executor 始終首選將請求加入隊列，而不添加新的線程。

 OK，此時任務變加入隊列之中了，那什麼時候纔會添加新線程呢？

 

 寫道

如果無法將請求加入隊列，則創建新的線程，除非創建此線程超出 maximumPoolSize，在這種情況下，任務將被拒絕。

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

 

可以仔細想想哈。

 

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

 

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

 

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

 

new ThreadPoolExecutor(
            2, 4, 30, TimeUnit.SECONDS,
            new ArrayBlockingQueue<Runnable>(2),
            new RecorderThreadFactory("CookieRecorderPool"),
            new ThreadPoolExecutor.CallerRunsPolicy());

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

 

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

 

總結：

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

通常來說對於靜態任務可以歸爲：

1. 數量大，但是執行時間很短
2. 數量小，但是執行時間較長
3. 數量又大執行時間又長
4. 除了以上特點外，任務間還有些內在關係

看完這篇問文章後，希望能夠可以選擇合適的類型了