聊到 Java 并發(fā)線程池是繞不開的高頻考點(diǎn)。生產(chǎn)環(huán)境的每個(gè)高并發(fā)接口、每一條異步消息消費(fèi)鏈路背后幾乎都是 ThreadPoolExecutor 在撐著。很多人背得出核心參數(shù)、能默寫出四種拒絕策略可一旦遇上詭異問題——比如線程數(shù)漲到最大卻沒人干活、shutdown 后進(jìn)程卡住不退出、任務(wù)明明提交了卻石沉大海——就束手無策。原因只有一個(gè)只記住了 API 表面沒吃透它的實(shí)現(xiàn)原理。這篇文章我就帶你把 ThreadPoolExecutor 從源碼層面完整拆一遍。從 ctl 那個(gè)“一個(gè)變量管兩件事”的設(shè)計(jì)到 execute 的三次機(jī)會(huì)、Worker 的任務(wù)循環(huán)、五個(gè)狀態(tài)的生命周期遷移再到線上排查的真實(shí)坑全部講透。適合剛學(xué)完 Java 并發(fā)的同學(xué)建立完整認(rèn)知也適合工作了幾年的開發(fā)者排查線程池問題時(shí)回來翻一翻搞懂原理之后很多現(xiàn)象其實(shí)一眼就能看出根因。1. 從構(gòu)造參數(shù)看線程池的核心設(shè)計(jì)1.1 七個(gè)參數(shù)如何配合線程才不會(huì)“白養(yǎng)”也不會(huì)“爆倉”先看最常用的構(gòu)造函數(shù)public ThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long keepAliveTime, TimeUnit unit, BlockingQueueRunnable workQueue, ThreadFactory threadFactory, RejectedExecutionHandler handler)七個(gè)參數(shù)各管一塊理解它們是入門的第一道坎。corePoolSize核心線程數(shù)。這些線程是線程池的“常住人口”即使空閑也不會(huì)被回收除非你把 allowCoreThreadTimeOut 設(shè)為 true。任務(wù)還沒來的時(shí)候默認(rèn)不會(huì)提前創(chuàng)建只有提交第一個(gè)任務(wù)時(shí)才逐步創(chuàng)建。maximumPoolSize最大線程數(shù)。線程池允許同時(shí)存在的線程數(shù)量上限超出這個(gè)數(shù)新任務(wù)只能走拒絕策略。keepAliveTime unit非核心線程的空閑存活時(shí)間。當(dāng)線程數(shù)超過 corePoolSize多出來的“臨時(shí)工”空閑超過這個(gè)時(shí)間就會(huì)被回收。這個(gè)參數(shù)很容易踩坑因?yàn)槟J(rèn)情況下核心線程不受 keepAliveTime 控制。workQueue任務(wù)緩沖隊(duì)列。核心線程全忙時(shí)新任務(wù)先進(jìn)隊(duì)列等待而不是立刻建新線程。threadFactory線程工廠?？刂凭€程命名、是否守護(hù)、優(yōu)先級(jí)等。生產(chǎn)環(huán)境強(qiáng)烈建議自定義否則日志里全是 pool-1-thread-1排查問題非常痛苦。handler拒絕策略。隊(duì)列滿了且線程數(shù)也達(dá)到上限時(shí)新任務(wù)觸發(fā)拒絕策略。這七個(gè)參數(shù)內(nèi)部是有明確的協(xié)作順序的很多人在這里記反了一個(gè)關(guān)鍵點(diǎn)——核心線程滿后不是“立刻膨脹到最大線程數(shù)”而是先排隊(duì)。只有隊(duì)列也滿了才會(huì)去創(chuàng)建非核心線程。如果非核心線程也達(dá)到上限才會(huì)觸發(fā)拒絕策略。我常用一個(gè)營業(yè)廳模型來理解核心線程是固定柜臺(tái)隊(duì)列是等候區(qū)非核心線程是臨時(shí)加開的柜臺(tái)。固定柜臺(tái)全在辦業(yè)務(wù)客戶先去等候區(qū)排隊(duì)等候區(qū)滿了才加開臨時(shí)柜臺(tái)臨時(shí)柜臺(tái)也滿了再有客戶進(jìn)門就只能拒絕服務(wù)。這個(gè)模型對應(yīng)代碼邏輯幾乎一一匹配后面第 2 章會(huì)看到 execute 方法本身就是按這個(gè)順序?qū)懙摹?.2 看懂 ctl 這個(gè)魔法變量一個(gè)值同時(shí)保存狀態(tài)和線程數(shù)在進(jìn)入 execute 之前必須先認(rèn)識(shí)線程池里最核心的字段ctl。它是個(gè) AtomicInteger但只用了一個(gè) int 就同時(shí)保存了兩個(gè)信息——線程池運(yùn)行狀態(tài)runState和工作線程數(shù)workerCount。private final AtomicInteger ctl new AtomicInteger(ctlOf(RUNNING, 0)); private static final int COUNT_BITS Integer.SIZE - 3; // 29 private static final int CAPACITY (1 COUNT_BITS) - 1; // 2^29 - 1 private static int runStateOf(int c) { return c ~CAPACITY; } private static int workerCountOf(int c) { return c CAPACITY; } private static int ctlOf(int rs, int wc) { return rs | wc; }設(shè)計(jì)是這樣的高 3 位存 runState低 29 位存 workerCount。所以 workerCount 的理論上限是(1 29) - 1約 5 億實(shí)際開發(fā)中幾乎不可能觸頂addWorker 里的 CAPACITY 判斷只是留個(gè)安全邊界。為什么這么設(shè)計(jì)核心原因是“原子性”。線程池的狀態(tài)和線程數(shù)經(jīng)常需要同時(shí)變化比如 shutdown 時(shí)把狀態(tài)從 RUNNING 改成 SHUTDOWN同時(shí)希望線程數(shù)不被干擾。如果分兩個(gè)字段就得加鎖保證一致性合成一個(gè) int 放進(jìn) AtomicInteger一次 CAS 就能同時(shí)修改兩部分性能和安全兼顧。五個(gè)狀態(tài)的具體值也很講究狀態(tài)數(shù)值行為說明RUNNING-1 29負(fù)數(shù)接收新任務(wù)處理隊(duì)列任務(wù)SHUTDOWN0不接收新任務(wù)但繼續(xù)處理隊(duì)列任務(wù)STOP1 29不接收新任務(wù)不處理隊(duì)列任務(wù)中斷所有線程TIDYING2 29所有任務(wù)已結(jié)束workerCount 為 0即將執(zhí)行 terminated()TERMINATED3 29terminated() 執(zhí)行完畢徹底結(jié)束注意一個(gè)反直覺的細(xì)節(jié)RUNNING 是負(fù)數(shù)所以狀態(tài)之間的數(shù)值比較是RUNNING SHUTDOWN STOP TIDYING TERMINATED。源碼里大量使用runStateLessThan(c, STOP)或runStateAtLeast(c, STOP)這類判斷本質(zhì)上就是利用這個(gè)單調(diào)遞增的數(shù)值鏈來做范圍判斷?？炊@個(gè)后面讀源碼就能順下來。2. 任務(wù)提交的完整鏈路execute 的三次機(jī)會(huì)2.1 源碼級(jí)拆解 execute核心線程、隊(duì)列、非核心線程的優(yōu)先級(jí)任務(wù)提交的入口是 execute 方法submit 底層也會(huì)轉(zhuǎn)到這里。JDK 1.8 的源碼非常緊湊邏輯全部濃縮在幾行里public void execute(Runnable command) { if (command null) throw new NullPointerException(); int c ctl.get(); // 第一次機(jī)會(huì)核心線程未滿 if (workerCountOf(c) corePoolSize) { if (addWorker(command, true)) return; c ctl.get(); } // 第二次機(jī)會(huì)線程池還在運(yùn)行嘗試入隊(duì) if (isRunning(c) workQueue.offer(command)) { int recheck ctl.get(); if (!isRunning(recheck) remove(command)) reject(command); else if (workerCountOf(recheck) 0) addWorker(null, false); } // 第三次機(jī)會(huì)隊(duì)列滿了嘗試創(chuàng)建非核心線程 else if (!addWorker(command, false)) reject(command); }逐個(gè)拆開看。第一次機(jī)會(huì)只要當(dāng)前工作線程數(shù)小于 corePoolSize就直接 addWorker(command, true)創(chuàng)建核心線程并立刻執(zhí)行任務(wù)。這里有個(gè)細(xì)節(jié)如果 addWorker 失敗比如線程池剛好被 shutdown需要重新讀取 ctl因?yàn)閯偛诺?c 已經(jīng)過期了。第二次機(jī)會(huì)核心線程滿了進(jìn)入隊(duì)列。入隊(duì)前要判斷線程池是否還在 RUNNING 狀態(tài)只有運(yùn)行中才允許入隊(duì)。入隊(duì)成功不等于萬事大吉緊接著有一個(gè) recheck雙重檢查。這個(gè) recheck 非常關(guān)鍵因?yàn)槿腙?duì)和 recheck 之間線程池可能被另一個(gè)線程調(diào)用了 shutdown此時(shí)池狀態(tài)變了但任務(wù)已經(jīng)進(jìn)了隊(duì)列如果不做處理這個(gè)任務(wù)可能永遠(yuǎn)等不到執(zhí)行。所以發(fā)現(xiàn)狀態(tài)已經(jīng)不是 RUNNING就調(diào)用 remove(command) 把任務(wù)從隊(duì)列移除然后走拒絕策略。recheck 里還有個(gè)隱藏邏輯如果 recheck 時(shí)發(fā)現(xiàn) workerCount 為 0需要 addWorker(null, false) 補(bǔ)一個(gè)非核心線程。為什么因?yàn)榭赡艹霈F(xiàn)了“共享池但核心線程全部退出”的極端情況比如啟用了 allowCoreThreadTimeOut如果不補(bǔ)線程隊(duì)列里的任務(wù)就永遠(yuǎn)沒人消費(fèi)了。第三次機(jī)會(huì)入隊(duì)失敗說明隊(duì)列滿了此時(shí)嘗試 addWorker(command, false) 創(chuàng)建非核心線程。如果這也失敗說明線程數(shù)已經(jīng)達(dá)到 maximumPoolSize只能 reject。整個(gè)流程非常清晰地體現(xiàn)了線程池的哲學(xué)能復(fù)用核心線程就復(fù)用復(fù)用不了就緩沖緩沖不下才擴(kuò)編擴(kuò)編還不行就拒絕。我建議讀者把 execute 這段源碼背下來面試手撕題和實(shí)際排查都會(huì)用到。2.2 addWorker 的雙重校驗(yàn)與線程啟動(dòng)細(xì)節(jié)addWorker 是真正干活的地方。這個(gè)方法做了兩件事先通過 CAS 把 workerCount 加上去再創(chuàng)建 Worker 對象、啟動(dòng)線程。源碼較長核心骨架如下private boolean addWorker(Runnable firstTask, boolean core) { retry: for (;;) { int c ctl.get(); int rs runStateOf(c); // 第一道攔截狀態(tài)不允許 if (rs SHUTDOWN !(rs SHUTDOWN firstTask null)) return false; for (;;) { int wc workerCountOf(c); if (wc CAPACITY || wc (core ? corePoolSize : maximumPoolSize)) return false; if (compareAndIncrementWorkerCount(c)) break retry; c ctl.get(); if (runStateOf(c) ! rs) continue retry; } } // 之后是創(chuàng)建 Worker、加鎖、再次檢查、啟動(dòng)線程 ... }第一道攔截判斷池狀態(tài)如果已經(jīng) SHUTDOWN 以上通常不允許再創(chuàng)建線程。但保留了一個(gè)特例——rs SHUTDOWN firstTask null也就是允許在 SHUTDOWN 狀態(tài)下創(chuàng)建一個(gè)“空轉(zhuǎn)線程”。這是為了處理 2.1 里那種 workerCount 為 0 但隊(duì)列還有任務(wù)的情況線程池必須允許補(bǔ)一個(gè)線程去把剩余任務(wù)消費(fèi)完。第二道攔截判斷線程數(shù)不能超過 CAPACITY也不能超過 corePoolSize 或 maximumPoolSize根據(jù) core 參數(shù)選擇。CAS 失敗就重試如果期間線程池狀態(tài)變了就跳回 retry 重新做狀態(tài)檢查避免用舊狀態(tài)做出錯(cuò)誤判斷。創(chuàng)建 Worker 并啟動(dòng)線程的部分也很講究。拿到 Worker 和 thread 之后需要加 mainLock 鎖。這個(gè)鎖的作用是保護(hù) workers 集合同時(shí)保證與 shutdown 的 interruptIdleWorkers 操作互斥。加鎖后還要再檢查一次池狀態(tài)確認(rèn)沒有在創(chuàng)建期間被 shutdown 或 stop確認(rèn)安全才 t.start() 啟動(dòng)線程。這里有個(gè)小細(xì)節(jié)如果 t.start() 因?yàn)?ThreadFactory 返回的線程為 null 或啟動(dòng)異常addWorker 會(huì)把已經(jīng)加上的 workerCount 回滾并把 Worker 從集合移除。所以 addWorker 失敗時(shí)線程池的線程數(shù)不會(huì)虛高。提示很多人以為 addWorker 只是“new 一個(gè)線程然后 start”其實(shí)它做了狀態(tài)校驗(yàn)、CAS 計(jì)數(shù)、加鎖、二次校驗(yàn)、啟動(dòng)、異常回滾六件事。只記住一個(gè)“創(chuàng)建線程”是遠(yuǎn)遠(yuǎn)不夠的。3. Worker 線程的運(yùn)作模型用任務(wù)循環(huán)理解整個(gè)生命周期3.1 為什么 Worker 要繼承 AQS不可重入鎖的設(shè)計(jì)意圖Worker 是 ThreadPoolExecutor 的內(nèi)部類同時(shí)也是線程池真正“干活”的單元。它本身實(shí)現(xiàn)了 Runnable又繼承了 AbstractQueuedSynchronizerprivate final class Worker extends AbstractQueuedSynchronizer implements Runnable { final Thread thread; Runnable firstTask; volatile long completedTasks; }一個(gè)很自然的疑問是為什么不直接 new Thread 跑任務(wù)非要套一個(gè) Worker 類答案在于 Worker 給它自己裝了一把鎖。這把鎖是不可重入的互斥鎖它和任務(wù)執(zhí)行狀態(tài)嚴(yán)格綁定執(zhí)行任務(wù)前 lock執(zhí)行完 unlock。外部代碼通過 tryLock 就能判斷這個(gè) worker 是否空閑。這個(gè)判斷是 shutdown 機(jī)制的核心?？?interruptIdleWorkers 的實(shí)現(xiàn)邏輯for (Worker w : workers) { Thread t w.thread; if (!t.isInterrupted() w.tryLock()) { try { t.interrupt(); } finally { w.unlock(); } } }tryLock 成功說明 worker 當(dāng)前沒有在跑任務(wù)鎖是空閑的可以安全中斷tryLock 失敗說明它正在執(zhí)行任務(wù)不能中斷否則會(huì)把一個(gè)正在跑的業(yè)務(wù)邏輯打斷。為什么不用 ReentrantLock關(guān)鍵在于“不可重入”。如果換成可重入鎖同一個(gè)線程在持有鎖的過程中再次獲取鎖也能成功那 tryLock 就無法準(zhǔn)確反映“該 worker 是否正在執(zhí)行任務(wù)”。ThreadPoolExecutor 需要的是“已鎖 執(zhí)行中”這個(gè)強(qiáng)等價(jià)關(guān)系所以 JDK 特意用 AQS 實(shí)現(xiàn)了一個(gè)非重入鎖而不是直接復(fù)用 ReentrantLock。Worker 還有一個(gè)很隱蔽的初始化細(xì)節(jié)構(gòu)造函數(shù)里會(huì) setState(-1)而不是 0。這是為了讓 worker 在真正進(jìn)入 runWorker 之前不會(huì)被 interruptIdleWorkers 誤判為空閑線程給中斷掉。runWorker 一開頭會(huì)執(zhí)行 unlock() 把狀態(tài)恢復(fù)為 0從此才允許被外部中斷。這個(gè)防“搶跑中斷”的設(shè)計(jì)許多人看源碼都不會(huì)注意到但正是它保證了線程初始化期的安全。3.2 runWorker 主循環(huán)與 getTask 的四個(gè)出口Worker 啟動(dòng)后線程就跑進(jìn)了 runWorker 方法這是線程池工作的主循環(huán)final void runWorker(Worker w) { Thread wt Thread.currentThread(); Runnable task w.firstTask; w.firstTask null; w.unlock(); // 恢復(fù)可中斷狀態(tài) boolean completedAbruptly true; try { while (task ! null || (task getTask()) ! null) { w.lock(); // 池處于 STOP 及以上狀態(tài)需要設(shè)置中斷標(biāo)志 if ((runStateAtLeast(ctl.get(), STOP) || (Thread.interrupted() runStateAtLeast(ctl.get(), STOP))) !wt.isInterrupted()) wt.interrupt(); try { beforeExecute(wt, task); Throwable thrown null; try { task.run(); } catch (RuntimeException x) { thrown x; throw x; } catch (Error x) { thrown x; throw x; } catch (Throwable x) { thrown x; throw new Error(x); } finally { afterExecute(task, thrown); } } finally { task null; w.completedTasks; w.unlock(); } } completedAbruptly false; } finally { processWorkerExit(w, completedAbruptly); } }主循環(huán)的邏輯是先拿 firstTask拿不到就阻塞等待 getTask() 從隊(duì)列取任務(wù)。拿到任務(wù)后 lock設(shè)置中斷狀態(tài)如果池已 STOP執(zhí)行任務(wù)前后調(diào)用 beforeExecute / afterExecute 鉤子任務(wù)結(jié)束后統(tǒng)計(jì) completedTasks 并 unlock。循環(huán)直到 getTask 返回 null最后進(jìn)入 processWorkerExit 收尾。如果任務(wù)執(zhí)行拋出了 RuntimeException 或 Error會(huì)直接向上拋導(dǎo)致線程退出。這看起來可怕但線程池有補(bǔ)救機(jī)制processWorkerExit 會(huì)在 finally 中檢測到 completedAbruptly 為 true然后補(bǔ)充一個(gè)新 Worker。所以單次任務(wù)的異常不會(huì)把線程池打到“沒人可用”的狀態(tài)反而會(huì)自動(dòng)換一個(gè)線程繼續(xù)扛活。getTask 是決定 worker 生死的取任務(wù)邏輯它一共有四個(gè)出口。第一個(gè)出口池狀態(tài)已經(jīng) SHUTDOWN 且隊(duì)列為空或者池狀態(tài)已經(jīng)達(dá)到 STOPgetTask 直接返回 null。此時(shí)線程退出線程池進(jìn)入“收拾尾聲”的階段。第二個(gè)出口workerCount 大于 maximumPoolSize。這個(gè)情況通常發(fā)生在運(yùn)行時(shí)調(diào)用 setMaximumPoolSize 把上限調(diào)小了多出來的線程需要盡快退出。第三個(gè)出口超時(shí)未取到任務(wù)。timed allowCoreThreadTimeOut || wc corePoolSize當(dāng)線程數(shù)超過核心數(shù)、或允許核心線程超時(shí)時(shí)用workQueue.poll(keepAliveTime)等待超時(shí)拿不到任務(wù)就返回 null。這里有一個(gè)安全條件wc 1 || workQueue.isEmpty()也就是說池里最后一個(gè)線程在隊(duì)列非空時(shí)不能因?yàn)槌瑫r(shí)退出否則隊(duì)列里剩下的任務(wù)就沒人處理了。第四個(gè)出口被中斷。線程在 take 或 poll 時(shí)被 interrupt 后會(huì)回到循環(huán)頂部重新檢查狀態(tài)如果碰上池已經(jīng) SHUTDOWN就會(huì)走第一個(gè)出口退出。這也是 shutdown 后所有線程能陸續(xù)結(jié)束的原理。核心線程能不能被回收就藏在這個(gè) getTask 里。默認(rèn)情況下allowCoreThreadTimeOut false核心線程走workQueue.take()無限期阻塞永遠(yuǎn)等待任務(wù)所以不會(huì)被回收。只有顯式開啟 allowCoreThreadTimeOut核心線程才會(huì)變成“臨時(shí)工”享受同樣的超時(shí)回收待遇。這個(gè)參數(shù)要謹(jǐn)慎開啟它改變了線程池“保持核心線程常駐”的語義但也避免了低峰期線程白白占內(nèi)存。4. 線程池狀態(tài)機(jī)從 RUNNING 到 TERMINATED 的完整遷徙4.1 五種狀態(tài)各自的權(quán)限與遷移路徑前面列了五個(gè)狀態(tài)的數(shù)值這里再從行為角度梳理一遍它們在“接收新任務(wù)、處理隊(duì)列任務(wù)、中斷線程”三個(gè)維度上的權(quán)限差異狀態(tài)接收新任務(wù)處理隊(duì)列任務(wù)中斷工作線程RUNNING允許允許否SHUTDOWN拒絕允許只中斷空閑線程STOP拒絕拒絕中斷所有線程TIDYING拒絕拒絕已無線程TERMINATED拒絕拒絕已結(jié)束狀態(tài)遷移路徑只有五條RUNNING - SHUTDOWN調(diào)用 shutdown()RUNNING 或 SHUTDOWN - STOP調(diào)用 shutdownNow()SHUTDOWN - TIDYING隊(duì)列已空workerCount 為 0STOP - TIDYINGworkerCount 為 0TIDYING - TERMINATEDterminated() 鉤子執(zhí)行完畢真正推動(dòng)狀態(tài)從 SHUTDOWN/STOP 走到 TIDYING 的核心方法是 tryTerminate。它的判斷邏輯很精巧for (;;) { int c ctl.get(); // 運(yùn)行中直接返回已終止也返回 // SHUTDOWN 且隊(duì)列非空說明任務(wù)還沒消費(fèi)完不能終止 if (isRunning(c) || runStateAtLeast(c, TIDYING) || (runStateOf(c) SHUTDOWN !workQueue.isEmpty())) return; // 還有存活線程中斷一個(gè)空閑線程推動(dòng)其退出 if (workerCountOf(c) ! 0) { interruptIdleWorkers(true); return; } // 線程數(shù)為 0CAS 到 TIDYING執(zhí)行 terminated()然后置 TERMINATED ... }注意 workerCount 不為 0 時(shí)它不會(huì)傻等而是中斷一個(gè)空閑線程讓這個(gè)線程在 getTask 的下一次循環(huán)里發(fā)現(xiàn)狀態(tài)變化而退出從而逐步收斂到 0。這就是“中斷一個(gè)空閑線程”代替“阻塞等待所有線程結(jié)束”的推進(jìn)策略避免 tryTerminate 被卡死。4.2 shutdown 與 shutdownNow優(yōu)雅關(guān)閉和強(qiáng)制關(guān)閉的區(qū)別這兩個(gè)方法名字像語義差別非常大實(shí)際使用中經(jīng)常被搞混。shutdown 走的是 SHUTDOWN 狀態(tài)它只做三件事狀態(tài)改為 SHUTDOWN、中斷所有空閑線程、執(zhí)行 onShutdown 鉤子。注意它不會(huì)中斷正在執(zhí)行任務(wù)的線程也不會(huì)清除隊(duì)列里尚未執(zhí)行的任務(wù)。也就是說調(diào)用 shutdown 之后線程池會(huì)像一個(gè)已經(jīng)下班但還留在工位上把手頭活兒干完的同事把隊(duì)列里的任務(wù)全部處理干凈才進(jìn)入終止流程。shutdownNow 則完全不同。它把狀態(tài)直接推到 STOP然后中斷所有線程最后把隊(duì)列中還沒執(zhí)行的任務(wù) drain 出來作為 List 返回。調(diào)用方拿到這個(gè) List就能知道哪些任務(wù)“還沒干成”可以自行處置。維度shutdownshutdownNow移入的狀態(tài)SHUTDOWNSTOP未開始的任務(wù)繼續(xù)處理返回未執(zhí)行列表不再處理正在執(zhí)行的任務(wù)不中斷讓它跑完發(fā)送中斷信號(hào)是否能強(qiáng)制終止任務(wù)否否任務(wù)需響應(yīng)中斷最后一點(diǎn)值得強(qiáng)調(diào)shutdownNow 的“中斷所有線程”只是給線程發(fā)送中斷標(biāo)志。如果任務(wù)代碼不檢查中斷標(biāo)志、不響應(yīng) InterruptedException正在執(zhí)行的 run 方法照樣會(huì)跑完。很多“shutdownNow 之后池子還在跑”的疑問根因就在這里——任務(wù)本身不配合中斷。4.3 鉤子方法、awaitTermination 與監(jiān)控?cái)U(kuò)展ThreadPoolExecutor 留了三個(gè)擴(kuò)展點(diǎn)beforeExecute、afterExecute、terminated。默認(rèn)它們都是空實(shí)現(xiàn)子類重寫后可以實(shí)現(xiàn)很多實(shí)用功能。beforeExecute 在任務(wù)執(zhí)行前調(diào)用可以記錄任務(wù)開始時(shí)間、往 ThreadLocal 寫入交易號(hào)afterExecute 在任務(wù)執(zhí)行后調(diào)用哪怕任務(wù)拋了異常也會(huì)進(jìn)入這里異常信息放在第二個(gè)參數(shù) thrown 里是最可靠的“任務(wù)異常觀測點(diǎn)”。terminated 則在池走完 TIDYING 后、變成 TERMINATED 前執(zhí)行適合做資源清理、記錄最終統(tǒng)計(jì)指標(biāo)。awaitTermination 是等待池終止的利器。調(diào)用 shutdown 之后如果想確認(rèn)線程池真的結(jié)束了再去做后續(xù)操作可以用它做超時(shí)等待返回 true 表示池已經(jīng)進(jìn)入 TERMINATED返回 false 表示超時(shí)仍未結(jié)束。生產(chǎn)環(huán)境的應(yīng)用關(guān)閉流程基本標(biāo)配就是 shutdown awaitTermination 超時(shí)后的強(qiáng)制兜底。提示重寫 beforeExecute/afterExecute 時(shí)不要拋異常。尤其是 beforeExecute 一旦拋異常任務(wù)本身不會(huì)執(zhí)行而且 worker 會(huì)直接退出處理起來異常麻煩。5. 參數(shù)調(diào)優(yōu)與實(shí)戰(zhàn)推演隊(duì)列、拒絕策略和線程數(shù)怎么配5.1 核心線程數(shù)到底該設(shè)多少從公式到壓測線程數(shù)設(shè)多少是 ThreadPoolExecutor 配置里最玄學(xué)的問題。網(wǎng)上流傳兩個(gè)通用公式CPU 密集型設(shè) N1N 是 CPU 核數(shù)IO 密集型設(shè) N * (1 等待時(shí)間 / 計(jì)算時(shí)間)。這兩個(gè)公式能用但只能作為起點(diǎn)。原因很簡單真實(shí)業(yè)務(wù)很少是純 CPU 或純 IO中間還有鎖競爭、GC、網(wǎng)絡(luò)抖動(dòng)公式算出的數(shù)大概率不是最優(yōu)值。我更建議按這個(gè)思路落地先估算單任務(wù)的平均計(jì)算耗時(shí)和平均等待耗時(shí)代入 IO 密集型公式得出一個(gè)初始線程數(shù)然后把隊(duì)列長度設(shè)為“在目標(biāo)響應(yīng)時(shí)長內(nèi)最多能積壓的任務(wù)數(shù)”最后用壓測工具逐步加壓觀察三個(gè)核心指標(biāo)——activeCount 是否穩(wěn)定、queueSize 是否持續(xù)上漲、有沒有拒絕異常。如果 activeCount 還沒到 max 就開始拒絕說明隊(duì)列太短或線程數(shù)偏低如果 queueSize 一直漲但 activeCount 很低說明任務(wù)在等鎖或者線程在空轉(zhuǎn)。還有一個(gè)很容易被忽視的維度線程不是越多越好。超過一定數(shù)量后CPU 上下文切換開銷會(huì)吃掉并發(fā)紅利線程內(nèi)存占用每個(gè)線程默認(rèn)棧約 1MB也會(huì)成為隱性成本。生產(chǎn)環(huán)境寧可把線程數(shù)調(diào)得保守一點(diǎn)靠有界隊(duì)列和拒絕策略做防護(hù)也不要一次性把 maximumPoolSize 拉滿。5.2 隊(duì)列選型與四種拒絕策略的本質(zhì)隊(duì)列決定了線程池的“緩沖能力”選錯(cuò)隊(duì)列參數(shù)調(diào)得再合理都可能失效。四種常見隊(duì)列各有脾性隊(duì)列特性適用場景ArrayBlockingQueue有界固定容量底層數(shù)組生產(chǎn)環(huán)境默認(rèn)首選能兜底限流LinkedBlockingQueue默認(rèn)容量無限可指定容量無界時(shí)吞吐穩(wěn)定但任務(wù)積壓會(huì)占滿內(nèi)存SynchronousQueue不存任務(wù)直接交接給線程配合 CachedThreadPool線程按需飆升PriorityBlockingQueue無界按優(yōu)先級(jí)出隊(duì)需要任務(wù)優(yōu)先級(jí)時(shí)使用但仍要防堆積一個(gè)重要的認(rèn)知如果隊(duì)列是無界的maximumPoolSize 其實(shí)形同虛設(shè)。因?yàn)殛?duì)列永遠(yuǎn)不會(huì)滿execute 的第三次機(jī)會(huì)永遠(yuǎn)走不到非核心線程也就不會(huì)被創(chuàng)建任務(wù)只會(huì)越積越多直到內(nèi)存撐爆。所以生產(chǎn)環(huán)境一定要優(yōu)先有界隊(duì)列給線程池一個(gè)明確的“承載力邊界”。拒絕策略有四種內(nèi)置實(shí)現(xiàn)外加自定義方案AbortPolicy默認(rèn)策略直接拋 RejectedExecutionException。好處是錯(cuò)誤明顯壞處是調(diào)用方?jīng)]有心理準(zhǔn)備容易崩。CallerRunsPolicy誰提交誰執(zhí)行。提交任務(wù)的線程親自把任務(wù)跑掉等于把壓力傳導(dǎo)回去天然形成背壓而且不丟任務(wù)。我比較偏愛這個(gè)策略。DiscardPolicy靜默丟棄。適合日志、打點(diǎn)這類允許丟的任務(wù)但丟之前最好在自定義 handler 里記一條告警。DiscardOldestPolicy丟棄隊(duì)列里最早的任務(wù)再嘗試提交新任務(wù)。適合不介意丟舊任務(wù)、只要新任務(wù)的場景。實(shí)際項(xiàng)目中重要業(yè)務(wù)任務(wù)我一般用 CallerRunsPolicy防止高峰直接拋異常導(dǎo)致接口 5xx非核心的埋點(diǎn)、日志用 DiscardPolicy 并配告警對賬、訂單這類絕對不能丟的任務(wù)則自定義 handler把失敗任務(wù)寫入本地緩沖由補(bǔ)償任務(wù)重放。5.3 提交20個(gè)任務(wù)推出的完整走向理論講再多不如推演一遍。假設(shè) corePoolSize2maximumPoolSize5workQueue 容量為 10連續(xù)提交 20 個(gè)任務(wù)逐條跟蹤提交序號(hào)線程池行為當(dāng)前線程數(shù)隊(duì)列長度1創(chuàng)建核心線程執(zhí)行102創(chuàng)建核心線程執(zhí)行203入隊(duì)等待214~12繼續(xù)入隊(duì)22~1013隊(duì)列滿創(chuàng)建非核心線程執(zhí)行31014繼續(xù)創(chuàng)建非核心線程41015~17繼續(xù)創(chuàng)建非核心線程51018~20線程數(shù)已達(dá) 5隊(duì)列已滿觸發(fā)拒絕策略510這個(gè)推演暴露了一個(gè)容易混淆的點(diǎn)任務(wù) 3 到任務(wù) 12 這 10 個(gè)任務(wù)并沒有立刻執(zhí)行而是全部進(jìn)了隊(duì)列等待。只有當(dāng)隊(duì)列滿到第 11 個(gè)任務(wù)塞不進(jìn)去時(shí)線程池才開始把線程數(shù)從 2 往 5 擴(kuò)。所以觀察線上線程池的 activeCount 時(shí)如果看到它長期小于 corePoolSize說明任務(wù)量根本沒打滿如果等于 corePoolSize 且 queueSize 在漲說明隊(duì)列在承擔(dān)緩沖壓力只有 queueSize 頂滿activeCount 才開始往 max 漲。如果隊(duì)列換成無界 LinkedBlockingQueue那整個(gè)推演在任務(wù) 3~20 都會(huì)停在“入隊(duì)等待”線程數(shù)永遠(yuǎn)是 2。這就是無界隊(duì)列掩蓋 maximumPoolSize 的原因。理解這個(gè)推演配置參數(shù)時(shí)就能少走很多彎路。6. 線上排查實(shí)錄高頻問題與避坑指南6.1 線程數(shù)漲滿但隊(duì)列為空先看是不是 SynchronousQueue我見過一個(gè)很典型的案例某服務(wù)配置了 SynchronousQueue 和很大的 maximumPoolSize高峰期線程數(shù)直接沖到幾百CPU 被打滿接口超時(shí)率飆升。排查時(shí)先看隊(duì)列發(fā)現(xiàn) queueSize 永遠(yuǎn)是 0——這不是“沒有任務(wù)排隊(duì)”而是 SynchronousQueue 本身就不排隊(duì)。SynchronousQueue 的語義是“生產(chǎn)者直接把任務(wù)交給消費(fèi)者線程”沒有中間緩沖。任何提交進(jìn)來的任務(wù)都會(huì)立刻觸發(fā) addWorker 創(chuàng)建線程線程數(shù)自然容易一路頂?shù)?maximumPoolSize。它非常適合線程可快速創(chuàng)建銷毀、任務(wù)量波動(dòng)大的場景但要求 maximumPoolSize 必須設(shè)得克制同時(shí)做好限流。如果業(yè)務(wù)需要穩(wěn)定的緩沖和削峰SynchronousQueue 就是錯(cuò)誤選擇。遇到線程數(shù)異常上漲第一反應(yīng)應(yīng)該是去看線程池用的是哪種隊(duì)列、max 設(shè)多大再配合線程棧確認(rèn)線程都在干什么。別一上來就猜業(yè)務(wù)問題很多“并發(fā)異?！逼鋵?shí)是線程池配置與業(yè)務(wù)模型不匹配。6.2 execute 與 submit 的異常差異靜默失敗的高發(fā)區(qū)execute(Runnable) 和 submit(Callable/Runnable) 都能提交任務(wù)但異常處理路徑完全不同這是線上“任務(wù)靜默失敗”的高發(fā)原因。execute 提交的任務(wù)如果拋出 RuntimeException異常會(huì)直接冒出 runWorker導(dǎo)致當(dāng)前 worker 線程退出。線程池感知到異常后processWorkerExit 會(huì)補(bǔ)一個(gè)新線程進(jìn)來。這個(gè)異常會(huì)打印到 System.err但對業(yè)務(wù)代碼來說幾乎是透明的——你沒有辦法在提交方捕獲它唯一可靠的觀測點(diǎn)是重寫 afterExecute。submit 則不同。任務(wù)被包裝成 FutureTask異常會(huì)被 FutureTask 內(nèi)部捕獲并存起來提交方必須調(diào)用 future.get() 才能拿到 ExecutionException。如果沒人調(diào) get這個(gè)異常就被吞得干干凈凈日志里什么都看不到。所以我的建議是異步任務(wù)要么統(tǒng)一走自定義 handler afterExecute 記錄異常要么全部用 submit 并且及時(shí)處理 Future。不要混用 execute 和 submit否則排查問題時(shí)你不知道哪個(gè)任務(wù)在哪一層丟了異常。尤其是批量異步任務(wù)提交后一定要集中等待 Future 完成并對異常做分類處理。6.3 線程池關(guān)不上的兩個(gè)陷阱泄漏與退出卡住線程池“關(guān)不上”是另一個(gè)高頻問題常見原因有兩個(gè)。第一是線程池泄漏。比如在方法里每次請求都 new 一個(gè) ThreadPoolExecutor執(zhí)行完既不 shutdown也沒有把實(shí)例放進(jìn)容器管理。時(shí)間一長線程數(shù)不斷累積內(nèi)存和句柄都被耗盡。這種問題用 jstack 看線程名最明顯——大量同類前綴的線程堆在等待隊(duì)列的 take 上。解決方式是讓線程池全局單例由 Spring 容器或靜態(tài)字段管理生命周期而不是每次用都新建。第二是退出卡住。應(yīng)用要關(guān)閉線程池調(diào)了 shutdown 但進(jìn)程一直不退出。常見原因有兩種池里還有線程在跑長任務(wù)或者隊(duì)列里還有大量任務(wù)沒消費(fèi)完。shutdown 本來就會(huì)等待這些任務(wù)完成如果業(yè)務(wù)本身沒有結(jié)束點(diǎn)進(jìn)程就會(huì)一直掛著。正確做法是使用 shutdown awaitTermination 組合等待超時(shí)后對未完成任務(wù)做兜底比如取消、落庫再配合應(yīng)用關(guān)閉鉤子統(tǒng)一處理。另外ThreadFactory 會(huì)把線程創(chuàng)建成非守護(hù)線程如果池不關(guān)閉JVM 也會(huì)因?yàn)榇嬖诜鞘刈o(hù)線程而拒絕退出。6.4 問題定位速查表把高頻問題整理成一張速查表排查時(shí)直接對著看能省不少時(shí)間現(xiàn)象可能原因檢查方法處理建議線程數(shù)漲到最大但隊(duì)列空使用了 SynchronousQueue打印隊(duì)列類型與 activeCount換有界隊(duì)列或調(diào)低 max任務(wù)被大量拒絕隊(duì)列滿 線程滿看拒絕策略異常次數(shù)增加隊(duì)列容量或調(diào)大 max否則換 CallerRunsPolicy核心線程不斷被回收allowCoreThreadTimeOut 被開啟檢查配置項(xiàng)按業(yè)務(wù)決定是否關(guān)閉此選項(xiàng)提交后長時(shí)間不執(zhí)行隊(duì)列積壓嚴(yán)重查看 queueSize縮短單任務(wù)耗時(shí)或拆分任務(wù)任務(wù)異常但沒有日志submit 后未調(diào) get檢查 afterExecute 是否有埋點(diǎn)統(tǒng)一 afterExecute 記錄異常進(jìn)程退出卡住線程池未優(yōu)雅關(guān)閉jstack 看存活線程shutdown awaitTermination 兜底最后說點(diǎn)個(gè)人體會(huì)。線程池這種東西源碼讀三遍不如自己把狀態(tài)流轉(zhuǎn)圖畫一遍。我當(dāng)初就是在紙上把 RUNNING 到 TERMINATED 的路徑、execute 的三次機(jī)會(huì)、getTask 的四個(gè)出口全部畫完才真正把“線程池”三個(gè)字從 API 變成模型。學(xué)完原理之后要做的第一件事就是去看看生產(chǎn)環(huán)境里線程池的監(jiān)控指標(biāo)——activeCount、queueSize、completedTaskCount、拒絕次數(shù)這四個(gè)數(shù)字組合起來基本能解釋掉絕大多數(shù)線程池疑難雜癥。掌握這套底層邏輯再遇到詭異問題先別猜抓線程棧、看隊(duì)列深度、看拒絕計(jì)數(shù)根因通常就藏在組合的數(shù)據(jù)里。