我看過不少簡(jiǎn)歷寫“熟悉 Java 并發(fā)編程”的人很多但一聊到資源隔離大多數(shù)人只會(huì)背一句話用線程池隔離再用信號(hào)量限流。你再追問一句ThreadPoolExecutor 在提交任務(wù)時(shí)底層是怎么把任務(wù)塞進(jìn)隊(duì)列的Semaphore 的計(jì)數(shù)器是靠什么保證原子性的場(chǎng)面往往會(huì)安靜三秒鐘。這篇文章不打算念課本我就站在面試官和一線開發(fā)者的角度把 Java 資源隔離這件事拆透了。核心就兩個(gè)類ThreadPoolExecutor 和 Semaphore配合源碼逐行講清楚順便給出一套能直接抄進(jìn)項(xiàng)目的組合玩法。無論你是準(zhǔn)備面試還是正在治理線上故障這篇文章都能給你一些硬貨。1. 資源隔離在解決什么問題1.1 從一次線上事故說起先講個(gè)真實(shí)場(chǎng)景。訂單服務(wù)要調(diào)用外部會(huì)員接口這個(gè)會(huì)員接口平時(shí)很穩(wěn)但有一次大促它突然變慢單次響應(yīng)從 20ms 漲到 5 秒。訂單服務(wù)用的 Tomcat 默認(rèn)線程池200 個(gè)線程很快就全部阻塞在這個(gè)下游調(diào)用上。結(jié)果是一個(gè)下游慢接口把整個(gè)訂單服務(wù)拖到癱瘓連不依賴會(huì)員接口的庫(kù)存查詢、優(yōu)惠券計(jì)算也跟著不可用。這就是典型的缺乏資源隔離。沒有把“不同依賴、不同業(yè)務(wù)”之間的線程資源物理隔開時(shí)任何一個(gè)慢通道都可能成為系統(tǒng)的癌癥。解決思路有兩個(gè)要么給不同依賴分配獨(dú)立線程池要么用信號(hào)量控制并發(fā)訪問的下限和上限。這兩個(gè)方案在面試?yán)锉环磸?fù)問在工程里也被反復(fù)用但很多人只是聽過名詞沒有真正理解它們的邊界。1.2 線程池隔離和信號(hào)量隔離的本質(zhì)區(qū)別先別急著背概念我用大白話解釋。線程池隔離本質(zhì)是給每個(gè)子系統(tǒng)或外部依賴劃一塊“獨(dú)立的地盤”。比如 A 調(diào)用用線程池 AB 調(diào)用用線程池 BA 慢成狗最多消耗完 A 池子里的線程B 池子依然有可用線程業(yè)務(wù)照跑。這種隔離更徹底因?yàn)樗丫€程資源物理分隔開了。缺點(diǎn)也明顯創(chuàng)建多個(gè)線程池意味著更多線程、更多上下文切換、更高內(nèi)存占用而且線程池內(nèi)部的任務(wù)如果長(zhǎng)時(shí)間阻塞池里的線程還是會(huì)被占住。信號(hào)量隔離則是給某個(gè)共享資源或某條調(diào)用鏈路設(shè)一個(gè)并發(fā)通行上限。Semaphore 本身不創(chuàng)建線程它只維護(hù)一個(gè)許可證計(jì)數(shù)器線程執(zhí)行前申請(qǐng)?jiān)S可證執(zhí)行完歸還。它可以精準(zhǔn)控制“同一時(shí)刻最多有多少個(gè)線程在跑這段代碼”但對(duì)“誰去跑這些任務(wù)”不關(guān)心。它的優(yōu)勢(shì)是輕量、靈活缺點(diǎn)是沒有真正的隔離邊界如果其他模塊也在使用同一個(gè)線程池信號(hào)量只能限制這一把閘門擋不住別人把線程耗盡。表格對(duì)比看起來更直觀對(duì)比項(xiàng)線程池隔離信號(hào)量隔離隔離資源線程資源并發(fā)許可數(shù)量是否創(chuàng)建線程創(chuàng)建并管理線程不創(chuàng)建線程性能開銷較高線程切換有成本較低CAS 成本遠(yuǎn)小于線程切換防護(hù)目標(biāo)防止某個(gè)調(diào)用耗盡所有線程防止某個(gè)調(diào)用超出并發(fā)上限典型使用場(chǎng)景不同下游依賴分別獨(dú)立執(zhí)行控制數(shù)據(jù)庫(kù)連接、外部接口并發(fā)1.3 面試官想聽到的選型邏輯面試官問“你選線程池隔離還是信號(hào)量隔離”他不是真想聽你背定義而是想看你有沒有工程判斷力。我的選型邏輯一般來說是這樣如果下游依賴質(zhì)量不可控比如第三方接口經(jīng)常超時(shí)、響應(yīng)時(shí)間波動(dòng)巨大優(yōu)先線程池隔離因?yàn)樗鼙Ｗo(hù)整個(gè) JVM 的線程資源不被一個(gè)依賴拖垮。如果只是單純想限制某個(gè)熱點(diǎn)操作的并發(fā)量比如防止數(shù)據(jù)庫(kù)連接被打滿、防止緩存穿透時(shí)大量請(qǐng)求同時(shí)打到后端用信號(hào)量更合適畢竟線程池的成本擺在那里為每個(gè)接口各開一個(gè)池子資源浪費(fèi)嚴(yán)重。還有一個(gè)容易被忽略的點(diǎn)線程池隔離通常配合超時(shí)時(shí)間用比如 Future.get(timeout)否則線程池再隔離任務(wù)拿不到結(jié)果也不會(huì)釋放線程時(shí)間長(zhǎng)了照樣把池子占滿。信號(hào)量隔離則可以配合 tryAcquire(timeout)拿不到許可就快速失敗或降級(jí)比無限阻塞優(yōu)雅得多。2. ThreadPoolExecutor 源碼級(jí)拆解2.1 七個(gè)構(gòu)造參數(shù)每個(gè)參數(shù)暗藏坑ThreadPoolExecutor 有七個(gè)參數(shù)很多人背得滾瓜爛熟但真正被問到底層含義時(shí)容易翻車。逐個(gè)過一遍重點(diǎn)說容易被誤解的地方。corePoolSize核心線程數(shù)。默認(rèn)情況下核心線程創(chuàng)建后即使空閑也不會(huì)被回收。maximumPoolSize最大線程數(shù)。線程池允許存在的最大線程數(shù)量。keepAliveTime非核心線程空閑存活時(shí)間。如果 allowCoreThreadTimeOut 為 true核心線程也會(huì)受這個(gè)參數(shù)影響。unit時(shí)間單位和 keepAliveTime 配合使用。workQueue工作隊(duì)列存放來不及執(zhí)行的任務(wù)。threadFactory線程工廠用于創(chuàng)建線程可以自定義線程名、優(yōu)先級(jí)、是否守護(hù)線程。handler拒絕策略當(dāng)線程池?zé)o法接收新任務(wù)時(shí)執(zhí)行的兜底方案。第一個(gè)坑很多人以為“任務(wù)來了先創(chuàng)建核心線程核心線程滿了直接創(chuàng)建非核心線程”。不對(duì)真正的順序是任務(wù)來了優(yōu)先創(chuàng)建核心線程跑核心線程滿了任務(wù)進(jìn)隊(duì)列隊(duì)列也滿了才會(huì)創(chuàng)建非核心線程線程數(shù)達(dá)到 maximumPoolSize 且隊(duì)列還是滿觸發(fā)拒絕策略。也就是說maximumPoolSize 的線程不是隨便就能創(chuàng)建的隊(duì)列滿是一個(gè)硬前提。第二個(gè)坑隊(duì)列類型的選擇直接決定線程池行為。LinkedBlockingQueue 如果不設(shè)置容量就是無界隊(duì)列任務(wù)永遠(yuǎn)堆在隊(duì)列里maximumPoolSize 形同虛設(shè)因?yàn)殛?duì)列永遠(yuǎn)不會(huì)滿非核心線程永遠(yuǎn)不會(huì)創(chuàng)建拒絕策略也永遠(yuǎn)不會(huì)觸發(fā)。SynchronousQueue 不存儲(chǔ)任務(wù)一個(gè)生產(chǎn)線程必須等待一個(gè)消費(fèi)線程適合“任務(wù)直接交給線程處理不排隊(duì)”的場(chǎng)景。ArrayBlockingQueue 有界最推薦用于生產(chǎn)環(huán)境因?yàn)槎讯嗳蝿?wù)本質(zhì)上就是堆內(nèi)存風(fēng)險(xiǎn)。2.2 execute() 提交任務(wù)的完整鏈路面試最喜歡讓把 execute 方法源碼背出來。這里直接貼 Java 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); } else if (!addWorker(command, false)) { reject(command); } }第一步判斷當(dāng)前線程數(shù)是否小于核心線程數(shù)。如果是直接 addWorker 創(chuàng)建核心線程執(zhí)行任務(wù)任務(wù)不進(jìn)隊(duì)列。addWorker 失敗說明線程池已經(jīng)處于非 RUNNING 狀態(tài)或者線程數(shù)已經(jīng)超過限制這時(shí)要重新讀取 ctl。第二步如果線程數(shù)已經(jīng)達(dá)到核心線程數(shù)并且線程池處于 RUNNING 狀態(tài)嘗試把任務(wù)放進(jìn)隊(duì)列。offer 是非阻塞入隊(duì)隊(duì)列滿了會(huì)返回 false。這里有個(gè)關(guān)鍵細(xì)節(jié)任務(wù)成功入隊(duì)后還要做一次狀態(tài)復(fù)查。為什么因?yàn)槿蝿?wù)入隊(duì)和后續(xù)檢查之間可能有人調(diào)用了 shutdown線程池狀態(tài)變成 SHUTDOWN此時(shí)不再接受新任務(wù)但任務(wù)已經(jīng)在隊(duì)列里了所以需要通過 recheck 發(fā)現(xiàn)狀態(tài)變化然后移除任務(wù)并觸發(fā)拒絕策略。如果 recheck 時(shí)發(fā)現(xiàn)線程池里一個(gè)線程都沒有了比如核心線程被全部回收還得補(bǔ)一個(gè) worker 處理隊(duì)列里的任務(wù)。第三步如果入隊(duì)失敗說明隊(duì)列滿了嘗試用 addWorker 創(chuàng)建非核心線程來執(zhí)行任務(wù)。如果非核心線程也創(chuàng)建不了說明線程數(shù)已經(jīng)到了 maximumPoolSize直接執(zhí)行拒絕策略。addWorker 里面還有一個(gè)容易被問到的細(xì)節(jié)Worker 繼承 AQS自己實(shí)現(xiàn)了一個(gè)不可重入的互斥鎖。很多人不理解為什么不直接用 ReentrantLock。原因是線程池在 shutdown 時(shí)要中斷空閑線程而在線程正在執(zhí)行任務(wù)時(shí)又不想中斷它。Worker 用 AQS 實(shí)現(xiàn)鎖執(zhí)行任務(wù)時(shí)鎖被占用interruptIdleWorkers 拿不到鎖就不會(huì)打斷正在工作的線程任務(wù)執(zhí)行完釋放鎖空閑線程可以被安全中斷。這個(gè)設(shè)計(jì)是線程池源碼里非常精妙的一筆值得反復(fù)體會(huì)。2.3 線程池狀態(tài)機(jī)和拒絕策略的源碼真相線程池內(nèi)部用 ctl 這個(gè) AtomicInteger 同時(shí)保存線程狀態(tài)和線程數(shù)量高 3 位保存 runState低 29 位保存 workerCount。源碼里大量通過位運(yùn)算來拆分這兩個(gè)值比如private static final int COUNT_BITS Integer.SIZE - 3; private static final int CAPACITY (1 COUNT_BITS) - 1; private static int runStateOf(int c) { return c ~CAPACITY; } private static int workerCountOf(int c) { return c CAPACITY; }這招非常實(shí)用用一個(gè) int 原子變量同時(shí)管理兩個(gè)字段避免加鎖。線程池共有五種狀態(tài)RUNNING 接收新任務(wù)并處理隊(duì)列任務(wù)SHUTDOWN 不接收新任務(wù)但繼續(xù)處理隊(duì)列任務(wù)STOP 不接收新任務(wù)不處理隊(duì)列任務(wù)中斷正在執(zhí)行的任務(wù)TIDYING 所有任務(wù)已結(jié)束即將執(zhí)行 terminatedTERMINATED 完全終止。狀態(tài)之間是單向流轉(zhuǎn)的shutdown 會(huì)讓 RUNNING 變成 SHUTDOWNshutdownNow 會(huì)讓 RUNNING 或 SHUTDOWN 變成 STOP。拒絕策略是最后一個(gè)兜底環(huán)節(jié)四種內(nèi)置策略各有脾氣策略行為適用場(chǎng)景AbortPolicy直接拋 RejectedExecutionException默認(rèn)策略適合明確需要感知失敗的業(yè)務(wù)CallerRunsPolicy在提交任務(wù)的線程里執(zhí)行被拒絕的任務(wù)想利用調(diào)用線程兜底降低請(qǐng)求丟棄率DiscardPolicy靜默丟棄任務(wù)不重要的日志、監(jiān)控類任務(wù)DiscardOldestPolicy丟棄隊(duì)列頭部的任務(wù)然后重新提交希望保留最核心、最新的任務(wù)時(shí)生產(chǎn)環(huán)境中我一般的做法是自定義拒絕策略落一條監(jiān)控或者告警而不是默默丟任務(wù)或者直接拋異常這樣才能及時(shí)發(fā)現(xiàn)問題。3. Semaphore 源碼級(jí)拆解3.1 AQS 是信號(hào)量的地基Semaphore 的源碼核心在內(nèi)部類 Sync而 Sync 直接繼承 AbstractQueuedSynchronizerAQS。AQS 是 Java 并發(fā)包的基石組件它提供了一個(gè) volatile int state 作為同步狀態(tài)加上一個(gè) FIFO 的等待隊(duì)列。Semaphore 的 permits 就存在這個(gè) state 里面state 表示當(dāng)前剩余許可證數(shù)量。所有對(duì)許可證的獲取和釋放本質(zhì)上都是對(duì) state 的原子操作。看 NonfairSync 的 tryAcquireShared 源碼final int nonfairTryAcquireShared(int acquires) { for (;;) { int available getState(); int remaining available - acquires; if (remaining 0 || compareAndSetState(available, remaining)) return remaining; } }這里用了一個(gè)自旋 CAS先讀當(dāng)前剩余許可證減掉申請(qǐng)的許可證數(shù)如果剩余數(shù)量小于 0說明許可證不夠直接返回負(fù)數(shù)如果足夠就用 CAS 把 state 更新成新值。如果 CAS 失敗說明有其他線程同時(shí)修改了 state就重新循環(huán)再試。CAS 是 CPU 指令級(jí)的原子操作比加鎖輕量得多。正因?yàn)橛辛?AQS 和 CASSemaphore 的并發(fā)控制才不需要額外加 synchronized。3.2 acquire/release 到底做了什么Semaphore 的 acquire 方法有多個(gè)變體無參 acquire 會(huì)響應(yīng)中斷acquireUninterruptibly 不響應(yīng)中斷tryAcquire 立即返回tryAcquire(timeout, unit) 支持超時(shí)等待。核心流程都一樣以 acquire 為例public void acquire() throws InterruptedException { sync.acquireSharedInterruptibly(1); }AQS 的 acquireSharedInterruptibly 會(huì)先嘗試 tryAcquireShared只要返回負(fù)數(shù)就說明當(dāng)前線程需要排隊(duì)等待于是把當(dāng)前線程包裝成 Node 放進(jìn)等待隊(duì)列然后通過 LockSupport.park 掛起。當(dāng)其他線程執(zhí)行 release 時(shí)會(huì)重新嘗試讓出許可證然后喚醒隊(duì)列頭部的等待線程。release 方法代碼如下public void release() { sync.releaseShared(1); }AQS 的 releaseShared 會(huì)調(diào) tryReleaseSharedSemaphore 里實(shí)現(xiàn)為 CAS 把 state 加回去然后喚醒阻塞中的線程。這里有個(gè)特別容易踩的坑Semaphore 的許可證不歸屬任何具體線程。A 線程 acquire 之后B 線程也可以把這個(gè)許可證 release 出來。所以代碼里必須保證誰申請(qǐng)、誰釋放而且釋放操作要放在 finally 里否則任務(wù)拋異常許可證就永久丟失了最終所有線程都會(huì)阻塞在 acquire 上。3.3 公平模式與非公平模式的選擇Semaphore 構(gòu)造時(shí)可以傳公平標(biāo)志比如 new Semaphore(10, true)。公平和非公平的差別在 tryAcquireShared 的實(shí)現(xiàn)上。公平版會(huì)多一個(gè)判斷protected int tryAcquireShared(int acquires) { for (;;) { if (hasQueuedPredecessors()) return -1; int available getState(); int remaining available - acquires; if (remaining 0 || compareAndSetState(available, remaining)) return remaining; } }hasQueuedPredecessors 用來檢查等待隊(duì)列里有沒有排在前面的線程。如果有當(dāng)前線程哪怕許可證足夠也不能直接拿必須老實(shí)排隊(duì)。非公平版則不管隊(duì)列先搶一把再說搶不到再排隊(duì)。實(shí)際選型的話我建議大部分場(chǎng)景用非公平模式吞吐量更高。公平模式適合對(duì)響應(yīng)順序有嚴(yán)格要求的場(chǎng)景但代價(jià)是線程頻繁被掛起喚醒性能下降明顯。還有一個(gè)折中方案是使用 tryAcquire 而不是阻塞式 acquire讓拿不到許可證的業(yè)務(wù)快速走降級(jí)邏輯而不是排隊(duì)排到超時(shí)。4. ThreadPoolExecutor Semaphore 組合玩法4.1 最常見的組合缺陷無界隊(duì)列把信號(hào)量架空很多人說“我用線程池隔離 信號(hào)量限流”但代碼一寫全錯(cuò)。最常見的是把 Semaphore 放在任務(wù)內(nèi)部executor.execute(() - { semaphore.acquire(); try { // 真實(shí)業(yè)務(wù) } finally { semaphore.release(); } });這種寫法的問題在于任務(wù)已經(jīng)提交進(jìn)了線程池隊(duì)列信號(hào)量只是控制任務(wù)內(nèi)部真正執(zhí)行的并發(fā)數(shù)。如果隊(duì)列是無界的任務(wù)會(huì)瘋狂堆積信號(hào)量再小也攔不住內(nèi)存被打爆。更嚴(yán)重的是線程池的拒絕策略在這種情況下永遠(yuǎn)不會(huì)被觸發(fā)因?yàn)槿蝿?wù)永遠(yuǎn)有地方排隊(duì)。信號(hào)量確實(shí)限制了同時(shí)執(zhí)行的任務(wù)數(shù)但沒有限制積壓任務(wù)數(shù)。所以信號(hào)量必須放在提交之前在任務(wù)還沒進(jìn)隊(duì)列時(shí)就完成限流。4.2 更合理的組合姿勢(shì)信號(hào)量包在線程池外面我推薦的做法是自定義一個(gè) ExecutorService 包裝類把信號(hào)量的 acquire 放在 execute 之前public class SemaphoreExecutorService implements ExecutorService { private final ExecutorService delegate; private final Semaphore semaphore; public SemaphoreExecutorService(ExecutorService delegate, int permits) { this.delegate delegate; this.semaphore new Semaphore(permits); } Override public void execute(Runnable command) { semaphore.acquire(); try { delegate.execute(() - { try { command.run(); } finally { semaphore.release(); } }); } catch (RejectedExecutionException e) { semaphore.release(); throw e; } } Override public T FutureT submit(CallableT task) { semaphore.acquire(); try { return delegate.submit(() - { try { return task.call(); } finally { semaphore.release(); } }); } catch (RejectedExecutionException e) { semaphore.release(); throw e; } } }這樣做的效果是信號(hào)量限制的是“已經(jīng)提交到線程池但還沒執(zhí)行完的任務(wù)總數(shù)”而不是“正在執(zhí)行的任務(wù)數(shù)”。任務(wù)一旦提交成功許可證就被占用直到任務(wù)真正執(zhí)行完才釋放。線程池的隊(duì)列里最多積壓 permits 減去核心線程數(shù)的任務(wù)量?jī)?nèi)存風(fēng)險(xiǎn)被控制住了。如果線程池已經(jīng)關(guān)閉拒絕策略觸發(fā)必須順手釋放許可證否則調(diào)用方線程在 acquire 上越等越久。細(xì)節(jié)上要特別注意submit 方法返回的 Future在異常時(shí)其實(shí)已經(jīng)在 finally 里釋放了許可證但外部拿到的 Future 會(huì)拋出 ExecutionException調(diào)用方需要捕獲并決定是否重試。重試的話會(huì)再次 acquire相當(dāng)于把流量重新放進(jìn)閘門這是合理的降級(jí)策略。4.3 配置參數(shù)計(jì)算與實(shí)測(cè)效果參數(shù)怎么定不能拍腦袋。我一般用排隊(duì)理論的 Littles Law 做估算并發(fā)線程數(shù)約等于 QPS 乘以平均響應(yīng)時(shí)間。假設(shè)目標(biāo) QPS 是 1000下游 P99 耗時(shí) 80ms那理論并發(fā)就是 1000 * 0.08 80。核心線程數(shù)取 80 到 100 之間比較合理最大線程數(shù)可以留出緩沖比如 120。隊(duì)列容量取決于你愿意讓請(qǐng)求等多久。假設(shè)容忍排隊(duì)等待 200ms那隊(duì)列容量大約等于 1000 * 0.2 200。如果信號(hào)量要控制“提交但未完成”的任務(wù)總量可以設(shè)為最大線程數(shù)加上隊(duì)列容量也就是 120 200 320。我實(shí)際的壓測(cè)經(jīng)驗(yàn)是把 Semaphore 的 permits 設(shè)置成最大線程數(shù)加隊(duì)列容量確實(shí)能保證任務(wù)不會(huì)無限堆積但在高峰期acquire 會(huì)阻塞住上游線程如果上游沒有設(shè)置超時(shí)調(diào)用方可能集體卡死。所以更穩(wěn)妥的方案是使用帶超時(shí)的 tryAcquireif (!semaphore.tryAcquire(100, TimeUnit.MILLISECONDS)) { // 快速失敗走降級(jí)邏輯 throw new ServiceUnavailableException(系統(tǒng)繁忙); }這樣等于把信號(hào)量從“阻塞閘門”變成了“快速失敗閘門”。對(duì)調(diào)用方來說拿不到許可證直接返回 503 或者提示稍后重試遠(yuǎn)比默默排隊(duì)然后超時(shí)好。我曾經(jīng)在壓測(cè)環(huán)境對(duì)比過不加信號(hào)量時(shí)線程池隊(duì)列積壓 2 萬任務(wù)接口響應(yīng)時(shí)間從 80ms 漲到 8 秒加上信號(hào)量并開啟快速失敗后響應(yīng)時(shí)間穩(wěn)定在 100ms 左右失敗率控制在 5% 以內(nèi)用戶體驗(yàn)反而好得多因?yàn)槭∈橇⒖谭祷氐恼?qǐng)求不會(huì)堆積成雪崩。5. 面試連環(huán)炮與避坑實(shí)戰(zhàn)5.1 高頻追問 Top 5把我面試別人和被別人面試遇到的問題整理一下排名不分先后。corePoolSize 和 maximumPoolSize 之間線程數(shù)是怎么變化的很多人的答案是錯(cuò)的。真實(shí)順序是核心線程 → 隊(duì)列 → 非核心線程 → 拒絕策略。隊(duì)列滿是非核心線程創(chuàng)建的前提。ThreadPoolExecutor 的 Worker 為什么要繼承 AQS簡(jiǎn)單回答是為了實(shí)現(xiàn)一個(gè)不可重入鎖讓中斷空閑線程時(shí)不會(huì)誤傷正在執(zhí)行任務(wù)的線程。能說到這一層基本就過關(guān)了。Semaphore 和 CountDownLatch 有什么區(qū)別Semaphore 是控制并發(fā)數(shù)量的計(jì)數(shù)器可以反復(fù) acquire/releaseCountDownLatch 是門閂只能等待指定數(shù)量的線程完成后放行不能復(fù)位。信號(hào)量能不能完全替代線程池隔離不能。信號(hào)量不創(chuàng)建線程不隔離線程資源如果系統(tǒng)只有一條線程在跑業(yè)務(wù)用信號(hào)量等于自己打自己。線程池隔離解決的是資源獨(dú)占問題信號(hào)量解決的是并發(fā)上限問題。execute 提交任務(wù)時(shí)任務(wù)先入隊(duì)還是先創(chuàng)建非核心線程先入隊(duì)隊(duì)列滿才創(chuàng)建非核心線程。原因是為了復(fù)用核心線程盡量避免線程數(shù)量頻繁擴(kuò)展收縮。5.2 我在生產(chǎn)環(huán)境踩過的三個(gè)坑第一個(gè)坑是信號(hào)量許可證泄漏。早期做接口級(jí)限流時(shí)業(yè)務(wù)代碼在 acquire 之后出現(xiàn)了異常release 寫在了 try 塊之外的某個(gè)分支里異常路徑直接跳過 release。線上跑了三天所有線程全部阻塞在 acquire服務(wù)完全不可用。排查時(shí) jstack 一看全是 WAITING 狀態(tài)立刻意識(shí)到許可證沒了。從那以后我給自己定了一條死規(guī)矩acquire 緊跟 try-finallyrelease 永遠(yuǎn)在 finally 里。第二個(gè)坑是使用無界隊(duì)列配合線程池隔離。當(dāng)時(shí)為了性能用了默認(rèn)容量的 LinkedBlockingQueue結(jié)果某個(gè)慢依賴把隊(duì)列積壓到幾萬個(gè)任務(wù)內(nèi)存蹭蹭往上漲。最后通過對(duì)堆轉(zhuǎn)儲(chǔ)的分析發(fā)現(xiàn)大量 Runnable 對(duì)象堆積成串。后來統(tǒng)一換成了有界隊(duì)列并且把拒絕策略改成自定義策略記錄告警而不是拋異常。第三個(gè)坑是 CallerRunsPolicy 和信號(hào)量疊加的隱藏問題。如果信號(hào)量包在提交之前而線程池的拒絕策略是 CallerRunsPolicy被拒絕的任務(wù)會(huì)在調(diào)用方線程里同步執(zhí)行。這意味著調(diào)用方線程既要走 acquire 等待許可證又要負(fù)責(zé)跑任務(wù)非常容易導(dǎo)致調(diào)用方線程阻塞然后調(diào)用鏈路上游的資源也被占用。所以組合彈窗時(shí)要么用 CallerRunsPolicy 但把信號(hào)量的 acquire 放在包裝層之外并且使用 tryAcquire要么干脆用自定義拒絕策略做降級(jí)。5.3 排查資源耗盡問題的工具與方法線上遇到線程池被打滿或者信號(hào)量全部被占用時(shí)我最常用的排查手段是 jstack。直接看線程棧jstack pid在 dump 文件中搜索線程池名稱或者 ThreadPoolExecutor 相關(guān)的關(guān)鍵字可以看到哪些線程卡在 acquire 上哪些線程在執(zhí)行任務(wù)。如果大量線程處于 WAITING 狀態(tài)并且棧頂指向 AbstractQueuedSynchronizer 的 parkAndCheckInterrupt說明信號(hào)量許可證已經(jīng)耗盡。如果線程處于 RUNNABLE 但堆棧里任務(wù)執(zhí)行時(shí)間異常久說明某個(gè)下游調(diào)用沒有超時(shí)保護(hù)。線程池自身的監(jiān)控指標(biāo)也不能少。ThreadPoolExecutor 提供了 getActiveCount、getQueue().size()、getCompletedTaskCount 等方法可以接入 Micrometer 或 Prometheus 做實(shí)時(shí)監(jiān)控。我習(xí)慣同時(shí)監(jiān)控三個(gè)核心指標(biāo)活躍線程數(shù)是否逼近 maximumPoolSize、隊(duì)列大小是否持續(xù)上漲、任務(wù)拒絕次數(shù)是否大于零。這三個(gè)指標(biāo)任何一項(xiàng)異常都說明資源隔離策略需要重新調(diào)整。還有一個(gè)診斷利器是 Arthas線上環(huán)境不用重啟就能執(zhí)行thread -n 3可以看到 CPU 占用最高的線程?？焖俣ㄎ皇悄膫€(gè)業(yè)務(wù)類在占線程。排查信號(hào)量問題時(shí)還可以用 Arthas 的 watch 命令觀察 acquire 方法的調(diào)用頻率和阻塞時(shí)間判斷限流是否提前觸發(fā)。最后分享一個(gè)小技巧給線程池起名字。用 ThreadFactory 自定義線程名比如 OrderService-Pool-1線上查 jstack 時(shí)一眼就能看出是哪個(gè)業(yè)務(wù)鏈路出了問題不用對(duì)著 thread-12 這種默認(rèn)名字猜半天。一個(gè)合格的 Java 開發(fā)者應(yīng)該把這種細(xì)節(jié)刻進(jìn)肌肉記憶。說到底ThreadPoolExecutor 和 Semaphore 的組合核心思路不是“用兩個(gè)鎖工具”而是用線程池解決資源邊界問題用信號(hào)量解決并發(fā)入口問題。真正理解了源碼的思想才能在面試時(shí)對(duì)答如流在線上問題時(shí)臨危不亂。如果你在項(xiàng)目里也有類似的隔離實(shí)踐歡迎按這個(gè)思路去給團(tuán)隊(duì)做一次分享踩坑的經(jīng)歷就是最有說服力的教案。