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