小宇：閃客，我最近看到線程池，被里邊亂七八槽的參數給搞暈了，你能不能給我講講呀？
閃客：沒問題，這個我擅長，咱們從一個最簡單的情況開始，假設有一段代碼，你希望異步執行它，是不是要寫出這樣的代碼？
new Thread(r).start();
小宇：嗯嗯，最簡單的寫法似乎就是這樣呢。
閃客：這種寫法當然可以完成功能，可是你這樣寫，老王這樣寫，老張也這樣寫，程序中到處都是這樣創建線程的方法，能不能寫一個統一的工具類讓大家調用呢？
小宇：可以的，感覺有一個統一的工具類，更優雅一些。
閃客：那如果讓你來設計這個工具類，你會怎么寫呢？我先給你定一個接口，你來實現。
public interface Executor { public void execute(Runnable r); }
小宇：emmm，我可能先定義幾個成員變量，比如核心線程數、最大線程數 ...反正就是那些亂七八糟的參數。
閃客：STOP！小宇呀，你現在深受面試手冊的毒害，你先把這些全部的概念忘掉，就說讓你寫一個最簡單的工具類，第一反應，你會怎么寫？
第一版
小宇：那我可能會這樣
// 新線程：直接創建一個新線程運行
class FlashExecutor implements Executor {
public void execute(Runnable r) {
new Thread(r).start();
}
}
閃客：嗯嗯很好，你的思路非常棒。
小宇：啊，我這個會不會太 low 了呀，我還以為你會罵我呢。
怎么會， Doug Lea 大神在 JDK 源碼注釋中給出的就是這樣的例子，這是最根本的功能。你在這個基礎上，嘗試着優化一下？
第二版
小宇：還能怎么優化呢？這不已經用一個工具類實現了異步執行了嘛！
閃客：我問你一個問題，假如有 10000 個人都調用這個工具類提交任務，那就會創建 10000 個線程來執行，這肯定不合適吧！能不能控制一下線程的數量呢？
小宇：這不難，我可以把這個任務 r 丟到一個 tasks 隊列中，然后只啟動一個線程，就叫它 Worker 線程吧，不斷從 tasks 隊列中取任務，執行任務。這樣無論調用者調用多少次，永遠就只有一個 Worker 線程在運行，像這樣。
閃客：太棒了，這個設計有了三個重大的意義：
1. 控制了線程數量。
2. 隊列不但起到了緩沖的作用，還將任務的提交與執行解耦了。
3. 最重要的一點是，解決了每次重復創建和銷毀線程帶來的系統開銷。
小宇：哇真的么，這么小的改動有這么多意義呀。
閃客：那當然，不過只有一個后台的工作線程 Worker 會不會少了點？還有如果這個 tasks 隊列滿了怎么辦呢？
第三版
小宇：哦，的確，只有一個線程在某些場景下是很吃力的，那我把 Worker 線程的數量增加？
閃客：沒錯，Worker 線程的數量要增加，但是具體數量要讓使用者決定，調用時傳入，就叫核心線程數 corePoolSize 吧。
小宇：好的，那我這樣設計。
1. 初始化線程池時，直接啟動 corePoolSize 個工作線程 Worker 先跑着。
2. 這些 Worker 就是死循環從隊列里取任務然后執行。
3. execute 方法仍然是直接把任務放到隊列，但隊列滿了之后直接拋棄
閃客：太完美了，獎勵你一塊費列羅吧。
小宇：哈哈謝謝，那我先吃一會兒哈。
閃客：好，你邊吃我邊說。現在我們已經實現了一個至少不那么丑陋的線程池了，但還有幾處小瑕疵，比如初始化的時候，就創建了一堆 Worker 線程在那空跑着，假如此時並沒有異步任務提交過來執行，這就有點浪費了。
小宇：哦好像是誒！
閃客：還有，你這隊列一滿，就直接把新任務丟棄了，這樣有些粗暴，能不能讓調用者自己決定該怎么處理呢？
小宇：哎呀，想不到我這么溫柔的妹紙居然寫出了這么粗暴的代碼。
閃客：額，你先把費列羅咽下去吧。
第四版
小宇：我吃完了，現在腦子有點不夠用了，得先消化消化食物，要不你幫我分析分析吧。
閃客：好的，現在我們做出如下改進。
1. 按需創建Worker：剛初始化線程池時，不再立刻創建 corePoolSize 個工作線程，而是等待調用者不斷提交任務的過程中，逐漸把工作線程 Worker 創建出來，等數量達到 corePoolSize 時就停止，把任務直接丟到隊列里。那就必然要用一個屬性記錄已經創建出來的工作線程數量，就叫 workCount 吧。
2. 加拒絕策略：實現上就是增加一個入參，類型是一個接口 RejectedExecutionHandler，由調用者決定實現類，以便在任務提交失敗后執行 rejectedExecution 方法。
3. 增加線程工廠：實現上就是增加一個入參，類型是一個接口 ThreadFactory，增加工作線程時不再直接 new 線程，而是調用這個由調用者傳入的 ThreadFactory 實現類的 newThread 方法。
就像下面這樣。
小宇：哇，還是你厲害，這一版應該很完美了吧？ 閃客：不不不，離完美還差得很遠，接下來的改進，由你來想吧，我這里可以給你一個提示
彈性思維
第五版
小宇：彈性思維？哈哈閃客你這術語說的真是越來越不像人話了
閃客：咳咳
小宇：哦，我是說你肯定是指我這個代碼寫的沒有彈性，對吧？可是彈性是指什么呢？
閃客：簡單說，在這個場景里，彈性就是在任務提交比較頻繁，和任務提交非常不頻繁這兩種情況下，你這個代碼是否有問題？
小宇：emmm 讓我想想，我這個線程池，當提交任務的量突增時，工作線程和隊列都被占滿了，就只能走拒絕策略，其實就是被丟棄掉
閃客：是的
小宇：這樣的確是太硬了，誒不過我想了下，調用方可以通過設置很大的核心線程數 corePoolSize 來解決這個問題呀。
閃客：的確是可以，但一般場景下 QPS 高峰期都很短，而為了這個很短暫的高峰，設置很大的核心線程數，簡直太浪費資源了，你看上面的圖不覺得眼暈么？
小宇：是呀，那怎么辦呢，太大了也不行，太小了也不行。
閃客：我們可以發明一個新的屬性，叫最大線程數 maximumPoolSize 。當核心線程數和隊列都滿了時，新提交的任務仍然可以通過創建新的工作線程（叫它 非核心線程 ），直到工作線程數達到 maximumPoolSize 為止，這樣就可以緩解一時的高峰期了，而用戶也不用設置過大的核心線程數。
小宇：哦好像有點感覺了，可是具體怎么操作呢？ 閃客：想象力不行呀小宇，那你看下面的演示。
1. 開始的時候和上一版一樣，當 workCount < corePoolSize 時，通過創建新的 Worker 來執行任務。
2. 當 workCount >= corePoolSize 就停止創建新線程，把任務直接丟到隊列里。
3. 但當隊列已滿且仍然 workCount < maximumPoolSize 時，不再直接走拒絕策略，而是創建非核心線程，直到 workCount = maximumPoolSize，再走拒絕策略。
小宇：哎呀，我怎么沒想到，這樣 corePoolSize 就負責平時大多數情況所需要的工作線程數，而 maximumPoolSize 就負責在高峰期臨時擴充工作線程數。
閃客：沒錯，高峰時期的彈性搞定了，那自然就還要考慮低谷時期。當長時間沒有任務提交時，核心線程與非核心線程都一直空跑着，浪費資源。我們可以給非核心線程設定一個超時時間 keepAliveTime ，當這么長時間沒能從隊列里獲取任務時，就不再等了，銷毀線程。
小宇：嗯，這回咱們的線程池在 QPS 高峰時可以臨時擴容，QPS 低谷時又可以及時回收線程（非核心線程）而不至於浪費資源，真的顯得十分 Q 彈呢。
閃客：是呀是呀。誒不對，怎么又變成我說了，不是說這一版你來思考么？
小宇：我也想啊，但你這一講技術就自說自話的毛病老是不改，我有啥辦法。 閃客：額抱歉抱歉，那接下來你總結一下我們的線程池吧
總結
小宇：嗯好的，首先它的構造方法是這個樣子滴
public FlashExecutor( int corePoolSize, int maximumPoolSize, long keepAliveTime, TimeUnit unit, BlockingQueue<Runnable> workQueue, ThreadFactory threadFactory, RejectedExecutionHandler handler) { ... // 省略一些參數校驗 this.corePoolSize = corePoolSize; this.maximumPoolSize = maximumPoolSize; this.workQueue = workQueue; this.keepAliveTime = unit.toNanos(keepAliveTime); this.threadFactory = threadFactory; this.handler = handler; }
這些參數分別是
int corePoolSize：核心線程數
int maximumPoolSize：最大線程數
long keepAliveTime：非核心線程的空閑時間
TimeUnit unit：空閑時間的單位
BlockingQueue<Runnable> workQueue：任務隊列（線程安全的阻塞隊列）
ThreadFactory threadFactory：線程工廠
RejectedExecutionHandler handler：拒絕策略
整個任務的提交流程是
閃客：不錯不錯，這可是你自己總結的喲，現在還用我給你講什么是線程池了么？
小宇：啊天呢，我才發現這似乎就是我一直弄不清楚的線程池的參數和原理呢！
閃客：沒錯，而且最后一版代碼的構造方法，就是 Java 面試常考的 ThreadPoolExecutor 最長的那個構造方法，參數名都沒變。
小宇：哇，太贊了！我都忘了一開始我想干嘛了，嘻嘻。
閃客：哈哈，不知不覺學到了技術才爽呢，對吧？晚飯時間快到了，要不要一塊去吃山西面館呀？
小宇：哦，那家店餐桌的顏色我不太喜歡，下次吧。
閃客：哦好吧。
后記
線程池是面試常考的知識點，網上很多文章都是直接從它那有 7 個參數的構造方法講起，強行把各個參數的含義說給你聽，讓人雲里霧里。 希望讀者讀完本篇文章后，線程池的這些參數不再是死記硬背，而是像本文中這些動圖一樣在你的腦中活靈活現，這樣就能永遠記住他們啦~ 本文中各個版本都有對應代碼，在公眾號 低並發編程 后台回復 線程池 即可獲取。