ThreadPoolExecutor使用和思考(上)-线程池大小设置与BlockingQueue的三种实现区别
前記：
?
?
?
查看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有一個特點，他是無界的。
?
Java代碼 ??
ExecutorService newSingleThreadExecutor()：單線程。
?
可以看到，與fixedThreadPool很像，只不過fixedThreadPool中的入參直接退化為1
?
?
Java代碼 ??
ExecutorService newCachedThreadPool()：無界線程池，可以進行自動線程回收。
?
這個實現就有意思了。首先是無界的線程池，所以我們可以發現maximumPoolSize為big big。其次BlockingQueue的選擇上使用SynchronousQueue?？赡軐τ谠揃lockingQueue有些陌生，簡單說：該QUEUE中，每個插入操作必須等待另一個
線程的對應移除操作。比如，我先添加一個元素，接下來如果繼續想嘗試添加則會阻塞，直到另一個線程取走一個元素，反之亦然。（想到什么？就是緩沖區為1的生產者消費者模式^_^）
注意到介紹中的自動回收線程的特性嗎，為什么呢？先不說，但注意到該實現中corePoolSize和maximumPoolSize的大小不同。
?
?
Java代碼 ?===============================神奇分割線==================================
?
到此如果有很多疑問，那是必然了（除非你也很了解了）
?
先從BlockingQueue<Runnable>?workQueue這個入參開始說起。在JDK中，其實已經說得很清楚了，一共有三種類型的queue。以下為引用：（我會稍微修改一下，并用紅色突出顯示）
?
?
- 如果運行的線程少于 corePoolSize，則 Executor 始終首選添加新的線程，而不進行排隊。（什么意思？如果當前運行的線程小于corePoolSize，則任務根本不會存放，添加到queue中，而是直接抄家伙（thread）開始運行）
- 如果運行的線程等于或多于 corePoolSize，則 Executor 始終首選將請求加入隊列，而不添加新的線程。
- 如果無法將請求加入隊列，則創建新的線程，除非創建此線程超出 maximumPoolSize，在這種情況下，任務將被拒絕。
排隊有三種通用策略：
?
===============================神奇分割線==================================
?
到這里，該了解的理論已經夠多了，可以調節的就是corePoolSize和maximumPoolSizes 這對參數還有就是BlockingQueue的選擇。
?
例子一：使用直接提交策略，也即SynchronousQueue。
?
首先SynchronousQueue是無界的，也就是說他存數任務的能力是沒有限制的，但是由于該Queue本身的特性，在某次添加元素后必須等待其他線程取走后才能繼續添加。在這里不是核心線程便是新創建的線程，但是我們試想一樣下，下面的場景。
?
我們使用一下參數構造ThreadPoolExecutor：
?
?
Java代碼 ??當核心線程已經有2個正在運行.
?
什么意思？如果你的任務A1，A2有內部關聯，A1需要先運行，那么先提交A1，再提交A2，當使用SynchronousQueue我們可以保證，A1必定先被執行，在A1么有被執行前，A2不可能添加入queue中
例子二：使用無界隊列策略，即LinkedBlockingQueue
這個就拿newFixedThreadPool來說，根據前文提到的規則： 寫道 如果運行的線程少于 corePoolSize，則 Executor 始終首選添加新的線程，而不進行排隊。 那么當任務繼續增加，會發生什么呢？ 寫道 ? 如果運行的線程等于或多于 corePoolSize，則 Executor 始終首選將請求加入隊列，而不添加新的線程。
?OK，此時任務變加入隊列之中了，那什么時候才會添加新線程呢？
?
寫道 如果無法將請求加入隊列，則創建新的線程，除非創建此線程超出 maximumPoolSize，在這種情況下，任務將被拒絕。這里就很有意思了，可能會出現無法加入隊列嗎？不像SynchronousQueue那樣有其自身的特點，對于無界隊列來說，總是可以加入的（資源耗盡，當然另當別論）。換句說，永遠也不會觸發產生新的線程！corePoolSize大小的線程數會一直運行，忙完當前的，就從隊列中拿任務開始運行。所以要防止任務瘋長，比如任務運行的實行比較長，而添加任務的速度遠遠超過處理任務的時間，而且還不斷增加，如果任務內存大一些，不一會兒就爆了，呵呵。
?
可以仔細想想哈。
?
例子三：有界隊列，使用ArrayBlockingQueue。
?
這個是最為復雜的使用，所以JDK不推薦使用也有些道理。與上面的相比，最大的特點便是可以防止資源耗盡的情況發生。
?
舉例來說，請看如下構造方法：
?
Java代碼 ?假設，所有的任務都永遠無法執行完。
?
對于首先來的A,B來說直接運行，接下來，如果來了C,D，他們會被放到queu中，如果接下來再來E,F，則增加線程運行E，F。但是如果再來任務，隊列無法再接受了，線程數也到達最大的限制了，所以就會使用拒絕策略來處理。
?
總結：
總結
以上是生活随笔為你收集整理的ThreadPoolExecutor使用和思考(上)-线程池大小设置与BlockingQueue的三种实现区别的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： linux 环境变量设置方法总结（PAT
- 下一篇： 1. ThreadPoolExecuto