1. 線程池到底解決了什么問(wèn)題先說(shuō)個(gè)我早年踩過(guò)的坑。那會(huì)兒剛工作沒(méi)多久接手一個(gè)內(nèi)部報(bào)表系統(tǒng)每次請(qǐng)求進(jìn)來(lái)我都是 new Thread(...).start() 這種最樸素的寫(xiě)法。單機(jī)并發(fā)量不大二三十個(gè)請(qǐng)求同時(shí)進(jìn)來(lái)系統(tǒng)也就撐住了。直到后來(lái)接了一個(gè)定時(shí)批量導(dǎo)出的需求每天凌晨要同時(shí)跑幾十個(gè)導(dǎo)出任務(wù)再加上白天的正常請(qǐng)求JVM 直接頻繁 Full GC線程數(shù)飆到幾百個(gè)CPU 被打滿整個(gè)服務(wù)像死了一樣。后來(lái)排查才發(fā)現(xiàn)罪魁禍?zhǔn)拙褪菬o(wú)節(jié)制地創(chuàng)建線程。線程池這個(gè)東西項(xiàng)目標(biāo)題寫(xiě)的是“基礎(chǔ)”但我覺(jué)得它其實(shí)是 Java 并發(fā)編程里最實(shí)用、最值得先搞明白的一塊。它解決的痛點(diǎn)非常樸素線程的創(chuàng)建和銷毀是有代價(jià)的不能每次要用時(shí)就現(xiàn)場(chǎng)造一個(gè)。造一個(gè)線程要分配棧內(nèi)存。默認(rèn)棧大小通常 512KB 到 1MB1000 個(gè)線程就是幾百 MB 的虛擬內(nèi)存。而且線程多了之后CPU 大量時(shí)間花在線程切換上而不是干活上系統(tǒng)吞吐量不升反降。線程池的核心思路就一句話把線程作為一個(gè)可復(fù)用的資源提前備好任務(wù)來(lái)了直接分配線程去執(zhí)行執(zhí)行完線程不銷毀繼續(xù)等下一個(gè)任務(wù)。這個(gè)“線程復(fù)用”的機(jī)制省掉的不只是創(chuàng)建銷毀的耗時(shí)更是讓系統(tǒng)的線程總數(shù)可控。那這篇內(nèi)容適合誰(shuí)看我的建議是剛接觸并發(fā)編程的初學(xué)者可以先建立整體概念工作一兩年的開(kāi)發(fā)者可以照著參數(shù)配置的思路去優(yōu)化現(xiàn)有項(xiàng)目哪怕你是做架構(gòu)設(shè)計(jì)的理解線程池背后的“池化思想”對(duì)你設(shè)計(jì)其他資源管理組件也有幫助。我盡量用大白話加實(shí)際場(chǎng)景來(lái)講不搞晦澀的理論堆砌。2. ThreadPoolExecutor 七個(gè)參數(shù)一個(gè)都不能糊弄2.1 參數(shù)總覽與直覺(jué)理解Java 里邊最核心的線程池實(shí)現(xiàn)就是 ThreadPoolExecutor。我們平時(shí)用的 Executors.newFixedThreadPool()、newCachedThreadPool() 這些工具方法底層都是包了 ThreadPoolExecutor。直接用工具方法雖然方便但在生產(chǎn)環(huán)境里我基本不推薦原因后面會(huì)說(shuō)。ThreadPoolExecutor 構(gòu)造方法有七個(gè)參數(shù)我先把它們列出來(lái)再逐個(gè)拆解參數(shù)含義類比corePoolSize核心線程數(shù)正式員工人數(shù)maximumPoolSize最大線程數(shù)正式員工加臨時(shí)工上限keepAliveTime非核心線程空閑存活時(shí)間臨時(shí)工干完活后等多久走人unit存活時(shí)間單位等多久的時(shí)間單位workQueue任務(wù)隊(duì)列客戶等待區(qū)threadFactory線程工廠招聘渠道handler拒絕策略客戶太多時(shí)怎么辦我用的類比是“銀行網(wǎng)點(diǎn)”。corePoolSize 就是柜臺(tái)正式柜員處理業(yè)務(wù)高峰期時(shí)正式柜員不夠用了客戶就到等待區(qū)排隊(duì)這個(gè)等待區(qū)就是 workQueue。排隊(duì)區(qū)滿了銀行決定開(kāi)臨時(shí)窗口叫一波臨時(shí)柜員頂上這就是 maximumPoolSize 里多出來(lái)的那部分。等客戶少了臨時(shí)柜員超過(guò) keepAliveTime 沒(méi)活干就被請(qǐng)走了。如果連臨時(shí)窗口都滿了等待區(qū)也滿了再來(lái)客戶就直接拒之門(mén)外這就是 handler 的工作。這個(gè)類比能幫你建立直覺(jué)但實(shí)際配置的時(shí)候有幾個(gè)容易搞混的點(diǎn)我專門(mén)展開(kāi)講。2.2 核心線程數(shù)和最大線程數(shù)的關(guān)系很多人以為線程池一開(kāi)始就會(huì)創(chuàng)建 corePoolSize 個(gè)線程其實(shí)不是。默認(rèn)情況下線程池是懶創(chuàng)建來(lái)一個(gè)任務(wù)才創(chuàng)建一個(gè)核心線程直到數(shù)量達(dá)到 corePoolSize。當(dāng)然可以用 prestartAllCoreThreads() 強(qiáng)制預(yù)熱。核心線程數(shù)和最大線程數(shù)的關(guān)系最關(guān)鍵的是搞清楚“什么時(shí)候創(chuàng)建非核心線程”。這里有一個(gè)非常經(jīng)典的問(wèn)題任務(wù)來(lái)了是先創(chuàng)建新線程還是先丟進(jìn)隊(duì)列答案是當(dāng)運(yùn)行線程數(shù)小于 corePoolSize 時(shí)來(lái)任務(wù)直接創(chuàng)建線程執(zhí)行根本不走隊(duì)列當(dāng)運(yùn)行線程數(shù)等于 corePoolSize 時(shí)后續(xù)任務(wù)先進(jìn)隊(duì)列當(dāng)隊(duì)列滿了并且運(yùn)行線程數(shù)小于 maximumPoolSize 時(shí)才會(huì)創(chuàng)建非核心線程去執(zhí)行新來(lái)的任務(wù)。這個(gè)順序很重要。有一個(gè)常見(jiàn)誤區(qū)就是“隊(duì)列滿了就丟給非核心線程執(zhí)行”聽(tīng)起來(lái)對(duì)但你要注意是隊(duì)列滿了之后新來(lái)的任務(wù)直接交給非核心線程執(zhí)行而隊(duì)列里的任務(wù)還是繼續(xù)排隊(duì)。這會(huì)導(dǎo)致一個(gè)有意思的現(xiàn)象后來(lái)的任務(wù)可能比先來(lái)的任務(wù)先執(zhí)行。雖然線程池的默認(rèn)執(zhí)行模型不是嚴(yán)格按任務(wù)順序來(lái)保證的但理解這一點(diǎn)能幫你解釋很多“任務(wù)執(zhí)行順序詭異”的問(wèn)題。再往深說(shuō)一層corePoolSize 和 maximumPoolSize 之差就是你允許系統(tǒng)在極端情況下使用的“彈性”資源。這個(gè)差值設(shè)得越大系統(tǒng)應(yīng)對(duì)突刺并發(fā)的能力越強(qiáng)但代價(jià)是線程數(shù)劇增上下文切換開(kāi)銷變大。2.3 keepAliveTime 與線程回收keepAliveTime 只針對(duì)非核心線程。核心線程默認(rèn)一輩子都待在池子里哪怕空閑也不銷毀。但有一個(gè)例外如果設(shè)置了 allowCoreThreadTimeOut(true)核心線程也會(huì)在空閑超過(guò) keepAliveTime 后被回收此時(shí)線程池的運(yùn)行線程數(shù)可能降為 0。我建議對(duì)絕大多數(shù)服務(wù)端應(yīng)用把 allowCoreThreadTimeOut 設(shè)置為 false也就是保留核心線程。因?yàn)榫€程池本來(lái)就是想避免重復(fù)創(chuàng)建銷毀線程的核心線程幾十個(gè)常駐內(nèi)存開(kāi)銷很小換來(lái)的是響應(yīng)速度更快。除非你的場(chǎng)景是“偶發(fā)任務(wù) 長(zhǎng)時(shí)間空閑”否則沒(méi)必要開(kāi)啟。還有個(gè)細(xì)節(jié)任務(wù)全部執(zhí)行完后線程池里的線程不會(huì)自動(dòng)消失如果項(xiàng)目停了一定要調(diào) shutdown() 或 shutdownNow()否則 JVM 會(huì)因?yàn)榫€程未結(jié)束而無(wú)法正常退出。我見(jiàn)過(guò)很多測(cè)試環(huán)境啟動(dòng)的線程池沒(méi)有關(guān)閉導(dǎo)致服務(wù)重啟后老線程還掛在那邊日志文件被占用非常頭大。2.4 線程工廠的隱藏作用threadFactory 這個(gè)參數(shù)看起來(lái)不起眼很多人直接忽略。但生產(chǎn)環(huán)境排查問(wèn)題的時(shí)候線程名字太重要了。默認(rèn)的線程名是 pool-1-thread-1 這種你在 dump 線程棧的時(shí)候看到幾十個(gè) pool-x-thread-y根本分不清是哪條業(yè)務(wù)鏈路創(chuàng)建的。我強(qiáng)烈建議自定義 ThreadFactory用業(yè)務(wù)名稱來(lái)命名線程。比如從訂單系統(tǒng)拉的線程池線程名就叫 order-process-pool-1-thread-1。實(shí)現(xiàn)起來(lái)很簡(jiǎn)單ThreadFactory threadFactory new ThreadFactory() { private final AtomicInteger counter new AtomicInteger(1); Override public Thread newThread(Runnable r) { Thread t new Thread(r); t.setName(order-process-pool- counter.getAndIncrement()); t.setDaemon(false); return t; } };還可以順手在 ThreadFactory 里設(shè)置異常處理器UncaughtExceptionHandler把線程拋出未捕獲異常時(shí)打印關(guān)鍵信息。這算是低成本高收益的小動(dòng)作線上排查問(wèn)題的時(shí)候能省大量時(shí)間。2.5 拒絕策略的選擇不能拍腦袋當(dāng)線程池的線程都在跑、隊(duì)列也滿了再提交新任務(wù)就會(huì)觸發(fā)拒絕策略。Java 內(nèi)置了四種拒絕策略行為適用場(chǎng)景AbortPolicy直接拋 RejectedExecutionException默認(rèn)策略任務(wù)不能丟時(shí)使用CallerRunsPolicy由提交任務(wù)的線程自己執(zhí)行不想丟任務(wù)但也不在乎誰(shuí)去執(zhí)行DiscardPolicy靜默丟棄允許丟任務(wù)的非核心場(chǎng)景DiscardOldestPolicy丟棄隊(duì)列里最老的任務(wù)再嘗試提交只關(guān)心最新任務(wù)的場(chǎng)景我見(jiàn)過(guò)不少項(xiàng)目直接默認(rèn)使用 AbortPolicy結(jié)果高并發(fā)下一旦觸發(fā)拒絕請(qǐng)求直接報(bào)錯(cuò)用戶看到頁(yè)面 500然后又觸發(fā)重試再把線程池壓得更滿惡性循環(huán)。實(shí)際項(xiàng)目中像異步寫(xiě)日志這種允許丟棄的任務(wù)可以用 DiscardPolicy但對(duì)于核心交易鏈路拒絕策略最好是自定義的比如把被拒絕的任務(wù)持久化到本地文件或者發(fā)消息到告警渠道之后再撈回來(lái)補(bǔ)處理。別嫌麻煩生產(chǎn)環(huán)境不出問(wèn)題則已一出就是大事。3. 阻塞隊(duì)列的選擇直接決定線程池行為3.1 隊(duì)列種類和適用場(chǎng)景談到“線程池的阻塞隊(duì)列選擇”這里面的門(mén)道比大多數(shù)人想象的多。隊(duì)列選錯(cuò)了線程池的參數(shù)配得再好也白搭。因?yàn)殛?duì)列和線程數(shù)是互相制約的隊(duì)列容量越大線程池需要擴(kuò)線程的機(jī)會(huì)就越少隊(duì)列容量越小線程數(shù)容易被打滿拒絕策略更容易觸發(fā)。Java 里常見(jiàn)的阻塞隊(duì)列有這些隊(duì)列特點(diǎn)適用場(chǎng)景ArrayBlockingQueue有界數(shù)組隊(duì)列必須指定容量需要嚴(yán)格控制任務(wù)積壓量LinkedBlockingQueue鏈表隊(duì)列默認(rèn)無(wú)界可設(shè)容量任務(wù)流量波動(dòng)大的緩沖場(chǎng)景SynchronousQueue不存儲(chǔ)任務(wù)直接交給線程超高吞吐、不排隊(duì)場(chǎng)景PriorityBlockingQueue優(yōu)先級(jí)排序無(wú)界任務(wù)需要按優(yōu)先級(jí)處理DelayQueue延遲出隊(duì)延時(shí)任務(wù)、定時(shí)調(diào)度3.2 SynchronousQueue 和 CachedThreadPool 的愛(ài)恨情仇SynchronousQueue 是里面比較特殊的它不是一個(gè)真正的容器隊(duì)列它內(nèi)部不存儲(chǔ)任務(wù)而是直接把任務(wù)交給一個(gè)等待取任務(wù)的線程。生產(chǎn)者和消費(fèi)者之間直接握手機(jī)制。這個(gè)隊(duì)列配合 Executors.newCachedThreadPool() 使用就是天生一對(duì)newCachedThreadPool 的核心線程數(shù)為 0最大線程數(shù)是 Integer.MAX_VALUEkeepAliveTime 是 60 秒。這導(dǎo)致一個(gè)后果來(lái)一個(gè)任務(wù)就必須創(chuàng)建一個(gè)線程來(lái)執(zhí)行因?yàn)殛?duì)列不緩存線程空閑 60 秒就被回收。這種線程池適合短平快的任務(wù)、任務(wù)數(shù)量不穩(wěn)定但每個(gè)任務(wù)執(zhí)行時(shí)間很短的場(chǎng)景。但是如果任務(wù)執(zhí)行時(shí)間長(zhǎng)它就會(huì)瘋狂創(chuàng)建線程直到把系統(tǒng)資源耗盡。newCachedThreadPool 的“緩存”兩個(gè)字容易誤導(dǎo)人實(shí)際上的語(yǔ)義是“每來(lái)必建閑置即焚”。3.3 有界隊(duì)列和線程數(shù)該怎么聯(lián)動(dòng)設(shè)置業(yè)界比較推崇的做法是用有界隊(duì)列 有限最大線程數(shù)。LinkedBlockingQueue 默認(rèn)無(wú)界是個(gè)大坑Executors.newFixedThreadPool() 底層用的就是無(wú)界 LinkedBlockingQueue如果任務(wù)生產(chǎn)速度遠(yuǎn)超消費(fèi)速度隊(duì)列里的任務(wù)會(huì)無(wú)限堆積直接內(nèi)存溢出。那有人問(wèn)既然無(wú)界隊(duì)列有風(fēng)險(xiǎn)為什么 FixedThreadPool 還這么設(shè)計(jì)因?yàn)樗谡Z(yǔ)義上保證“線程數(shù)固定絕不擴(kuò)增”任務(wù)再多的也是排隊(duì)。適合那種對(duì)并發(fā)資源有嚴(yán)格上限控制、并且任務(wù)量可預(yù)測(cè)的場(chǎng)景。對(duì)于絕大多數(shù)外部流量不可控的服務(wù)我不會(huì)用無(wú)界隊(duì)列。更好的組合是一種“彈性策略”corePoolSize 設(shè)小一點(diǎn)隊(duì)列容量設(shè)到一個(gè)合理水位maximumPoolSize 設(shè)一個(gè)稍高的值。隊(duì)列沒(méi)滿之前任務(wù)排隊(duì)讓線程平穩(wěn)消費(fèi)隊(duì)列滿了以后擴(kuò)線程吸收突發(fā)流量再不行就觸發(fā)拒絕策略將任務(wù)引導(dǎo)到降級(jí)方案。這個(gè)組合的思想是讓系統(tǒng)有一個(gè)緩沖帶而不是在隊(duì)列滿和拒絕之間硬碰硬。具體容量怎么算可以粗略按“高峰期 QPS x 任務(wù)平均耗時(shí) x 容忍排隊(duì)秒數(shù)”框一個(gè)量級(jí)。比如高峰期每秒提交 200 個(gè)任務(wù)每個(gè)任務(wù)平均執(zhí)行 0.2 秒你希望任務(wù)最多等待 5 秒那隊(duì)列容量大約就是 200 x 5 1000。這是個(gè)估算口徑真實(shí)環(huán)境還要配合壓測(cè)調(diào)優(yōu)。3.4 優(yōu)先級(jí)隊(duì)列和延遲隊(duì)列的小切面PriorityBlockingQueue 是無(wú)界隊(duì)列最大線程數(shù)這個(gè)參數(shù)基本失去了意義因?yàn)殛?duì)列永遠(yuǎn)不會(huì)滿線程數(shù)達(dá)到 corePoolSize 后就不再擴(kuò)展了。它適合那種任務(wù)本身有明確優(yōu)先級(jí)且任務(wù)總量可控的場(chǎng)景。注意它的排序基于 Comparator如果元素不實(shí)現(xiàn) Comparable 且不傳 Comparator會(huì)直接報(bào) ClassCastException。DelayQueue 更小眾一些經(jīng)典使用場(chǎng)景是定時(shí)任務(wù)調(diào)度。比如一個(gè)訂單超過(guò) 30 分鐘未支付就自動(dòng)關(guān)閉可以把任務(wù)放入 DelayQueue延遲到期了才出隊(duì)被線程執(zhí)行。網(wǎng)上很多循環(huán)掃描數(shù)據(jù)庫(kù)的實(shí)現(xiàn)性能和實(shí)時(shí)性都不好用 DelayQueue 內(nèi)存里做一版效果立竿見(jiàn)影。不過(guò)要注意應(yīng)用重啟后延遲隊(duì)列里的任務(wù)全部丟失所以它只能作為短時(shí)近實(shí)時(shí)調(diào)度不能完全替代持久化任務(wù)系統(tǒng)。4. 從配置到落地線程池的完整實(shí)戰(zhàn)4.1 手寫(xiě)一套靠譜的線程池配置先給出一份可以直接借鑒的代碼。假設(shè)場(chǎng)景是一個(gè)外賣平臺(tái)的訂單推送服務(wù)每個(gè)推送請(qǐng)求需要經(jīng)過(guò)鑒權(quán)、消息組裝、渠道發(fā)送三個(gè)步驟單次任務(wù)平均 50ms高峰期每秒約 300 個(gè)推送請(qǐng)求系統(tǒng)要求任務(wù)不能丟失盡量不阻塞主流程。我給的初始配置是這樣的ExecutorService pushPool new ThreadPoolExecutor( 40, 80, 60L, TimeUnit.SECONDS, new LinkedBlockingQueueRunnable(1500), new NamedThreadFactory(order-push), new CallerRunsPolicy() );為什么這么配我來(lái)解釋一下計(jì)算思路。核心線程數(shù) 40基于“每秒 300 個(gè)任務(wù)單任務(wù) 50ms”來(lái)毛估一個(gè)線程每秒能處理約 20 個(gè)任務(wù)1000ms / 50ms那 40 個(gè)線程每秒能處理 800 個(gè)任務(wù)已經(jīng)覆蓋峰值流量。留有一定余量但也不至于線程數(shù)過(guò)多。隊(duì)列容量 1500按照“高峰期排隊(duì)不超過(guò) 5 秒”的目標(biāo)來(lái)定300 x 5 1500。這 5 秒是給突發(fā)流量預(yù)留的緩沖如果持續(xù)打滿隊(duì)列還繼續(xù)超過(guò) 5 秒那就說(shuō)明下游發(fā)送渠道有性能問(wèn)題應(yīng)該觸發(fā)降級(jí)而不是無(wú)限等。最大線程數(shù) 80是為了在隊(duì)列塞滿后快速擴(kuò)線程覆蓋多出來(lái)的流量。多出的 40 個(gè)線程就相當(dāng)于臨時(shí)應(yīng)急力量配合 60 秒的 keepAliveTime流量高峰過(guò)去后它們會(huì)被回收。拒絕策略選 CallerRunsPolicy這里是基于業(yè)務(wù)訴求的推送任務(wù)不能丟那么當(dāng)線程池飽和時(shí)由提交任務(wù)的線程自己執(zhí)行。代價(jià)是可能阻塞調(diào)用方的主流程但在“不能丟任務(wù)”和“不能被阻塞”之間只能二選一這里我們先?！安粊G”。如果你連阻塞也不能接受那就要把被拒絕的任務(wù)持久化到自己封裝的重試隊(duì)列里這就不是單純線程池能解決的問(wèn)題了。4.2 核心參數(shù)的調(diào)整路徑與壓測(cè)方法配置不是一次定死的我習(xí)慣的做法是先按估算定初值再用壓測(cè)驗(yàn)證最后觀察線上指標(biāo)調(diào)整。壓測(cè)的時(shí)候重點(diǎn)關(guān)注四個(gè)數(shù)據(jù)QPS每秒處理任務(wù)數(shù)、任務(wù)平均耗時(shí)、線程池活躍線程數(shù)、隊(duì)列積壓量。用 JMeter 或者自寫(xiě)腳本從低并發(fā)逐步往上加觀察隊(duì)列積壓是否持續(xù)增長(zhǎng)。如果 QPS 增長(zhǎng)到某個(gè)點(diǎn)后不再上升、隊(duì)列積壓直線上升說(shuō)明瓶頸在線程池下游要去看下游依賴的資源水位。線上運(yùn)行后給自己配一個(gè)監(jiān)控看板。我常用的是 Spring Boot 的 Actuator 暴露線程池指標(biāo)或者自己在代碼里定時(shí)打點(diǎn)輸出核心指標(biāo)像這樣private void printPoolMetrics(ThreadPoolExecutor pool) { logger.info(pool size{}, active{}, queued{}, completed{}, taskCount{}, pool.getPoolSize(), pool.getActiveCount(), pool.getQueue().size(), pool.getCompletedTaskCount(), pool.getTaskCount()); }一個(gè)靠譜的判斷標(biāo)準(zhǔn)是持續(xù)運(yùn)行下活躍線程數(shù)不應(yīng)該長(zhǎng)期貼近 maximumPoolSize隊(duì)列積壓量應(yīng)該保持在一個(gè)可控水位會(huì)自行回落。如果活躍線程數(shù)長(zhǎng)期封頂說(shuō)明你的擴(kuò)展能力已經(jīng)耗盡要么擴(kuò)容要么治理任務(wù)本身。4.3 為什么不建議直接使用 Executors 的工具方法把 Executors 單獨(dú)拿出來(lái)說(shuō)是因?yàn)樗切率肿钊菀撞鹊目又?。Executors.newFixedThreadPool(10) 用的是無(wú)界隊(duì)列 LinkedBlockingQueue隱患是任務(wù)無(wú)限堆積。Executors.newCachedThreadPool() 用 SynchronousQueue 無(wú)界線程數(shù)隱患是高并發(fā)下線程數(shù)暴漲。Executors.newScheduledThreadPool() 用于定時(shí)調(diào)度場(chǎng)景確實(shí)方便但同樣要注意異常吞掉的問(wèn)題。寫(xiě)業(yè)務(wù)代碼的時(shí)候工具方法確實(shí)省事但生產(chǎn)環(huán)境不可控因素太多我的原則是手寫(xiě) ThreadPoolExecutor 并為每個(gè)參數(shù)賦予明確含義。這樣不管是做容量評(píng)估、故障排查還是后續(xù)調(diào)整參數(shù)都有一個(gè)清晰的參照系。多寫(xiě)十行配置代碼換來(lái)的是更好的可維護(hù)性這筆賬怎么算都不虧。4.4 線程池在使用中的更多細(xì)節(jié)線程池提交任務(wù)有兩種方式execute() 和 submit()。execute 沒(méi)有返回值任務(wù)拋出的異常會(huì)直接打到線程的異常處理器submit 會(huì)返回一個(gè) Future異常被封裝在 Future 里你調(diào)用 get() 時(shí)才會(huì)拋出。很多線上日志里看不到錯(cuò)誤就是因?yàn)橛昧?submit 之后沒(méi)有拿 get() 結(jié)果異常被靜默吞掉了。這是個(gè)非常隱蔽的坑。解決方式一個(gè)是任務(wù)內(nèi)部自己 try/catch明確記錄日志另一個(gè)是如果不需要返回值就統(tǒng)一用 execute需要用 submit就一定要對(duì) Future 做異常消費(fèi)。別在提交處只寫(xiě)一句 pool.submit(...) 就完事異常遲早會(huì)咬你一口。ThreadPoolExecutor 還支持鉤子方法beforeExecute、afterExecute、terminated?？梢栽?afterExecute 里統(tǒng)計(jì)任務(wù)執(zhí)行耗時(shí)自動(dòng)記錄慢任務(wù)日志。這個(gè)對(duì)定位“哪類任務(wù)拖垮線程池”很有幫助我維護(hù)的系統(tǒng)中就加了一個(gè) afterExecute 的慢任務(wù)告警邏輯效果很明顯。再說(shuō)一下多線程池的隔離策略。如果你的應(yīng)用里有多個(gè)不同的業(yè)務(wù)鏈路比如一個(gè)是訂單處理、一個(gè)是消息推送、一個(gè)是日志上報(bào)不要把它們共用一個(gè)線程池。一個(gè)任務(wù)積壓會(huì)把所有業(yè)務(wù)拖垮。正確的做法是不同業(yè)務(wù)用不同的線程池甚至給核心鏈路的線程池單獨(dú)設(shè)定較高的優(yōu)先級(jí)。這就是所謂的線程池隔離。鏈路 A 堵死只影響 A不至于整個(gè)應(yīng)用癱瘓。5. 幾個(gè)真實(shí)故障復(fù)盤(pán)與問(wèn)題速查5.1 場(chǎng)景一隊(duì)列無(wú)界導(dǎo)致內(nèi)存暴漲我有個(gè)朋友維護(hù)過(guò)一套文件轉(zhuǎn)碼服務(wù)用 Executors.newFixedThreadPool(20) 寫(xiě)的每來(lái)一個(gè)轉(zhuǎn)碼任務(wù)就 submit 進(jìn)去。平時(shí)任務(wù)量不大沒(méi)出過(guò)問(wèn)題。直到某天業(yè)務(wù)方搞了一次大批量歷史文件補(bǔ)轉(zhuǎn)碼一次推了幾十萬(wàn)個(gè)任務(wù)進(jìn)來(lái)。隊(duì)列無(wú)界任務(wù)對(duì)象全部積壓在內(nèi)存里每個(gè)任務(wù)還帶著原始文件路徑和元數(shù)據(jù)JVM 老年代直接被打滿Full GC 頻繁到服務(wù)失去響應(yīng)。復(fù)盤(pán)結(jié)論線程池的“緩沖能力”不是無(wú)限的無(wú)界隊(duì)列在流量洪峰下就是一顆定時(shí)炸彈。解決方案就是把隊(duì)列改成有界并且設(shè)置合理的 maximumPoolSize 和拒絕策略把壓力擋在系統(tǒng)能承受的范圍之外。5.2 場(chǎng)景二核心線程數(shù)配置過(guò)大導(dǎo)致資源浪費(fèi)另一個(gè)案例是一個(gè)內(nèi)部管理平臺(tái)峰值并發(fā)只有一二十結(jié)果運(yùn)維照著網(wǎng)上的模板把 corePoolSize 配了 100。100 個(gè)常駐線程每個(gè)分配 1MB ?？臻g保守估計(jì)光線程棧就占了 100MB 內(nèi)存。雖然不至于宕機(jī)但白白浪費(fèi)了很多資源。而且線程池還有鎖競(jìng)爭(zhēng)的成本線程越多上下文切換越明顯。復(fù)盤(pán)結(jié)論corePoolSize 的確定要基于業(yè)務(wù)流量的真實(shí)水位而不是按“寧可多配不可少配”的思路來(lái)。畢竟這些線程是長(zhǎng)期駐留的配多了就是天天交房租卻不用房間。5.3 場(chǎng)景三拒絕策略觸發(fā)后任務(wù)悄然消失某數(shù)據(jù)同步項(xiàng)目用的 DiscardPolicy當(dāng)時(shí)覺(jué)得反正是異步同步偶爾丟幾條數(shù)據(jù)也沒(méi)關(guān)系。結(jié)果某次上游業(yè)務(wù)調(diào)整同步任務(wù)量翻了幾倍線程池頻繁觸發(fā)拒絕策略幾千條數(shù)據(jù)被靜默丟棄。直到下游報(bào)表數(shù)據(jù)對(duì)不上翻代碼才發(fā)現(xiàn)是拒絕策略吞了任務(wù)。復(fù)盤(pán)結(jié)論對(duì)“允許丟棄”的判定必須非常謹(jǐn)慎。即使允許丟棄也最好在丟棄策略里打一條告警日志或者做一個(gè)計(jì)數(shù)器上報(bào)到監(jiān)控平臺(tái)。不要讓任務(wù)“消失”得無(wú)聲無(wú)息。5.4 常見(jiàn)問(wèn)題速查表問(wèn)題現(xiàn)象可能原因處理建議任務(wù)一直排隊(duì)不執(zhí)行隊(duì)列過(guò)大或核心線程數(shù)不足檢查隊(duì)列容量與任務(wù)提交速率調(diào)整隊(duì)列或核心線程數(shù)線程數(shù)持續(xù)逼近 maximumPoolSize任務(wù)執(zhí)行慢下游性能瓶頸排查任務(wù)內(nèi)部耗時(shí)優(yōu)化下游調(diào)用而不是盲目調(diào)大線程數(shù)線程池拒絕任務(wù)但無(wú)日志使用了 DiscardPolicy 或 DiscardOldestPolicy自研拒絕策略加入告警和日志應(yīng)用停止時(shí)卡住不退線程池未調(diào)用 shutdown注冊(cè) JVM 關(guān)閉鉤子統(tǒng)一 shutdown任務(wù)異常未捕獲也沒(méi)日志使用 submit 后未消費(fèi) Future用 execute 或?qū)?Future 做異常處理線程名全是 pool-x-thread-y未自定義 ThreadFactory自定義業(yè)務(wù)線程名便于定位6. 我對(duì)線程池配置的個(gè)人經(jīng)驗(yàn)總結(jié)這些年我配過(guò)很多線程池從最初的照抄模板到后來(lái)能按業(yè)務(wù)場(chǎng)景自己算參數(shù)最大的體會(huì)是線程池的參數(shù)不是孤立數(shù)學(xué)題每一個(gè)數(shù)字背后都應(yīng)該對(duì)應(yīng)一個(gè)業(yè)務(wù)指標(biāo)。你問(wèn)自己三個(gè)問(wèn)題配置就不會(huì)跑偏高峰期每秒多少任務(wù)單個(gè)任務(wù)要跑多久系統(tǒng)允許任務(wù)排多久隊(duì)其實(shí)最后說(shuō)個(gè)比較容易被忽略的點(diǎn)線程池的配置不是“配完就不管了”。它像一個(gè)小型交通樞紐線上流量一變它的行為就要重新評(píng)估。所以我習(xí)慣在每個(gè)迭代版本里順手看一眼線程池的監(jiān)控指標(biāo)重點(diǎn)觀察隊(duì)列水位和活躍線程數(shù)養(yǎng)成這個(gè)習(xí)慣之后很多并發(fā)問(wèn)題都在萌芽階段就被發(fā)現(xiàn)了。如果你想在并發(fā)編程上深入一步建議自己動(dòng)手寫(xiě)幾個(gè)不同組合參數(shù)的小實(shí)驗(yàn)觀察線程創(chuàng)建時(shí)機(jī)、任務(wù)執(zhí)行順序、拒絕行為實(shí)測(cè)一遍比看十篇文章都管用。