Java線程池

為了更好地控制多線程，JDK提供了一套Executor架構，幫助開發人員有效的進行線程控制，其本質就是一個線程池。其中ThreadPoolExecutor是線程池中最核心的一個類，後面提到的四種線程池都是基于ThreadPoolExecutor實作的。

ThreadPoolExecutor提供了四個構造方法，我們看下最重要的一個構造函數：

函數的參數含義如下：

corePoolSize： 線程池維護線程的最少數量

maximumPoolSize：線程池維護線程的最大數量

keepAliveTime： 線程池維護線程所允許的空閑時間

unit： 線程池維護線程所允許的空閑時間的機關

workQueue： 線程池所使用的緩沖隊列

handler： 線程池對拒絕任務的處理政策

線程池執行的過程：

線程池剛建立時，裡面沒有一個線程。任務隊列是作為參數傳進來的。不過，就算隊列裡面有任務，線程池也不會馬上執行它們。

當調用 execute() 方法添加一個任務時，線程池會做如下判斷：

a. 如果正在運作的線程數量小于 corePoolSize，那麼馬上建立線程運作這個任務；

b. 如果正在運作的線程數量大于或等于 corePoolSize，那麼将這個任務放入隊列。

c. 如果這時候隊列滿了，而且正在運作的線程數量小于 maximumPoolSize，那麼還是要建立線程運作這個任務；

d. 如果隊列滿了，而且正在運作的線程數量大于或等于 maximumPoolSize，那麼線程池會抛出異常，告訴調用者“我不能再接受任務了”。

當一個線程完成任務時，它會從隊列中取下一個任務來執行。

當一個線程無事可做，超過一定的時間（keepAliveTime）時，線程池會判斷，如果目前運作的線程數大于corePoolSize，那麼這個線程就被停掉。是以線程池的所有任務完成後，它最終會收縮到 corePoolSize 的大小。

ThreadPoolExecutor的繼承關系：

ThreadPoolExecutor中的隊列：

ThreadPoolExecutor内部應用了任務緩存隊列，即workQueue，它用來存放等待執行的任務。

workQueue的類型為BlockingQueue，通常可以取下面三種類型：

ArrayBlockingQueue：基于數組的先進先出隊列，此隊列建立時必須指定大小；

LinkedBlockingQueue：基于連結清單的先進先出隊列，如果建立時沒有指定此隊列大小，則預設為Integer.MAX_VALUE；

synchronousQueue：這個隊列比較特殊，它不會儲存送出的任務，而是将直接建立一個線程來執行新來的任務。

任務拒絕政策：

當線程池的任務緩存隊列已滿并且線程池中的線程數目達到maximumPoolSize，如果還有任務到來就會采取任務拒絕政策，通常有以下四種政策：

擴充線程池（記錄任務執行日志）：

在預設的ThreadPoolExecutor實作中，提供了空的beforeExecutor和afterExecutor的實作，在實際應用中可以對其進行擴充來實作對線程池運作狀态的追蹤，輸出一些有用的調試資訊，以幫助系統故障診斷，這對于多線程程式錯誤排查是很有幫助的。

ThreadPoolExecutor例子：

我們可以利用這個特性實作線上程池中列印出異常堆棧資訊（正常是不會列印出來的），這裡就不示範了。

<a></a>

Executors 提供了一系列工廠方法用于創先線程池，傳回的線程池都實作了 ExecutorService 接口。

這四種方法都是用的 Executors 中的 ThreadFactory 建立的線程。

newCachedThreadPool()

緩存型池子，先檢視池中有沒有以前建立的線程，如果有，就 reuse 如果沒有，就建一個新的線程加入池中

緩存型池子通常用于執行一些生存期很短的異步型任務 是以在一些面向連接配接的 daemon 型 SERVER 中用得不多。但對于生存期短的異步任務，它是 Executor 的首選。

能 reuse 的線程，必須是 timeout IDLE 内的池中線程，預設 timeout 是 60s,超過這個 IDLE 時長，線程執行個體将被終止及移出池。

newFixedThreadPool(int)

newFixedThreadPool 與 cacheThreadPool 差不多，也是能 reuse 就用，但不能随時建新的線程。

其獨特之處:任意時間點，最多隻能有固定數目的活動線程存在，此時如果有新的線程要建立，隻能放在另外的隊列中等待，直到目前的線程中某個線程終止直接被移出池子。

和 cacheThreadPool 不同，FixedThreadPool 沒有 IDLE 機制（可能也有，但既然文檔沒提，肯定非常長，類似依賴上層的 TCP 或 UDP IDLE 機制之類的），是以 FixedThreadPool 多數針對一些很穩定很固定的正規并發線程，多用于伺服器。

從方法的源代碼看，cache池和fixed 池調用的是同一個底層 池，隻不過參數不同:

fixed 池線程數固定，并且是0秒IDLE（無IDLE）。

cache 池線程數支援 0-Integer.MAX_VALUE(顯然完全沒考慮主機的資源承受能力），60 秒 IDLE 。

newScheduledThreadPool(int)

排程型線程池

這個池子裡的線程可以按 schedule 依次 delay 執行，或周期執行

SingleThreadExecutor()

單例線程，任意時間池中隻能有一個線程

用的是和 cache 池和 fixed 池相同的底層池，但線程數目是 1-1,0 秒 IDLE（無 IDLE）

一般來說，CachedTheadPool 在程式執行過程中通常會建立與所需數量相同的線程，然後在它回收舊線程時停止建立新線程，是以它是合理的 Executor 的首選，隻有當這種方式會引發問題時（比如需要大量長時間面向連接配接的線程時），才需要考慮用 FixedThreadPool。 ----《Thinking in Java》第四版

以上引用自極客學院，總結的太精彩了。

Spring的TaskExecutor接口等同于java.util.concurrent.Executor接口。 實際上，它存在的主要原因是為了在使用線程池的時候，将對Java 5的依賴抽象出來。 這個接口隻有一個方法execute(Runnable task)，它根據線程池的語義和配置，來接受一個執行任務。最初建立TaskExecutor是為了在需要時給其他Spring元件提供一個線程池的抽象。例如ApplicationEventMulticaster元件、JMS的 AbstractMessageListenerContainer和對Quartz的整合都使用了TaskExecutor抽象來提供線程池。 當然，如果你的bean需要線程池行為，你也可以使用這個抽象層。

介紹下使用比較多的ThreadPoolTaskExecutor 類，這個實作隻能在Java 5以上環境使用（現在應該沒有低于1.5的老環境了吧~），它暴露的bean properties可以用來配置一個java.util.concurrent.ThreadPoolExecutor，把它包裝到一個TaskExecutor中。

spring中ThreadPoolTaskExecutor最常用方式就是做為BEAN注入到容器中,其暴露的各個屬性其實是ThreadPoolExecutor的屬性，而且這展現了DI容器的優勢：

線程池的理想大小取決于被送出任務的類型以及所部署系統的特性。在代碼中不會固定線程池的大小，而應該通過某種配置機制來來提供，或者根據Runtime.getRuntime().availableProcessors()來動态計算。

如果一台伺服器上隻部署這一個應用并且隻有一個線程池（N為CPU總核數）：

如果是CPU密集型應用，則線程池大小設定為N+1

如果是IO密集型應用，則線程池大小設定為2N+1

線程等待時間所占比例越高，需要越多線程。線程CPU時間所占比例越高，需要越少線程。

【黃金公式】最佳線程數目 = （線程等待時間與線程CPU時間之比 + 1）* CPU數目

一個實際的計算過程（慕課網）：

假設值

tasks ：每秒的任務數，假設為500~1000

taskcost：每個任務花費時間，假設為0.1s

responsetime：系統允許容忍的最大響應時間，假設為1s

計算

corePoolSize = 每秒需要多少個線程處理？

threadcount = tasks/(1/taskcost) =taskstaskcout = (500~1000)0.1 = 50~100 個線程。corePoolSize設定應該大于50

根據8020原則，如果80%的每秒任務數小于800，那麼corePoolSize設定為80即可

queueCapacity = (coreSizePool/taskcost)*responsetime

計算可得 queueCapacity = 80/0.1*1 = 80。意思是隊列裡的線程可以等待1s，超過了的需要新開線程來執行

切記不能設定為Integer.MAX_VALUE，這樣隊列會很大，線程數隻會保持在corePoolSize大小，當任務陡增時，不能新開線程來執行，響應時間會随之陡增。

maxPoolSize = (max(tasks)- queueCapacity)/(1/taskcost)

計算可得 maxPoolSize = (1000-80)/10 = 92

(最大任務數-隊列容量)/每個線程每秒處理能力 = 最大線程數

rejectedExecutionHandler：根據具體情況來決定，任務不重要可丢棄，任務重要則要利用一些緩沖機制來處理

keepAliveTime和allowCoreThreadTimeout采用預設通常能滿足

本文轉自 bxst 51CTO部落格，原文連結:http://blog.51cto.com/13013670/1943962