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