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