本系列文章經補充和完善，已修訂整理成書《Java編程的邏輯》，由機械工業出版社華章分社出版，於2018年1月上市熱銷，讀者好評如潮！各大網店和書店有售，歡迎購買，京東自營鏈接：http://item.jd.com/12299018.html
上節，我們初步探討了Java並發包中的任務執行服務，實際中，任務執行服務的主要實現機制是線程池，本節，我們就來探討線程池。
基本概念
線程池，顧名思義，就是一個線程的池子，里面有若干線程，它們的目的就是執行提交給線程池的任務，執行完一個任務后不會退出，而是繼續等待或執行新任務。線程池主要由兩個概念組成，一個是任務隊列，另一個是工作者線程，工作者線程主體就是一個循環，循環從隊列中接受任務並執行，任務隊列保存待執行的任務。
線程池的概念類似於生活中的一些排隊場景，比如在火車站排隊購票、在醫院排隊掛號、在銀行排隊辦理業務等，一般都由若干個窗口提供服務，這些服務窗口類似於工作者線程，而隊列的概念是類似的，只是，在現實場景中，每個窗口經常有一個單獨的隊列，這種排隊難以公平，隨着信息化的發展，越來越多的排隊場合使用虛擬的統一隊列，一般都是先拿一個排隊號，然后按號依次服務。
線程池的優點是顯而易見的：
- 它可以重用線程，避免線程創建的開銷
- 在任務過多時，通過排隊避免創建過多線程，減少系統資源消耗和競爭，確保任務有序完成
Java並發包中線程池的實現類是ThreadPoolExecutor，它繼承自AbstractExecutorService，實現了ExecutorService，基本用法與上節介紹的類似，我們就不贅述了。不過，ThreadPoolExecutor有一些重要的參數，理解這些參數對於合理使用線程池非常重要，接來下，我們探討這些參數。
理解線程池
構造方法
ThreadPoolExecutor有多個構造方法，都需要一些參數，主要構造方法有：
public ThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long keepAliveTime, TimeUnit unit, BlockingQueue<Runnable> workQueue) public ThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long keepAliveTime, TimeUnit unit, BlockingQueue<Runnable> workQueue, ThreadFactory threadFactory, RejectedExecutionHandler handler)
第二個構造方法多了兩個參數threadFactory和handler，這兩個參數一般不需要，第一個構造方法會設置默認值。
參數corePoolSize, maximumPoolSize, keepAliveTime, unit用於控制線程池中線程的個數，workQueue表示任務隊列，threadFactory用於對創建的線程進行一些配置，handler表示任務拒絕策略。下面我們再來詳細探討下這些參數。
線程池大小
線程池的大小主要與四個參數有關：
- corePoolSize：核心線程個數
- maximumPoolSize：最大線程個數
- keepAliveTime和unit：空閑線程存活時間
maximumPoolSize表示線程池中的最多線程數，線程的個數會動態變化，但這是最大值，不管有多少任務，都不會創建比這個值大的線程個數。
corePoolSize表示線程池中的核心線程個數，不過，這並不是說，一開始就創建這么多線程，剛創建一個線程池后，實際上並不會創建任何線程。
一般情況下，有新任務到來的時候，如果當前線程個數小於corePoolSiz，就會創建一個新線程來執行該任務，需要說明的是，即使其他線程現在也是空閑的，也會創建新線程。
不過，如果線程個數大於等於corePoolSiz，那就不會立即創建新線程了，它會先嘗試排隊，需要強調的是，它是"嘗試"排隊，而不是"阻塞等待"入隊，如果隊列滿了或其他原因不能立即入隊，它就不會排隊，而是檢查線程個數是否達到了maximumPoolSize，如果沒有，就會繼續創建線程，直到線程數達到maximumPoolSize。
keepAliveTime的目的是為了釋放多余的線程資源，它表示，當線程池中的線程個數大於corePoolSize時，額外空閑線程的存活時間，也就是說，一個非核心線程，在空閑等待新任務時，會有一個最長等待時間，即keepAliveTime，如果到了時間還是沒有新任務，就會被終止。如果該值為0，表示所有線程都不會超時終止。
這幾個參數除了可以在構造方法中進行指定外，還可以通過getter/setter方法進行查看和修改。
public void setCorePoolSize(int corePoolSize) public int getCorePoolSize() public int getMaximumPoolSize() public void setMaximumPoolSize(int maximumPoolSize) public long getKeepAliveTime(TimeUnit unit) public void setKeepAliveTime(long time, TimeUnit unit)
除了這些靜態參數，ThreadPoolExecutor還可以查看關於線程和任務數的一些動態數字：
//返回當前線程個數 public int getPoolSize() //返回線程池曾經達到過的最大線程個數 public int getLargestPoolSize() //返回線程池自創建以來所有已完成的任務數 public long getCompletedTaskCount() //返回所有任務數，包括所有已完成的加上所有排隊待執行的 public long getTaskCount()
隊列
ThreadPoolExecutor要求的隊列類型是阻塞隊列BlockingQueue，我們在76節介紹過多種BlockingQueue，它們都可以用作線程池的隊列，比如：
- LinkedBlockingQueue：基於鏈表的阻塞隊列，可以指定最大長度，但默認是無界的。
- ArrayBlockingQueue：基於數組的有界阻塞隊列
- PriorityBlockingQueue：基於堆的無界阻塞優先級隊列
- SynchronousQueue：沒有實際存儲空間的同步阻塞隊列
如果用的是無界隊列，需要強調的是，線程個數最多只能達到corePoolSize，到達corePoolSize后，新的任務總會排隊，參數maximumPoolSize也就沒有意義了。
另一面，對於SynchronousQueue，我們知道，它沒有實際存儲元素的空間，當嘗試排隊時，只有正好有空閑線程在等待接受任務時，才會入隊成功，否則，總是會創建新線程，直到達到maximumPoolSize。
任務拒絕策略
如果隊列有界，且maximumPoolSize有限，則當隊列排滿，線程個數也達到了maximumPoolSize，這時，新任務來了，如何處理呢？此時，會觸發線程池的任務拒絕策略。
默認情況下，提交任務的方法如execute/submit/invokeAll等會拋出異常，類型為RejectedExecutionException。
不過，拒絕策略是可以自定義的，ThreadPoolExecutor實現了四種處理方式：
- ThreadPoolExecutor.AbortPolicy：這就是默認的方式，拋出異常
- ThreadPoolExecutor.DiscardPolicy：靜默處理，忽略新任務，不拋異常，也不執行
- ThreadPoolExecutor.DiscardOldestPolicy：將等待時間最長的任務扔掉，然后自己排隊
- ThreadPoolExecutor.CallerRunsPolicy：在任務提交者線程中執行任務，而不是交給線程池中的線程執行
它們都是ThreadPoolExecutor的public靜態內部類，都實現了RejectedExecutionHandler接口，這個接口的定義為：
public interface RejectedExecutionHandler { void rejectedExecution(Runnable r, ThreadPoolExecutor executor); }
當線程池不能接受任務時，調用其拒絕策略的rejectedExecution方法。
拒絕策略可以在構造方法中進行指定，也可以通過如下方法進行指定：
public void setRejectedExecutionHandler(RejectedExecutionHandler handler)
默認的RejectedExecutionHandler是一個AbortPolicy實例，如下所示：
private static final RejectedExecutionHandler defaultHandler = new AbortPolicy();
而AbortPolicy的rejectedExecution實現就是拋出異常，如下所示：
public void rejectedExecution(Runnable r, ThreadPoolExecutor e) { throw new RejectedExecutionException("Task " + r.toString() + " rejected from " + e.toString()); }
我們需要強調下，拒絕策略只有在隊列有界，且maximumPoolSize有限的情況下才會觸發。
如果隊列無界，服務不了的任務總是會排隊，但這不見得是期望的，因為請求處理隊列可能會消耗非常大的內存，甚至引發內存不夠的異常。
如果隊列有界但maximumPoolSize無限，可能會創建過多的線程，占滿CPU和內存，使得任何任務都難以完成。
所以，在任務量非常大的場景中，讓拒絕策略有機會執行是保證系統穩定運行很重要的方面。
線程工廠
線程池還可以接受一個參數，ThreadFactory，它是一個接口，定義為：
public interface ThreadFactory { Thread newThread(Runnable r); }
這個接口根據Runnable創建一個Thread，ThreadPoolExecutor的默認實現是Executors類中的靜態內部類DefaultThreadFactory，主要就是創建一個線程，給線程設置一個名稱，設置daemon屬性為false，設置線程優先級為標准默認優先級，線程名稱的格式為： pool-<線程池編號>-thread-<線程編號>。
如果需要自定義一些線程的屬性，比如名稱，可以實現自定義的ThreadFactory。
關於核心線程的特殊配置
線程個數小於等於corePoolSize時，我們稱這些線程為核心線程，默認情況下：
- 核心線程不會預先創建，只有當有任務時才會創建
- 核心線程不會因為空閑而被終止，keepAliveTime參數不適用於它
不過，ThreadPoolExecutor有如下方法，可以改變這個默認行為。
//預先創建所有的核心線程 public int prestartAllCoreThreads() //創建一個核心線程，如果所有核心線程都已創建，返回false public boolean prestartCoreThread() //如果參數為true，則keepAliveTime參數也適用於核心線程 public void allowCoreThreadTimeOut(boolean value)
工廠類Executors
類Executors提供了一些靜態工廠方法，可以方便的創建一些預配置的線程池，主要方法有：
public static ExecutorService newSingleThreadExecutor() public static ExecutorService newFixedThreadPool(int nThreads) public static ExecutorService newCachedThreadPool()
newSingleThreadExecutor基本相當於調用：
public static ExecutorService newSingleThreadExecutor() { return new ThreadPoolExecutor(1, 1, 0L, TimeUnit.MILLISECONDS, new LinkedBlockingQueue<Runnable>()); }
只使用一個線程，使用無界隊列LinkedBlockingQueue，線程創建后不會超時終止，該線程順序執行所有任務。該線程池適用於需要確保所有任務被順序執行的場合。
newFixedThreadPool的代碼為：
public static ExecutorService newFixedThreadPool(int nThreads) { return new ThreadPoolExecutor(nThreads, nThreads, 0L, TimeUnit.MILLISECONDS, new LinkedBlockingQueue<Runnable>()); }
使用固定數目的n個線程，使用無界隊列LinkedBlockingQueue，線程創建后不會超時終止。和newSingleThreadExecutor一樣，由於是無界隊列，如果排隊任務過多，可能會消耗非常大的內存。
newCachedThreadPool的代碼為：
public static ExecutorService newCachedThreadPool() { return new ThreadPoolExecutor(0, Integer.MAX_VALUE, 60L, TimeUnit.SECONDS, new SynchronousQueue<Runnable>()); }
它的corePoolSize為0，maximumPoolSize為Integer.MAX_VALUE，keepAliveTime是60秒，隊列為SynchronousQueue。
它的含義是，當新任務到來時，如果正好有空閑線程在等待任務，則其中一個空閑線程接受該任務，否則就總是創建一個新線程，創建的總線程個數不受限制，對任一空閑線程，如果60秒內沒有新任務，就終止。
實際中，應該使用newFixedThreadPool還是newCachedThreadPool呢？
在系統負載很高的情況下，newFixedThreadPool可以通過隊列對新任務排隊，保證有足夠的資源處理實際的任務，而newCachedThreadPool會為每個任務創建一個線程，導致創建過多的線程競爭CPU和內存資源，使得任何實際任務都難以完成，這時，newFixedThreadPool更為適用。
不過，如果系統負載不太高，單個任務的執行時間也比較短，newCachedThreadPool的效率可能更高，因為任務可以不經排隊，直接交給某一個空閑線程。
在系統負載可能極高的情況下，兩者都不是好的選擇，newFixedThreadPool的問題是隊列過長，而newCachedThreadPool的問題是線程過多，這時，應根據具體情況自定義ThreadPoolExecutor，傳遞合適的參數。
線程池的死鎖
關於提交給線程池的任務，我們需要特別注意一種情況，就是任務之間有依賴，這種情況可能會出現死鎖。比如任務A，在它的執行過程中，它給同樣的任務執行服務提交了一個任務B，但需要等待任務B結束。
如果任務A是提交給了一個單線程線程池，就會出現死鎖，A在等待B的結果，而B在隊列中等待被調度。
如果是提交給了一個限定線程個數的線程池，也有可能出現死鎖，我們看個簡單的例子：
public class ThreadPoolDeadLockDemo { private static final int THREAD_NUM = 5; static ExecutorService executor = Executors.newFixedThreadPool(THREAD_NUM); static class TaskA implements Runnable { @Override public void run() { try { Thread.sleep(100); } catch (InterruptedException e) { e.printStackTrace(); } Future<?> future = executor.submit(new TaskB()); try { future.get(); } catch (Exception e) { e.printStackTrace(); } System.out.println("finished task A"); } } static class TaskB implements Runnable { @Override public void run() { System.out.println("finished task B"); } } public static void main(String[] args) throws InterruptedException { for (int i = 0; i < 5; i++) { executor.execute(new TaskA()); } Thread.sleep(2000); executor.shutdown(); } }
以上代碼使用newFixedThreadPool創建了一個5個線程的線程池，main程序提交了5個TaskA，TaskA會提交一個TaskB，然后等待TaskB結束，而TaskB由於線程已被占滿只能排隊等待，這樣，程序就會死鎖。
怎么解決這種問題呢？
替換newFixedThreadPool為newCachedThreadPool，讓創建線程不再受限，這個問題就沒有了。
另一個解決方法，是使用SynchronousQueue，它可以避免死鎖，怎么做到的呢？對於普通隊列，入隊只是把任務放到了隊列中，而對於SynchronousQueue來說，入隊成功就意味着已有線程接受處理，如果入隊失敗，可以創建更多線程直到maximumPoolSize，如果達到了maximumPoolSize，會觸發拒絕機制，不管怎么樣，都不會死鎖。我們將創建executor的代碼替換為：
static ExecutorService executor = new ThreadPoolExecutor( THREAD_NUM, THREAD_NUM, 0, TimeUnit.SECONDS, new SynchronousQueue<Runnable>());
只是更改隊列類型，運行同樣的程序，程序不會死鎖，不過TaskA的submit調用會拋出異常RejectedExecutionException，因為入隊會失敗，而線程個數也達到了最大值。
小結
本節介紹了線程池的基本概念，詳細探討了其主要參數的含義，理解這些參數對於合理使用線程池是非常重要的，對於相互依賴的任務，需要特別注意，避免出現死鎖。
ThreadPoolExecutor實現了生產者/消費者模式，工作者線程就是消費者，任務提交者就是生產者，線程池自己維護任務隊列。當我們碰到類似生產者/消費者問題時，應該優先考慮直接使用線程池，而非重新發明輪子，自己管理和維護消費者線程及任務隊列。
在異步任務程序中，一種常見的場景是，主線程提交多個異步任務，然后有任務完成就處理結果，並且按任務完成順序逐個處理，對於這種場景，Java並發包提供了一個方便的方法，使用CompletionService，讓我們下一節來探討它。
(與其他章節一樣，本節所有代碼位於 https://github.com/swiftma/program-logic)
----------------
未完待續，查看最新文章，敬請關注微信公眾號“老馬說編程”(掃描下方二維碼)，從入門到高級，深入淺出，老馬和你一起探索Java編程及計算機技術的本質。用心原創，保留所有版權。
