1. 線程池核心機制與參數(shù)解讀先聊點實在的。接手過幾個線上服務(wù)之后你會發(fā)現(xiàn)線程池這玩意兒寫起來簡單跑起來要命。很多人背了八股文知道ThreadPoolExecutor有七個參數(shù)但真到了生產(chǎn)環(huán)境線程池一滿任務(wù)一丟接口超時日志里連個報錯都找不到那時候才明白什么叫“基礎(chǔ)不牢地動山搖”。這篇文章我把線程池從參數(shù)到底層流轉(zhuǎn)、從隊列選型到生產(chǎn)配置、從常見故障到排查手法完整過一遍。不是面試八股是真正能在線上環(huán)境扛住壓力的那種理解。1.1 七個參數(shù)各自扮演什么角色ThreadPoolExecutor的構(gòu)造方法里那七個參數(shù)任何一個設(shè)錯了都不是“性能差一點”的問題而是直接導(dǎo)致線上故障的問題。先把它們逐個拆開看。corePoolSize核心線程數(shù)線程池里常駐的線程數(shù)量。就算閑著這些線程也不會銷毀除非設(shè)置了allowCoreThreadTimeOut。它決定了線程池處理突發(fā)流量的“最低火力”。maximumPoolSize最大線程數(shù)線程池允許存在的最大線程數(shù)量。當(dāng)核心線程都在忙隊列又滿了線程池才會創(chuàng)建額外線程直到這個上限。keepAliveTime存活時間非核心線程空閑多久后被回收。默認情況下只對超出核心線程數(shù)的那部分線程生效。這個參數(shù)如果設(shè)得太小流量抖動時頻繁創(chuàng)建銷毀線程反而增加開銷。unit時間單位配合keepAliveTime用的秒、毫秒、微秒按需選擇。workQueue任務(wù)隊列核心線程都在忙的時候新任務(wù)先在隊列里排隊。這個隊列選擇的學(xué)問最大后面單獨用一節(jié)細講。threadFactory線程工廠創(chuàng)建線程用的工廠。生產(chǎn)環(huán)境必須自定義給線程起有意義的名稱否則排查問題時你看到的全是pool-1-thread-1這種毫無信息量的名字。handler拒絕策略線程池和隊列都滿的時候新任務(wù)怎么處理。默認的AbortPolicy是直接拋異常但如果你沒接住任務(wù)就沒了。從JDK源碼的角度看ThreadPoolExecutor內(nèi)部就一個核心狀態(tài)變量用ctl這個AtomicInteger同時保存workerCount工作線程數(shù)和runState運行狀態(tài)。高3位存狀態(tài)低29位存線程數(shù)用位運算來保證狀態(tài)切換和線程數(shù)增減的原子性。這不只是面試考點理解了這一步你才能理解為什么線程池關(guān)閉時要先shutdown()再awaitTermination()——那是為了讓狀態(tài)有機會從RUNNING平滑過渡到TIDYING。1.2 任務(wù)提交后線程池內(nèi)部是怎么流轉(zhuǎn)的很多資料會畫一張復(fù)雜的流程圖其實你記住四個步驟就夠了。這是execute()方法的真實執(zhí)行邏輯順序錯了就全錯了核心線程未滿線程池收到新任務(wù)先判斷當(dāng)前工作線程數(shù)是否小于corePoolSize。如果小于直接創(chuàng)建核心線程執(zhí)行這個任務(wù)。注意不是先丟隊列。這個順序很多人搞反了。隊列未滿核心線程已經(jīng)全部在忙新任務(wù)被塞進阻塞隊列等待。線程池不會立刻創(chuàng)建新線程而是讓任務(wù)排隊。隊列已滿線程未達上限隊列放不下了線程池才會創(chuàng)建非核心線程去處理任務(wù)。這一步是“先塞隊列再擴線程”這個機制決定了你單純調(diào)大maximumPoolSize不一定能提升吞吐量還要看隊列策略。隊列滿且線程滿觸發(fā)拒絕策略。四種策略分別是拋異常Abort、丟棄Discard、丟棄最老的DiscardOldest、由調(diào)用線程自己執(zhí)行CallerRuns。這里有個關(guān)鍵點線程池創(chuàng)建非核心線程后如果這個線程空閑時間超過了keepAliveTime就會被回收。所以你的線程池容量是動態(tài)變化的別以為maximumPoolSize設(shè)了10就一直有10個線程。生活類比線程池就像一家銀行。柜臺窗口是核心線程大廳等候區(qū)是隊列行長決定要不要臨時加開窗口非核心線程。等候區(qū)坐滿了窗口也全開著再來客戶就只能拒之門外拒絕策略。1.3 拒絕策略不是隨便選的默認的AbortPolicy直接拋RejectedExecutionException如果你的業(yè)務(wù)代碼沒有捕獲任務(wù)靜默丟失上游看到的只是接口超時或數(shù)據(jù)缺失。我在生產(chǎn)環(huán)境見過最典型的案例一個消息推送服務(wù)用了默認策略流量高峰時大量消息被丟棄用戶沒收到推送排查了半天才在日志里找到零星的RejectedExecutionException。CallerRunsPolicy反而是我比較推薦的兜底策略。它不會丟任務(wù)而是讓提交任務(wù)的線程通常是業(yè)務(wù)線程自己執(zhí)行這個任務(wù)。這就形成了天然限流——提交線程被占用提交速度自然慢下來。壞處是接口響應(yīng)時間可能飆升你要在監(jiān)控上接受這個代價。DiscardPolicy和DiscardOldestPolicy基本只適合丟得起消息的場景比如實時日志、監(jiān)控指標(biāo)丟了也不心疼。凡是涉及訂單、支付、消息通知的別用。經(jīng)驗之談拒絕策略不要只寫在代碼注釋里要在監(jiān)控大盤上加上“線程池拒絕次數(shù)”這個指標(biāo)。一旦出現(xiàn)拒絕告警說明你的線程池容量或隊列已經(jīng)到極限了這是容量規(guī)劃的報警信號。2. 阻塞隊列選型最容易踩坑的環(huán)節(jié)線程池的參數(shù)里workQueue的選擇大概是生產(chǎn)環(huán)境最容易被忽視、又最容易出問題的一項。隊列選錯不只是性能問題可能直接把內(nèi)存打爆。2.1 三種常見隊列的底層差異無界隊列LinkedBlockingQueue默認容量是Integer.MAX_VALUE任務(wù)永遠進得來maximumPoolSize直接變成擺設(shè)。你設(shè)了最大線程數(shù)10但因為隊列永遠不滿非核心線程永遠不會被創(chuàng)建。這個隊列最大的風(fēng)險是——如果生產(chǎn)速度持續(xù)快過消費速度隊列無限膨脹最終觸發(fā)OOM內(nèi)存溢出。有界隊列ArrayBlockingQueue必須指定容量比如new ArrayBlockingQueue(1000)。這是生產(chǎn)環(huán)境最推薦的選擇它會強制你思考“隊列最多能堆積多少任務(wù)”。隊列滿了之后線程池才會擴容到maximumPoolSize一切行為都可預(yù)測。同步隊列SynchronousQueue這個隊列比較特殊它內(nèi)部不存儲任何任務(wù)。每個任務(wù)進來必須立刻有一個線程接走否則就阻塞。配合maximumPoolSize設(shè)得比較大時相當(dāng)于完全沒有緩沖任務(wù)直達線程。適合處理“必須立刻執(zhí)行不緩存”的場景比如即時通信的消息轉(zhuǎn)發(fā)。優(yōu)先級隊列PriorityBlockingQueue任務(wù)按優(yōu)先級排序。適合有明確優(yōu)先級的業(yè)務(wù)但要注意——如果任務(wù)一直有高優(yōu)先級的進來低優(yōu)先級任務(wù)可能會餓死永遠得不到執(zhí)行。從底層實現(xiàn)看LinkedBlockingQueue用兩個鎖分別控制隊頭和隊尾讀寫可以并行ArrayBlockingQueue只有一個鎖讀寫互斥。所以理論上LinkedBlockingQueue的吞吐量更高但這在業(yè)務(wù)層面往往不是主要矛盾——容量可控性和溢出風(fēng)險才是。生活類比先把任務(wù)全部裝進一個大倉庫無界隊列再讓工人慢慢搬。表面看效率高但倉庫如果無限大積壓的貨物會把倉庫撐爆。有界隊形就像是限定了倉庫面積滿了就得加人或者不接單。2.2 不同業(yè)務(wù)場景該選哪個隊列拿我實際見過的幾個場景來說。場景一Web接口異步處理任務(wù)。用戶請求進來把任務(wù)丟線程池響應(yīng)立刻返回。這種場景選有界隊列比如ArrayBlockingQueue容量設(shè)1000~5000。為什么因為你需要一個明確的任務(wù)積壓上限。如果隊列無界網(wǎng)絡(luò)抖動導(dǎo)致任務(wù)暴增時內(nèi)存會先扛不住服務(wù)OOM掛掉那可比拒絕幾個請求嚴重多了。場景二日志異步寫入。日志數(shù)據(jù)量大、允許丟棄、對實時性要求不高。這種場景可以用無界隊列或者干脆用DiscardPolicy因為日志丟幾條不影響核心業(yè)務(wù)。但要注意如果你用logback或log4j2的異步隊列它們內(nèi)部已經(jīng)做了有界處理和丟棄策略你配置線程池時不需要重復(fù)造輪子。場景三即時性要求極高的消息推送。用戶在線狀態(tài)判斷、IM消息轉(zhuǎn)發(fā)這類任務(wù)延遲敏感。用SynchronousQueue配合較大的maximumPoolSize讓任務(wù)能立刻分配到線程執(zhí)行。代價是線程池會頻繁創(chuàng)建線程keepAliveTime要設(shè)短一點比如60秒避免線程堆積。2.3 隊列長度怎么定隊列長度沒有萬能公式但有一個可以參考的估算思路。假設(shè)你的核心線程數(shù)是4每個任務(wù)平均耗時200ms那么線程池每秒大約能消費4 * (1000/200) 20個任務(wù)。如果你的業(yè)務(wù)高峰期每秒提交50個任務(wù)那每秒積壓30個任務(wù)。如果你能接受任務(wù)最多積壓1分鐘隊列長度就設(shè)為30 * 60 1800。這個估算方式背后是經(jīng)典的利特爾法則Littles Law系統(tǒng)中的任務(wù)數(shù)等于到達速率乘以處理時間。用這個思路算出來的隊列長度至少是“有依據(jù)”的比拍腦袋強得多。算完再在壓測環(huán)境驗證一下看看積壓和拒絕是否在可接受范圍內(nèi)。注意隊列長度不能只算平均值要按峰值的3~5倍預(yù)留。線上流量不是勻速的秒殺、活動、定時任務(wù)觸發(fā)重疊可能瞬間就是10倍流量別讓隊列在正常波動下就撐滿。3. 生產(chǎn)環(huán)境線程池配置實踐3.1 核心線程數(shù)到底怎么算線程池的線程數(shù)設(shè)置業(yè)界流傳的經(jīng)驗公式基本是CPU密集型設(shè)為CPU核心數(shù) 1IO密集型設(shè)為CPU核心數(shù) * 2。先解釋為什么。CPU密集型任務(wù)計算、加密、序列化基本不阻塞線程數(shù)接近CPU核心數(shù)就能跑滿。多加一個線程是為了防止某個線程偶爾因頁缺失、上下文切換而空閑時能補位。IO密集型任務(wù)數(shù)據(jù)庫訪問、遠程調(diào)用、文件讀寫大部分時間在等IO返回線程處于阻塞狀態(tài)。這時候線程數(shù)可以多一些讓等待的線程和運行的線程重疊。$CPU核心數(shù) * 2$ 是一個經(jīng)驗起點更準確的計算是$$線程數(shù) CPU核心數(shù) \times (1 \frac{等待時間}{計算時間})$$比如一個任務(wù)計算耗時20msIO等待80ms那等待時間與計算時間的比值是4理想線程數(shù)就是核心數(shù)乘以14。但要注意這個公式適合單任務(wù)獨立的情況。如果多個任務(wù)共享同一個下游連接池比如數(shù)據(jù)庫連接池只有50個連接你的線程數(shù)設(shè)200也沒用都被連接池擋住了。實操建議核心線程數(shù)先按經(jīng)驗公式定一個初值然后壓測。觀察線程池活躍度、隊列積壓速度、任務(wù)耗時這三個指標(biāo)不斷調(diào)整直到吞吐量和延遲達到平衡。沒有哪一組參數(shù)是“絕對正確”的只有“適合你當(dāng)前業(yè)務(wù)”的。3.2 不要在代碼里硬編碼線程池新手最容易犯的錯就是每次用到線程池就現(xiàn)場new一個ExecutorService executor Executors.newFixedThreadPool(10);這條代碼有兩個問題。第一Executors提供的快捷方法里newFixedThreadPool和newSingleThreadExecutor用的是無界隊列前面說過了有OOM風(fēng)險。第二每次new一個線程池用完不關(guān)閉線程資源一直在泄漏。我有一個項目就因為這個原因上線一周后線程數(shù)漲到幾千個最后服務(wù)直接不響應(yīng)了。正確做法是全局統(tǒng)一管理線程池。可以用Spring管理在配置類里聲明Configuration public class ThreadPoolConfig { Bean(businessExecutor) public ThreadPoolExecutor businessExecutor() { ThreadPoolExecutor executor new ThreadPoolExecutor( 8, 16, 60L, TimeUnit.SECONDS, new ArrayBlockingQueue(2000), new NamedThreadFactory(biz-exec), new ThreadPoolExecutor.CallerRunsPolicy() ); // 預(yù)啟動核心線程避免流量突刺時冷啟動 executor.prestartAllCoreThreads(); return executor; } }注意我用了NamedThreadFactory——這是Guava或自定義的目的就是給線程起名字。出了故障你在jstack里能看到biz-exec-thread-5在干什么而不是一頭霧水地猜pool-3-thread-1是哪來的。prestartAllCoreThreads()這個方法也很實用。默認情況下核心線程是懶加載的收到第一個任務(wù)才創(chuàng)建。對高并發(fā)服務(wù)來說首次請求可能會因為線程創(chuàng)建而變慢預(yù)啟動可以消除這個問題。3.3 動態(tài)調(diào)整生產(chǎn)環(huán)境的神器靜態(tài)參數(shù)配得再好也應(yīng)對不了流量突變。比如運營活動來了任務(wù)量翻倍或者大促結(jié)束任務(wù)量驟降。Java提供了一個很實用的方法ThreadPoolExecutor#setCorePoolSize()和setMaximumPoolSize()。你可以把線程池參數(shù)配置到配置中心Nacos、Apollo改動實時生效Component public class DynamicThreadPoolManager { private final ThreadPoolExecutor executor; public void updatePoolSize(int coreSize, int maxSize) { executor.setCorePoolSize(coreSize); executor.setMaximumPoolSize(maxSize); log.info(線程池參數(shù)動態(tài)調(diào)整完成, core{}, max{}, coreSize, maxSize); } }這套方案有兩個細節(jié)。第一setCorePoolSize如果設(shè)得比當(dāng)前線程數(shù)小多余的線程會在空閑后逐漸回收不會立刻中斷正在執(zhí)行的任務(wù)所以是安全的。第二配置中心推送新值后最好加一個版本號日志方便排查“是不是參數(shù)被誰改過”。遇到的真實案例我曾經(jīng)維護過一個推送服務(wù)每次大促前都要手動改線程池參數(shù)再重啟后來接入了動態(tài)配置大促前提前半小時改配置再也不用重啟了。而且加了告警之后線程池如果發(fā)生拒絕馬上能感知到手里有動態(tài)參數(shù)這招改起來也不用慌張。4. 常見問題與排查技巧實錄4.1 線程池里任務(wù)異常被吞掉這是最隱蔽的一個坑。execute()方法提交的任務(wù)如果執(zhí)行過程中拋出異常這個異常會被線程池捕獲打印到System.err或者線程池內(nèi)部的UncaughtExceptionHandler但不會自動傳給提交任務(wù)的調(diào)用方。后果就是——任務(wù)失敗了你完全無感日志也不一定有記錄數(shù)據(jù)就這么悄悄丟了。復(fù)現(xiàn)現(xiàn)場public class ThreadPoolExceptionDemo { public static void main(String[] args) { ThreadPoolExecutor executor new ThreadPoolExecutor( 2, 4, 60L, TimeUnit.SECONDS, new ArrayBlockingQueue(100) ); executor.execute(() - { throw new RuntimeException(任務(wù)執(zhí)行失敗); }); // 主線程繼續(xù)跑完全感知不到上面那個異常 System.out.println(主線程執(zhí)行完畢); } }你跑一下會發(fā)現(xiàn)異常在子線程里是打出來了但主線程毫無察覺。解決辦法有幾種一是在任務(wù)內(nèi)部自己捕獲所有異常并記錄日志executor.execute(() - { try { doBusiness(); } catch (Exception e) { log.error(任務(wù)執(zhí)行異常, e); // 如果業(yè)務(wù)需要可以在這里做補償或重試 } });二是用submit()代替execute()返回值是Future調(diào)用future.get()時異常會重新拋出來。代價是如果主線程不做get()異常依然是無感的。三是給線程池設(shè)置UncaughtExceptionHandlerThreadFactory factory new ThreadFactoryBuilder() .setNameFormat(biz-pool-%d) .setUncaughtExceptionHandler((t, e) - log.error(線程 {} 發(fā)生未捕獲異常, t.getName(), e)) .build();我個人的習(xí)慣是任務(wù)內(nèi)部必須try-catch并且把異常上下文任務(wù)ID、參數(shù)、耗時打全。線程池是異步的異步意味著你失去了原有的調(diào)用棧不好好記日志出了問題就是大海撈針。4.2 ThreadLocal內(nèi)存泄漏線程池和ThreadLocal搭配使用是經(jīng)典的內(nèi)存泄漏觸發(fā)點。邏輯是這樣的ThreadLocal的特點是“線程本地變量”每個線程維護一個ThreadLocalMap。正常業(yè)務(wù)中線程用完就銷毀ThreadLocalMap隨之被GC回收。但線程池里的線程長期存活如果某個任務(wù)往ThreadLocal里寫了一個大對象用完后沒有手動remove()那這個對象就會被后續(xù)所有任務(wù)共同看到。輕則數(shù)據(jù)串號A用戶的數(shù)據(jù)跑到B用戶那里重則老年代持續(xù)增長觸發(fā)Full GC。真實事故一個訂單服務(wù)在攔截器里把用戶信息放進了ThreadLocal線程池里的線程處理完一個請求后沒有清理。結(jié)果用戶A查訂單跳出了用戶B的訂單信息。這個事故的直接原因就是ThreadLocal值在不同請求間串了。規(guī)矩很簡單用ThreadLocal的地方finally塊里必須remove()。public void handleRequest(User user) { // 假設(shè) UserContext 內(nèi)部用 ThreadLocal 存用戶信息 UserContext.set(user); try { doBusiness(); } finally { UserContext.remove(); } }這行remove()在面試里很好答但在生產(chǎn)環(huán)境你少寫一行線上就會炸。線程池的復(fù)用特性決定了ThreadLocal必須是“用完即扔”的一次性工具絕不能依賴GC幫你清理。4.3 線程池用完沒關(guān)閉導(dǎo)致的線程泄漏線程池不像普通對象不會因為你不再引用它就自動銷毀。ThreadPoolExecutor的核心線程默認是常駐的即使業(yè)務(wù)已經(jīng)不再提交任務(wù)那些線程依然活著。最常見的一個場景批處理任務(wù)里循環(huán)處理一批數(shù)據(jù)每次都創(chuàng)建一個線程池處理處理完沒有調(diào)用shutdown()。第一批數(shù)據(jù)處理的線程池還在第二批又創(chuàng)建了新線程池久而久之線程數(shù)只增不減直到操作系統(tǒng)再也創(chuàng)建不了線程報出OutOfMemoryError: unable to create new native thread。關(guān)閉線程池的正確姿勢executor.shutdown(); // 不再接受新任務(wù)但已提交的任務(wù)繼續(xù)執(zhí)行 try { // 等待60秒讓已提交的任務(wù)執(zhí)行完 if (!executor.awaitTermination(60, TimeUnit.SECONDS)) { // 如果還沒執(zhí)行完強制關(guān)閉 executor.shutdownNow(); } } catch (InterruptedException e) { executor.shutdownNow(); Thread.currentThread().interrupt(); }shutdown()和shutdownNow()的區(qū)別是前者等已經(jīng)提交的任務(wù)跑完后者直接中斷正在執(zhí)行的任務(wù)并返回未執(zhí)行的任務(wù)列表。生產(chǎn)環(huán)境一般先shutdown()再awaitTermination()給任務(wù)一個優(yōu)雅退出的窗口。如果等不及再shutdownNow()。4.4 常見問題排查速查表現(xiàn)象排查思路處理方式接口超時、任務(wù)不見查看拒絕策略是否觸發(fā)監(jiān)控線程池拒絕次數(shù)日志搜索RejectedExecutionException調(diào)整隊列或最大線程數(shù)內(nèi)存持續(xù)增長、OOM檢查隊列是否無界、任務(wù)積壓換成有界隊列給隊列容量設(shè)置上限監(jiān)控隊列深度線程數(shù)持續(xù)上漲不下降確認allowCoreThreadTimeOut、檢查線程是否阻塞在外部調(diào)用上jstack查看線程棧確認是否有線程因IO等待而長期不釋放多個請求間數(shù)據(jù)串號檢查ThreadLocal是否用了沒清理在finally里調(diào)用remove()重啟驗證核心線程數(shù)為0時行為詭異了解corePoolSize0的特殊邏輯任務(wù)提交時先入隊有任務(wù)被消費后線程才創(chuàng)建實際場景不建議設(shè)0業(yè)務(wù)無法預(yù)測響應(yīng)行為線上任務(wù)執(zhí)行超時但無明顯報錯查任務(wù)里是否有遠程調(diào)用下游超時時間是否合理在任務(wù)內(nèi)部記錄耗時日志拆解耗時構(gòu)成排查線程池問題最常用的命令# 查看進程中最耗CPU的線程 top -Hp pid # 打印線程堆棧 jstack pid thread_dump.txt # 用 jstack 搜索自定義線程名前綴快速定位 grep biz-exec thread_dump.txt排查時有個小技巧如果你用了自定義線程池jstack里每個線程名都帶業(yè)務(wù)前綴一眼就能定位。這一行命名習(xí)慣省下來的排查時間無法估算。5. 自己動手實現(xiàn)一個簡化版線程池別急著跳過這部分是理解Java線程池的最佳途徑。面試的時候背誦參數(shù)是低級的真正的高級是能用自己的話說出線程池是怎么跑起來的。自己寫一個簡化版比看十遍源碼都管用。5.1 核心結(jié)構(gòu)設(shè)計一個簡化線程池需要四個部件任務(wù)隊列、工作線程集合、線程池狀態(tài)、任務(wù)調(diào)度邏輯。public class SimpleThreadPool { // 任務(wù)隊列存放提交的任務(wù) private final BlockingQueueRunnable taskQueue; // 工作線程集合 private final ListWorker workers new ArrayList(); // 線程池狀態(tài) private volatile boolean running true; // 核心線程數(shù) private final int corePoolSize; public SimpleThreadPool(int corePoolSize, int queueCapacity) { this.corePoolSize corePoolSize; this.taskQueue new ArrayBlockingQueue(queueCapacity); } // 啟動核心線程 public void start() { for (int i 0; i corePoolSize; i) { Worker worker new Worker(thread- i); workers.add(worker); worker.start(); } } // 提交任務(wù)入隊失敗就拒絕 public void execute(Runnable task) { if (!running) { throw new IllegalStateException(線程池已停止); } // 這里真正生產(chǎn)環(huán)境要考慮是否創(chuàng)建額外線程 taskQueue.offer(task); } // 關(guān)閉線程池 public void shutdown() { running false; workers.forEach(Worker::interrupt); } // 工作線程 private class Worker extends Thread { public Worker(String name) { super(name); } Override public void run() { while (running || !taskQueue.isEmpty()) { try { Runnable task taskQueue.poll(1, TimeUnit.SECONDS); if (task ! null) { task.run(); } } catch (InterruptedException e) { Thread.currentThread().interrupt(); } } } } }這個版本極其簡化沒有最大線程數(shù)概念沒有拒絕策略但核心骨架已經(jīng)到位了一個隊列存任務(wù)一組線程消費隊列。理解了這一點再看官方ThreadPoolExecutor你就知道它是在這個骨架上加了狀態(tài)機、動態(tài)擴容、拒絕策略、線程回收等細節(jié)。5.2 關(guān)鍵實現(xiàn)細節(jié)我發(fā)明的這個簡化版有個細節(jié)值得品味while (running || !taskQueue.isEmpty())。這個循環(huán)條件保證了關(guān)閉線程池時已經(jīng)在隊列里沒執(zhí)行的任務(wù)也會被消費完不會因為shutdown()調(diào)用就立刻丟任務(wù)。這其實就是官方shutdown()和shutdownNow()的區(qū)別本質(zhì)好的關(guān)閉策略不是戛然而止而是給排隊任務(wù)一個“消化完”的窗口。taskQueue.poll(1, TimeUnit.SECONDS)這個細節(jié)也很關(guān)鍵。它讓空閑線程每秒鐘醒一次檢查狀態(tài)而不是用take()死等這樣既能及時響應(yīng)關(guān)閉信號也不會浪費CPU。實際生產(chǎn)中你把keepAliveTime理解成類似的東西它是線程從“等不到新任務(wù)”到“被回收”的等待時間。5.3 用測試驗證自己的線程池寫完了必須跑一下驗證三個核心能力能執(zhí)行任務(wù)、能排隊、能優(yōu)雅關(guān)閉。public class SimpleThreadPoolTest { public static void main(String[] args) throws InterruptedException { SimpleThreadPool pool new SimpleThreadPool(2, 5); pool.start(); for (int i 0; i 10; i) { final int taskId i; pool.execute(() - { System.out.println(Thread.currentThread().getName() 執(zhí)行任務(wù) taskId); try { Thread.sleep(200); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } }); } // 等待任務(wù)執(zhí)行 Thread.sleep(2000); pool.shutdown(); System.out.println(線程池已關(guān)閉); } }觀察輸出你會看到兩個核心線程輪流執(zhí)行10個任務(wù)且線程創(chuàng)建是“懶啟動”——第一個任務(wù)執(zhí)行時才真正創(chuàng)建線程這也印證了前面說核心線程為什么最好提前預(yù)啟動的原因。我自己寫完這個小demo后對官方ThreadPoolExecutor的理解確實上了一個臺階。一個“會思考”的線程池?zé)o非是在這幾個部件上做了很多精細化控制源碼也就不再是背出來的八股文了。我個人在實際項目中的體會是線程池的參數(shù)沒有金科玉律每個服務(wù)都要根據(jù)自身的任務(wù)類型和下游依賴能力壓測調(diào)優(yōu)。先寫對參數(shù)合理、隊列有界、拒絕策略合適再看緊線程數(shù)、隊列深度、拒絕次數(shù)、任務(wù)耗時全上監(jiān)控最后能用動態(tài)參數(shù)對抗流量突變。做好這三步線程池才能從“能跑”變成“扛得住”。如果遇到線程池問題排查無從下手先從jstack看線程在干什么再回來看隊列積壓和線程池參數(shù)90%的問題能快速定位。