線程池(java.util.concurrent.ThreadPoolExecutor)的使用

一、簡介

線程池類為 java.util.concurrent.ThreadPoolExecutor，常用構造方法為：

ThreadPoolExecutor(int corePoolSize, int maximumPoolSize,

long keepAliveTime, TimeUnit unit,

BlockingQueue workQueue,

RejectedExecutionHandler handler)

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

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

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

unit： 線程池維護線程所允許的空閑時間的單位

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

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

一個任務通過 execute(Runnable)方法被添加到線程池，任務就是一個 Runnable類型的對象，任務的執行方法就是 Runnable類型對象的run()方法。

當一個任務通過execute(Runnable)方法欲添加到線程池時：

l 如果此時線程池中的數量小於corePoolSize，即使線程池中的線程都處於空閑狀態，也要建立新的線程來處理被添加的任務。

l 如果此時線程池中的數量等於 corePoolSize，但是緩衝隊列 workQueue未滿，那麼任務被放入緩衝隊列。

l 如果此時線程池中的數量大於corePoolSize，緩衝隊列workQueue滿，並且線程池中的數量小於maximumPoolSize，建新的線程來處理被添加的任務。

l 如果此時線程池中的數量大於corePoolSize，緩衝隊列workQueue滿，並且線程池中的數量等於maximumPoolSize，那麼通過 handler所指定的策略來處理此任務。也就是：處理任務的優先順序為：核心線程corePoolSize、任務隊列workQueue、最大線程 maximumPoolSize，如果三者都滿了，使用handler處理被拒絕的任務。

l 當線程池中的線程數量大於 corePoolSize時，如果某線程空閑時間超過keepAliveTime，線程將被終止。這樣，線程池可以動態調整池中的線程數。

unit可選的參數為java.util.concurrent.TimeUnit中的幾個靜態屬性：

NANOSECONDS、

MICROSECONDS、

MILLISECONDS、

SECONDS。

workQueue常用的是：java.util.concurrent.ArrayBlockingQueue

handler有四個選擇：

ThreadPoolExecutor.AbortPolicy()

拋出java.util.concurrent.RejectedExecutionException異常

ThreadPoolExecutor.CallerRunsPolicy()

重試添加當前的任務，他會自動重複調用execute()方法

ThreadPoolExecutor.DiscardOldestPolicy()

拋棄舊的任務

ThreadPoolExecutor.DiscardPolicy()

拋棄當前的任務

二、相關參考

一個 ExecutorService，它使用可能的幾個池線程之一執行每個提交的任務，通常使用 Executors Factory 方法配置。

線程池可以解決兩個不同問題：由於減少了每個任務調用的開銷，它們通常可以在執行大量非同步任務時提供增強效能，並且還可以提供綁定和管理資源（包 括執行集合任務時使用的線程）的方法。每個 ThreadPoolExecutor 還維護著一些基本的統計資料，如完成的任務數。

為了便於跨大量上下文使用，此類提供了很多可調整的參數和擴充掛鈎。但是，強烈建議程式員使用較為方便的 Executors Factory 方法 Executors.newCachedThreadPool()（無界線程池，可以進行自動線程回收）、 Executors.newFixedThreadPool(int)（固定大小線程池）和 Executors.newSingleThreadExecutor()（單個後台線程），它們均為大多數使用情境預定義了設定。否則，在手動設定和調 整此類時，使用以下指導：

核心和最大池大小

ThreadPoolExecutor 將根據 corePoolSize（參見 getCorePoolSize()）和 maximumPoolSize（參見 getMaximumPoolSize()）設定的邊界自動調整池大小。當新任務在方法 execute(java.lang.Runnable) 中提交時，如果啟動並執行線程少於 corePoolSize，則建立新線程來處理請求，即使其他輔助線程是閒置。如果啟動並執行線程多於 corePoolSize 而少於 maximumPoolSize，則僅當隊列滿時才建立新線程。如果設定的 corePoolSize 和 maximumPoolSize 相同，則建立了固定大小的線程池。如果將 maximumPoolSize 設定為基本的無界值（如 Integer.MAX_VALUE），則允許池適應任意數量的並發任務。在大多數情況下，核心和最大池大小僅基於構造來設定，不過也可以使用 setCorePoolSize(int) 和 setMaximumPoolSize(int) 進行動態更改。

按需構造

預設情況下，即使核心線程最初只是在新任務需要時才建立和啟動的，也可以使用方法 prestartCoreThread() 或 prestartAllCoreThreads() 對其進行動態重寫。

建立新線程

使用 ThreadFactory 建立新線程。如果沒有另外說明，則在同一個 ThreadGroup 中一律使用 Executors.defaultThreadFactory() 建立線程，並且這些線程具有相同的 NORM_PRIORITY 優先順序和非守護進程狀態。通過提供不同的 ThreadFactory，可以改變線程的名稱、線程組、優先順序、守護進程狀態，等等。如果從 newThread 返回 null 時 ThreadFactory 未能建立線程，則執行程式將繼續運行，但不能執行任何任務。

保持啟用時間

如果池中當前有多於 corePoolSize 的線程，則這些多出的線程在空閑時間超過 keepAliveTime 時將會終止（參見 getKeepAliveTime(java.util.concurrent.TimeUnit)）。這提供了當池處於非使用中時減少資源消耗的方 法。如果池後來變得更為活動，則可以建立新的線程。也可以使用方法 setKeepAliveTime(long, java.util.concurrent.TimeUnit) 動態地更改此參數。使用 Long.MAX_VALUE TimeUnit.NANOSECONDS 的值在關閉前有效地從以前的終止狀態禁用空閑線程。

排隊

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

A. 如果啟動並執行線程少於 corePoolSize，則 Executor 始終首選添加新的線程，而不進行排隊。

B. 如果啟動並執行線程等於或多於 corePoolSize，則 Executor 始終首選將請求排入佇列，而不添加新的線程。

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

排隊有三種通用策略：

直接提交。工作隊列的預設選項是 SynchronousQueue，它將任務直接提交給線程而不保持它們。在此，如果不存在可用於立即運行任務的線程，則試圖把任務排入佇列將失敗，因此 會構造一個新的線程。此策略可以避免在處理可能具有內部依賴性的請求集合時出現鎖定。直接提交通常要求無界 maximumPoolSizes 以避免拒絕新提交的任務。當命令以超過隊列所能處理的平均數連續到達時，此策略允許無界線程具有增長的可能性。

無界隊列。使用無界隊列（例如，不具有預定義容量的 LinkedBlockingQueue）將導致在所有 corePoolSize 線程都忙的情況下將新任務排入佇列。這樣，建立的線程就不會超過 corePoolSize。（因此，maximumPoolSize 的值也就無效了。）當每個任務完全獨立於其他任務，即任務執行互不影響時，適合於使用無界隊列；例如，在 Web 頁伺服器中。這種排隊可用於處理瞬態突發請求，當命令以超過隊列所能處理的平均數連續到達時，此策略允許無界線程具有增長的可能性。

有界隊列。當使用有限的 maximumPoolSizes 時，有界隊列（如 ArrayBlockingQueue）有助於防止資源耗盡，但是可能較難調整和控制。隊列大小和最大池大小可能需要相互折衷：使用大型隊列和小型池可以 最大限度地降低 CPU 使用率、作業系統資源和環境切換開銷，但是可能導致人工降低輸送量。如果任務頻繁阻塞（例如，如果它們是 I/O 邊界），則系統可能為超過您許可的更多線程安排時間。使用小型隊列通常要求較大的池大小，CPU 使用率較高，但是可能遇到不可接受的調度開銷，這樣也會降低輸送量。

被拒絕的任務

當 Executor 已經關閉，並且 Executor 將有限邊界用於最大線程和工作隊列容量，且已經飽和時，在方法 execute(java.lang.Runnable) 中提交的新任務將被拒絕。在以上兩種情況下，execute 方法都將調用其 RejectedExecutionHandler 的 RejectedExecutionHandler.rejectedExecution(java.lang.Runnable, java.util.concurrent.ThreadPoolExecutor) 方法。下面提供了四種預定義的處理常式策略：

當 Executor 已經關閉，並且 Executor 將有限邊界用於最大線程和工作隊列容量，且已經飽和時，在方法 execute(java.lang.Runnable) 中提交的新任務將被拒絕。在以上兩種情況下，execute 方法都將調用其 RejectedExecutionHandler 的 RejectedExecutionHandler.rejectedExecution(java.lang.Runnable, java.util.concurrent.ThreadPoolExecutor) 方法。下面提供了四種預定義的處理常式策略：

A. 在預設的 ThreadPoolExecutor.AbortPolicy 中，處理常式遭到拒絕將拋出運行時 RejectedExecutionException。

B. 在 ThreadPoolExecutor.CallerRunsPolicy 中，線程調用運行該任務的 execute 本身。此策略提供簡單的反饋控制機制，能夠減緩新任務的提交速度。

C. 在 ThreadPoolExecutor.DiscardPolicy 中，不能執行的任務將被刪除。

D. 在 ThreadPoolExecutor.DiscardOldestPolicy 中，如果執行程式尚未關閉，則位於工作隊列頭部的任務將被刪除，然後重試執行程式（如果再次失敗，則重複此過程）。

定義和使用其他種類的 RejectedExecutionHandler 類也是可能的，但這樣做需要非常小心，尤其是當策略僅用於特定容量或排隊策略時。

掛鈎方法

此類提供 protected 可重寫的 beforeExecute(java.lang.Thread, java.lang.Runnable) 和 afterExecute(java.lang.Runnable, java.lang.Throwable) 方法，這兩種方法分別在執行每個任務之前和之後調用。它們可用於操縱執行環境；例如，重新初始化 ThreadLocal、搜集統計資訊或添加日誌條目。此外，還可以重寫方法 terminated() 來執行 Executor 完全終止後需要完成的所有特殊處理。

如果掛鈎或回調方法拋出異常，則內部輔助線程將依次失敗並突然終止。

隊列維護

方法 getQueue() 允許出於監控和調試目的而訪問工作隊列。強烈反對出於其他任何目的而使用此方法。remove(java.lang.Runnable) 和 purge() 這兩種方法可用於在取消大量已排隊任務時協助進行儲存回收。

一、例子

建立 TestThreadPool 類：

view plaincopy to clipboardprint?
import java.util.concurrent.ArrayBlockingQueue;
import java.util.concurrent.ThreadPoolExecutor;
import java.util.concurrent.TimeUnit;

public class TestThreadPool {

private static int produceTaskSleepTime = 2;

private static int produceTaskMaxNumber = 10;

public static void main(String[] args) {

// 構造一個線程池
ThreadPoolExecutor threadPool = new ThreadPoolExecutor(2, 4, 3,
TimeUnit.SECONDS, new ArrayBlockingQueue(3),
new ThreadPoolExecutor.DiscardOldestPolicy());

for (int i = 1; i

ThreadPoolExecutor配置

一、ThreadPoolExcutor為一些Executor提供了基本的實現，這些Executor是由Executors中的工廠 newCahceThreadPool、newFixedThreadPool和newScheduledThreadExecutor返回的。 ThreadPoolExecutor是一個靈活的健壯的池實現，允許各種各樣的使用者定製。

二、線程的建立與銷毀

1、核心池大小、最大池大小和存活時間共同管理著線程的建立與銷毀。

2、核心池的大小是目標的大小；線程池的實現試圖維護池的大小；即使沒有任務執行，池的大小也等於核心池的大小，並直到工作隊列充滿前，池都不會建立更多的線程。如果當前池的大小超過了核心池的大小，線程池就會終止它。

3、最大池的大小是可同時活動的線程數的上限。

4、如果一個線程已經閑置的時間超過了存活時間，它將成為一個被回收的候選者。

5、newFixedThreadPool工廠為請求的池設定了核心池的大小和最大池的大小，而且池永遠不會逾時

6、newCacheThreadPool工廠將最大池的大小設定為Integer.MAX_VALUE，核心池的大小設定為0，逾時設定為一分鐘。這樣建立了無限擴大的線程池，會在需求量減少的情況下減少線程數量。

三、管理

1、 ThreadPoolExecutor允許你提供一個BlockingQueue來持有等待執行的任務。任務排隊有3種基本方法：無限隊列、有限隊列和同步移交。

2、 newFixedThreadPool和newSingleThreadExectuor預設使用的是一個無限的 LinkedBlockingQueue。如果所有的工作者線程都處於忙碌狀態，任務會在隊列中等候。如果任務持續快速到達，超過了它們被執行的速度，隊 列也會無限制地增加。穩妥的策略是使用有限隊列，比如ArrayBlockingQueue或有限的LinkedBlockingQueue以及 PriorityBlockingQueue。

3、對於龐大或無限的池，可以使用SynchronousQueue，完全繞開隊列，直接將任務由生產者交給工作者線程

4、可以使用PriorityBlockingQueue通過優先順序安排任務。

線程池隊列飽和策略

1、當一個有限隊列充滿後，線程池的飽和策略開始起作用。

2、ThreadPoolExecutor的飽和策略通過調用setRejectedExecutionHandler來修改。不同的飽和策略如下：

1）AbortPolicy:中止,executor拋出未檢查RejectedExecutionException，調用者捕獲這個異常，然後自己編寫能滿足自己需求的處理代碼。

2）DiscardRunsPolicy:遺棄最舊的，選擇丟棄的任務，是本應接下來就執行的任務。

3)DiscardPolicy:遺棄會預設放棄最新提交的任務（這個任務不能進入隊列等待執行時）

4）CallerRunsPolicy：調用者運行，既不會丟棄哪個任務，也不會拋出任何異常，把一些任務推回到調用者那裡，以此減緩新任務流。它不會在池線程中執行最新提交的任務，但它會在一個調用了execute的線程中執行。

3、建立一個可變長的線程池，使用受限隊列和調用者運行飽和策略。

ThreadPoolExecutor executor=new ThreadPoolExecutor(N_THREADS,N_THREADS,0L,TimeUnit.MILLISECONDS,new LinkedBlockingQueue(CAPACITY));

executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy());

4、當線程隊列充滿後，並沒有預置的飽和策略來阻塞execute。但是，使用Semaphore訊號量可以實現這個效果。Semaphore會限制任務注入率。

@ThreadSafe

public class BoundedExecutor{

private final Executor exec;

private final Semaphore semaphore;

public BoundedExecutor(Executor exec,int bound){

this.exec=exec;

this.semaphore=new Semaphore(bound);

}

public void submitTask(final Runnable command) throws InterruptedException{

semaphore.acquire();

try{

exec.execute(new Runnable(){

public void run(){

try{

command.run();

}

finally{

semaphore.release();

}

}

});

}catch (RejectedExecutionException e){

semaphore.release();

}

}

}