做并發(fā)開發(fā)的前幾年我最怕別人問“JUC包里到底有哪些東西”。不是不會(huì)用而是記不住。ReentrantLock、ConcurrentHashMap、線程池、Semaphore、CountDownLatch單獨(dú)拎出來都能寫點(diǎn)Demo可真到項(xiàng)目里要做鎖等待超時(shí)、要做限流、要做任務(wù)匯總就不知道該選誰更不知道出了性能問題該往哪個(gè)方向查。后來我把JUC的設(shè)計(jì)主線捋了一遍才發(fā)現(xiàn)它根本不是一團(tuán)散沙底層是CAS和volatile上面長出了AQS這套“排隊(duì)加阻塞喚醒”的鎖框架再往上才是Lock、并發(fā)容器、原子類、線程池、并發(fā)工具類。這篇JUC并發(fā)編程的“下篇”就沿著這條主線做一次基礎(chǔ)速成把最常上手的組件一次講透。目標(biāo)很簡(jiǎn)單看完之后面對(duì)并發(fā)場(chǎng)景你能判斷出該用什么也知道為什么用它。1. AQSJUC的地基不讀懂它基本靠背很多人學(xué)JUC時(shí)先把API背一遍結(jié)果幾天就忘。原因在于不知道這些類在解決同一個(gè)底層問題。AQSAbstractQueuedSynchronizer幾乎撐起了JUC半壁江山ReentrantLock、Semaphore、CountDownLatch、ReentrantReadWriteLock內(nèi)部都有一個(gè)繼承AQS的同步器Sync。把AQS搞明白這些類在你眼里就不是孤立的API而是同一個(gè)模板換了幾套參數(shù)。1.1 state鎖的本質(zhì)是一個(gè)可原子操作的整數(shù)AQS內(nèi)部維護(hù)了一個(gè)volatile修飾的int變量state所有同步邏輯都圍繞它展開。它是什么含義由子類自己定ReentrantLock里它表示“當(dāng)前線程重入鎖的次數(shù)”Semaphore里它表示“剩余許可數(shù)量”CountDownLatch里它表示“還需要等待多少個(gè)事件”?？梢园阉斫獬梢粔K共享計(jì)數(shù)板所有線程的競(jìng)爭(zhēng)都落在這塊板上。對(duì)state的修改不能有半點(diǎn)含糊必須原子。AQS里統(tǒng)一用compareAndSetState方法底層就是CAS指令。有了volatile保證可見性有了CAS保證原子性這塊板上每一次加減都能被所有線程看到且不會(huì)錯(cuò)亂。理解AQS的鑰匙其實(shí)就兩把一個(gè)volatile int一個(gè)等待隊(duì)列。1.2 等待隊(duì)列搶鎖失敗的線程不是死等而是去排隊(duì)當(dāng)線程嘗試獲取同步狀態(tài)失敗時(shí)AQS會(huì)把它封裝成一個(gè)Node節(jié)點(diǎn)掛到一個(gè)FIFO的雙向隊(duì)列尾部然后阻塞自己。等持有鎖的線程釋放后會(huì)喚醒隊(duì)列中等待最久的下一個(gè)節(jié)點(diǎn)讓它重新嘗試搶鎖。這個(gè)設(shè)計(jì)可以用銀行柜臺(tái)來類比。你到柜臺(tái)辦事發(fā)現(xiàn)窗口有人占用不能一直在窗口前站著而是取號(hào)排隊(duì)。前面的人辦完叫號(hào)系統(tǒng)通知下一個(gè)。AQS里的CLH隊(duì)列變體就是這個(gè)“叫號(hào)系統(tǒng)”隊(duì)列里的節(jié)點(diǎn)就是號(hào)牌。這套機(jī)制避免了線程空轉(zhuǎn)自旋浪費(fèi)CPU也讓鎖的競(jìng)爭(zhēng)變得有序。有人問為什么阻塞喚醒比自旋好簡(jiǎn)單說就是自旋是讓出CPU時(shí)間片但還在“忙等”線程狀態(tài)一直是RUNNABLE高并發(fā)下大量線程自旋會(huì)把CPU打滿而阻塞有一套完整的掛起和喚醒機(jī)制線程不消耗CPU代價(jià)是上下文切換。AQS在最初幾次嘗試失敗后選擇入隊(duì)阻塞是一個(gè)典型的“快速失敗然后優(yōu)雅等待”策略。1.3 模板方法模式骨架固定鉤子開放AQS最巧妙的設(shè)計(jì)是用了模板方法模式。獲取和釋放同步狀態(tài)的流程骨架已經(jīng)寫死acquire先嘗試tryAcquire成功就直接拿到鎖失敗則入隊(duì)并阻塞喚醒后再循環(huán)嘗試release先嘗試tryRelease成功后喚醒隊(duì)列里的下一個(gè)等待線程關(guān)鍵在于tryAcquire和tryRelease這兩個(gè)方法AQS默認(rèn)拋異常由子類去實(shí)現(xiàn)。于是不同組件只需要回答兩個(gè)問題“我怎樣算拿到鎖”和“我怎樣算釋放鎖”。ReentrantLock就實(shí)現(xiàn)成了“state從0變成1并且記錄持有線程”Semaphore實(shí)現(xiàn)成了“state大于0就減1否則失敗”CountDownLatch實(shí)現(xiàn)成了“state不為0就失敗直到歸零”。如果哪天你需要自定義一個(gè)同步器比如實(shí)現(xiàn)一個(gè)只允許兩個(gè)線程同時(shí)訪問的資源自己寫一個(gè)類繼承AQS實(shí)現(xiàn)tryAcquire和tryRelease即可排隊(duì)和喚醒的臟活累活A(yù)QS全包了。1.4 公平鎖與非公平鎖就差一個(gè)hasQueuedPredecessors曾有人問ReentrantLock的公平和非公平有什么區(qū)別。代碼層面看差別小得驚人。非公平鎖的lock方法會(huì)先直接CAS搶一次state不管現(xiàn)在有沒有人在排隊(duì)搶不到才走AQS標(biāo)準(zhǔn)流程。公平鎖則在搶鎖前先調(diào)用hasQueuedPredecessors檢查隊(duì)列里有沒有排在自己前面的線程如果有就絕不插隊(duì)。用生活場(chǎng)景說非公平鎖是“窗口剛辦完一個(gè)業(yè)務(wù)新來的客戶眼疾手快直接補(bǔ)位”雖然侵害了排隊(duì)者的權(quán)益但反饋快、吞吐量高公平鎖是“新來的客戶先看看隊(duì)伍里有沒有人等有就老實(shí)排隊(duì)”。實(shí)際開發(fā)中除非業(yè)務(wù)對(duì)公平性有強(qiáng)要求一般優(yōu)先非公平鎖因?yàn)樗鼫p少了線程切換性能更好。公平鎖的代價(jià)是額外的排隊(duì)檢查還有可能降低吞吐。提示AQS這套設(shè)計(jì)里還有中斷響應(yīng)、超時(shí)等擴(kuò)展但基礎(chǔ)用法階段不需要每個(gè)字都吃透。把“state 隊(duì)列 模板方法”這三件事裝進(jìn)腦子后續(xù)的Lock和工具類就等于白送。2. 從synchronized到Lock體系鎖粒度與可控性的全面升級(jí)很多Java初學(xué)者知道synchronized卻在第一次看到Lock時(shí)困惑是synchronized不香了嗎其實(shí)兩者不是替代關(guān)系而是不同維度的工具。synchronized由JVM管理進(jìn)入代碼塊自動(dòng)加鎖退出自動(dòng)釋放Lock是純Java的接口一切獲取和釋放都交給開發(fā)者換來的是中斷、超時(shí)、多條件、公平性這些synchronized給不了的控制力。2.1 synchronized給不了的三個(gè)能力synchronized最讓人頭疼的是“鎖死了沒法干預(yù)”。一個(gè)線程拿著鎖執(zhí)行耗時(shí)操作其他線程只能在門口無限期等著連中斷信號(hào)都遞不進(jìn)去。Lock體系的第一個(gè)升級(jí)就是可中斷l(xiāng)ockInterruptibly()讓等待鎖的線程可以響應(yīng)中斷信號(hào)主動(dòng)放棄等待。第二個(gè)升級(jí)是可超時(shí)。tryLock(3, TimeUnit.SECONDS)等三秒拿不到鎖就放棄返回false。這種能力在解決死鎖時(shí)特別好用兩個(gè)線程互相持鎖等待時(shí)只要其中一個(gè)用帶超時(shí)的tryLock就能主動(dòng)退一步打破循環(huán)。第三個(gè)升級(jí)是多個(gè)條件隊(duì)列。synchronized搭配wait/notify時(shí)只有一個(gè)等待池notifyAll會(huì)喚醒所有線程經(jīng)常造成“該醒的沒醒、不該醒的醒了”。Lock可以new出多個(gè)Condition每個(gè)Condition相當(dāng)于一條獨(dú)立的等待隊(duì)列精確控制喚醒某一類線程。這一點(diǎn)在下文的生產(chǎn)者消費(fèi)者場(chǎng)景里體現(xiàn)得很明顯。2.2 標(biāo)準(zhǔn)范式鎖獲取與釋放的正確姿勢(shì)用Lock必須手動(dòng)釋放所以有個(gè)鐵律lock()要在try外調(diào)用unlock()必須在finally里。直接看代碼ReentrantLock lock new ReentrantLock(); lock.lock(); try { // 處理業(yè)務(wù)邏輯 } finally { lock.unlock(); }為什么lock()放try外面如果try里先執(zhí)行l(wèi)ock()且拋異常后面finally的unlock()會(huì)去釋放一個(gè)根本沒拿到的鎖拋IllegalMonitorStateException把原始異常也蓋掉了。所以嚴(yán)格順序是先成功拿到鎖再進(jìn)try保護(hù)臨界區(qū)最后finally釋放。養(yǎng)成這個(gè)肌肉記憶能避開一堆線上事故。2.3 Condition把wait/notify的單一等待池拆開直接放一個(gè)經(jīng)典的生產(chǎn)者消費(fèi)者實(shí)現(xiàn)用兩個(gè)Condition分別管理“隊(duì)列未滿”和“隊(duì)列非空”public class BoundedBufferE { private final Lock lock new ReentrantLock(); private final Condition notFull lock.newCondition(); private final Condition notEmpty lock.newCondition(); private final Object[] items new Object[10]; private int count; public void put(E item) throws InterruptedException { lock.lock(); try { while (count items.length) { notFull.await(); } items[count] item; notEmpty.signal(); } finally { lock.unlock(); } } public E take() throws InterruptedException { lock.lock(); try { while (count 0) { notEmpty.await(); } E item (E) items[--count]; notFull.signal(); return item; } finally { lock.unlock(); } } }注意while循環(huán)的判斷條件這是規(guī)范寫法用來防御“虛假喚醒”。wait/await被喚醒后條件未必真的滿足必須用循環(huán)重新檢查。如果把while寫成if就可能在線程被喚醒后繼續(xù)往下走取到空數(shù)據(jù)或覆蓋未讀數(shù)據(jù)。2.4 ReentrantReadWriteLock與StampedLock讀寫分離與樂觀讀ReentrantReadWriteLock把鎖分成讀鎖和寫鎖多個(gè)線程可以同時(shí)持讀鎖但寫鎖是排他的讀鎖與寫鎖互斥寫鎖與寫鎖也互斥。它適合讀多寫少的場(chǎng)景比如配置數(shù)據(jù)、熱點(diǎn)商品信息。不過它有個(gè)大坑鎖升級(jí)不被支持。一個(gè)線程先拿到讀鎖想再拿寫鎖可能直接死鎖因?yàn)榱硪粋€(gè)讀鎖線程也在做同樣的升級(jí)。反過來鎖降級(jí)是允許的即持有寫鎖時(shí)再拿讀鎖。寫鎖降級(jí)為讀鎖是為了釋放寫鎖后仍然保持讀一致性。StampedLock是JDK 8加入的更激進(jìn)方案它有三種模式寫鎖、讀鎖、樂觀讀。樂觀讀不加真正的鎖先讀數(shù)據(jù)并記一個(gè)版本號(hào)寫完再檢查版本號(hào)是否變化變了就用讀鎖兜底重新讀。這適合讀多寫少且讀操作很輕量的場(chǎng)景省掉讀鎖的加鎖開銷但需要接受偶爾的重讀。經(jīng)驗(yàn)在一次緩存框架優(yōu)化里讀寫鎖版本遇到“寫鎖頻繁等待”的問題因?yàn)樽x操作太多寫鎖總被夾在中間。換成StampedLock樂觀讀后讀路徑幾乎無鎖化吞吐明顯提升。不過樂觀讀對(duì)寫競(jìng)爭(zhēng)很敏感寫操作頻繁時(shí)反復(fù)重讀反而比讀鎖更慢所以要對(duì)場(chǎng)景做測(cè)試再上。3. 并發(fā)容器選型ConcurrentHashMap、寫時(shí)復(fù)制與阻塞隊(duì)列的適用邊界并發(fā)編程里容器選型幾乎決定了系統(tǒng)的穩(wěn)定性。很多人一上來就是“線程安全就用HashTable”可HashTable把所有方法都synchronized并發(fā)一高整個(gè)表都在互相等待。JUC里的容器解決的是“線程安全”和“并發(fā)效率”的平衡每種容器都有自己的適用邊界。3.1 ConcurrentHashMap的兩次進(jìn)化從分段鎖到CASsynchronizedJava 7的ConcurrentHashMap把數(shù)據(jù)分成16個(gè)Segment每個(gè)Segment自帶一把鎖。兩個(gè)線程操作不同Segment時(shí)可以并行但同段內(nèi)還是會(huì)串行。這種設(shè)計(jì)把鎖粒度從整張表降到了段級(jí)并發(fā)度上限就是Segment數(shù)量。Java 8干脆廢棄了Segment直接把數(shù)組的每個(gè)桶作為同步點(diǎn)插入時(shí)對(duì)桶下標(biāo)做CAS如果該位置已經(jīng)有節(jié)點(diǎn)再對(duì)這個(gè)桶的頭節(jié)點(diǎn)加synchronized。鎖粒度從一段降到了一個(gè)桶。理論上只要數(shù)據(jù)分散在不同的桶寫入就能大幅并行。這是JDK 8后ConcurrentHashMap成為并發(fā)首選的核心原因。需要特別說明的是synchronized在Java 8之后的鎖升級(jí)機(jī)制已經(jīng)非常成熟用在“單個(gè)桶”這種低競(jìng)爭(zhēng)部位反而比ReentrantLock更輕這也是JUC源碼里很多地方用synchronized做細(xì)粒度鎖的原因。3.2 弱一致性迭代器與size()的真相ConcurrentHashMap的迭代器是弱一致性的迭代過程中如果其他線程修改了map迭代器不會(huì)拋ConcurrentModificationException但新改動(dòng)也不保證能立刻看到。它對(duì)“正在被遍歷”的集合有很強(qiáng)的容錯(cuò)性很適合緩存快照、批量掃描這類場(chǎng)景。size()方法同樣不是一個(gè)精確值。為了不鎖住全表ConcurrentHashMap把計(jì)數(shù)拆成多個(gè)CounterCell不同線程的更新累加到不同Cell上size()時(shí)把這些Cell和一個(gè)base累加。累加過程不加鎖所以得到的是一個(gè)近似值。如果你需要精確計(jì)數(shù)得額外加鎖或用LongAdder配合維護(hù)一個(gè)外部計(jì)數(shù)器。很多人寫并發(fā)統(tǒng)計(jì)時(shí)直接把map.size()當(dāng)精確結(jié)果用結(jié)果越到臨界值偏差越明顯。3.3 CopyOnWriteArrayList用“寫時(shí)復(fù)制”換讀性能CopyOnWriteArrayList的思路是所有寫操作add、set、remove都先復(fù)制一份新數(shù)組在新數(shù)組上改完再用新數(shù)組替換舊數(shù)組。讀操作不加鎖直接讀當(dāng)前數(shù)組內(nèi)容。多個(gè)讀線程天然并發(fā)因?yàn)樽x的是不可變的數(shù)組對(duì)象。它的代價(jià)也直白每次寫都要復(fù)制全量數(shù)據(jù)寫頻繁時(shí)內(nèi)存浪費(fèi)巨大且讀到的是舊數(shù)據(jù)屬于最終一致性。所以它只適合讀多寫極少的場(chǎng)景典型就是監(jiān)聽器列表、配置快照。我在項(xiàng)目里用它在發(fā)布訂閱框架中保存訂閱者列表每次通知遍歷訂閱者時(shí)完全并行偶爾一個(gè)訂閱者加入才觸發(fā)一次數(shù)組復(fù)制代價(jià)很低。3.4 BlockingQueue四兄弟從有界到無界、從立即到延遲阻塞隊(duì)列把生產(chǎn)者和消費(fèi)者解耦是線程協(xié)作的最佳拍檔。常用實(shí)現(xiàn)各有側(cè)重隊(duì)列結(jié)構(gòu)邊界特點(diǎn)典型場(chǎng)景ArrayBlockingQueue數(shù)組有界容量固定公平鎖可選線程池工作隊(duì)列、有界緩沖LinkedBlockingQueue鏈表可選默認(rèn)無界吞吐高無界任務(wù)隊(duì)列SynchronousQueue無存儲(chǔ)有界0生產(chǎn)消費(fèi)必須直接交接直接提交任務(wù)給線程PriorityBlockingQueue堆無界按優(yōu)先級(jí)出隊(duì)優(yōu)先級(jí)任務(wù)調(diào)度DelayQueue堆無界延遲時(shí)間到了才能出隊(duì)定時(shí)任務(wù)、超時(shí)處理選型最核心的考量是背壓。生產(chǎn)速度遠(yuǎn)大于消費(fèi)速度時(shí)無界隊(duì)列會(huì)讓任務(wù)在內(nèi)存里無限積壓最后OOM有界隊(duì)列配合飽和策略才能讓整個(gè)系統(tǒng)在超負(fù)荷時(shí)能“減速”而不是“爆掉”。線程池使用場(chǎng)景里L(fēng)inkedBlockingQueue默認(rèn)無界容易埋雷所以工程上更推薦有界的ArrayBlockingQueue或直接傳一個(gè)自定義容量的LinkedBlockingQueue。注意SynchronousQueue不存儲(chǔ)任何元素生產(chǎn)者put時(shí)必須等消費(fèi)者take。用它做線程池隊(duì)列時(shí)意味著任務(wù)不會(huì)被排隊(duì)直接嘗試創(chuàng)建新線程執(zhí)行這對(duì)線程數(shù)控制是很大的風(fēng)險(xiǎn)別在不了解時(shí)隨手用。4. CAS與原子類無鎖方案背后的底層博弈并發(fā)編程有個(gè)反復(fù)出現(xiàn)的矛盾要保證原子性就必須加鎖加鎖就存在線程切換開銷。CAS提供了一條“不加鎖也能保證原子更新”的路代價(jià)是需要調(diào)用方自己去處理競(jìng)爭(zhēng)失敗。Java并發(fā)包里所有無鎖方案底層都依賴CAS。4.1 CAS三步指令比較、交換、循環(huán)CAS的完整操作是讀取內(nèi)存值V給定期待值E和新值N只有當(dāng)V和E相等時(shí)才把V改為N。整個(gè)比較和替換是一條CPU原子指令不會(huì)被打斷。可以想象成“先核對(duì)賬單金額確認(rèn)沒被別人改過才寫入新金額”。Java里體現(xiàn)最典型的是AtomicInteger。它的incrementAndGet不是簡(jiǎn)單加一而是do-while循環(huán)里反復(fù)嘗試CASAtomicInteger count new AtomicInteger(0); public int addOne() { int prev; do { prev count.get(); } while (!count.compareAndSet(prev, prev 1)); return prev 1; }如果兩個(gè)線程同時(shí)讀到prev5只有一個(gè)線程能CAS成功變成6另一個(gè)會(huì)重新讀舊值、重新嘗試。這就是“自旋”。自旋在低競(jìng)爭(zhēng)時(shí)非?？煲?yàn)椴恍枰袚Q線程但高競(jìng)爭(zhēng)下大量線程都在同一個(gè)內(nèi)存地址上自旋CPU白白空轉(zhuǎn)性能反而不如鎖。4.2 ABA問題數(shù)值沒變不代表狀態(tài)沒變CAS判斷“值相等”就認(rèn)為沒人改動(dòng)過但這個(gè)假設(shè)有漏洞。線程1讀到值A(chǔ)線程2把A改成B又改成A線程1再次CAS時(shí)發(fā)現(xiàn)還是A認(rèn)為過程沒被打擾實(shí)際上數(shù)據(jù)中間被改過。這叫ABA問題。ABA在純數(shù)值統(tǒng)計(jì)里往往無所謂但在鏈表、棧這類結(jié)構(gòu)上可能致命。比如棧頂節(jié)點(diǎn)被回收后重新入棧地址一樣但內(nèi)容已經(jīng)變了用CAS更新棧頂就可能覆蓋掉其他操作。解決辦法是給每個(gè)版本加編號(hào)每次修改編號(hào)1。JUC里的AtomicStampedReference就是干這個(gè)的它同時(shí)維護(hù)對(duì)象引用和整數(shù)stamp。4.3 AtomicInteger與LongAdder從單點(diǎn)計(jì)數(shù)到分段計(jì)數(shù)AtomicLong在高并發(fā)寫同一變量時(shí)所有線程搶同一個(gè)內(nèi)存地址CAS沖突概率隨線程數(shù)上升自旋空轉(zhuǎn)成本隨之增加。LongAdder換了個(gè)思路內(nèi)部維護(hù)一個(gè)base值和一個(gè)Cell數(shù)組。不同線程通過hash分散到不同Cell上各自累加最后sum()時(shí)把所有Cell和base加總。這就是“分段計(jì)數(shù)”把單點(diǎn)競(jìng)爭(zhēng)拆成多點(diǎn)并行?？雌饋鞮ongAdder很完美但它有一個(gè)特點(diǎn)sum()返回的是累加值不是嚴(yán)格實(shí)時(shí)的一致快照而且單個(gè)Cell的更新精度在極端情況下可能稍弱。用在統(tǒng)計(jì)請(qǐng)求數(shù)、PV次數(shù)這類場(chǎng)景非常合適但如果你需要強(qiáng)一致的自增結(jié)果來做判斷還是要用AtomicInteger。簡(jiǎn)單說統(tǒng)計(jì)用LongAdder判斷用Atomic。經(jīng)驗(yàn)有一個(gè)在線請(qǐng)求計(jì)數(shù)模塊最初用AtomicLong壓測(cè)時(shí)發(fā)現(xiàn)線程數(shù)超過32后吞吐不再上升大量CPU時(shí)間耗在CAS自旋。換LongAdder后同一臺(tái)機(jī)器吞吐直接翻倍。后來總結(jié)高并發(fā)熱點(diǎn)計(jì)數(shù)LongAdder是默認(rèn)優(yōu)先方案只有需要讀回精確值時(shí)才回到原子變量。4.4 別在業(yè)務(wù)代碼里直接用Unsafe原子類底層基于Unsafe的compareAndSwapInt等本地方法實(shí)現(xiàn)但Unsafe不是給業(yè)務(wù)開發(fā)者用的。它允許繞過Java內(nèi)存管理直接操作內(nèi)存一旦偏移量算錯(cuò)輕則數(shù)據(jù)錯(cuò)亂重則JVM崩潰。而且它不屬于標(biāo)準(zhǔn)API不同JDK版本內(nèi)部的實(shí)現(xiàn)細(xì)節(jié)一直在變。如果確實(shí)需要自定義CAS操作優(yōu)先找Java標(biāo)準(zhǔn)庫提供的現(xiàn)成類組合實(shí)在不夠用可以考慮JDK 9之后的VarHandle它提供了類型安全的引用和字段原子操作比Unsafe安全得多也更規(guī)范。我見過有人把Unsafe寫進(jìn)業(yè)務(wù)代碼代碼Review時(shí)每個(gè)人都看不懂最后只能回退到原子類加鎖方案維護(hù)成本太高。5. 線程池的實(shí)際打開方式七個(gè)參數(shù)、工廠方法陷阱與自定義策略線程池是并發(fā)開發(fā)里最常用的組件卻也是被誤解最多的組件。很多人直接調(diào)用Executors工廠方法對(duì)底層參數(shù)一無所知直到線上OOM才回頭研究。這一節(jié)就按實(shí)際鏈路拆一遍。5.1 七個(gè)參數(shù)提交任務(wù)后到底發(fā)生了什么ThreadPoolExecutor的完整構(gòu)造函數(shù)有七個(gè)參數(shù)核心線程數(shù)corePoolSize、最大線程數(shù)maximumPoolSize、空閑存活時(shí)間keepAliveTime、時(shí)間單位unit、工作隊(duì)列workQueue、線程工廠threadFactory、拒絕策略handler。當(dāng)一個(gè)新的任務(wù)通過execute提交進(jìn)來執(zhí)行流程非常固定當(dāng)前線程數(shù)小于corePoolSize直接創(chuàng)建核心線程執(zhí)行任務(wù)當(dāng)前線程數(shù)大于等于corePoolSize任務(wù)先丟進(jìn)工作隊(duì)列隊(duì)列已滿且當(dāng)前線程數(shù)小于maximumPoolSize創(chuàng)建救急線程執(zhí)行任務(wù)隊(duì)列已滿線程數(shù)也已達(dá)最大觸發(fā)拒絕策略很多人不理解第2步為什么是先排隊(duì)而不是先加線程。這是線程池對(duì)資源開銷的一種“背壓”設(shè)計(jì)核心線程還沒忙完新任務(wù)先排隊(duì)等待避免無限創(chuàng)建線程打爆系統(tǒng)。只有隊(duì)列真正滿時(shí)才認(rèn)為“確實(shí)忙不過來了”開始擴(kuò)張到最大線程數(shù)。理解了這套順序你就知道調(diào)優(yōu)線程池時(shí)為什么隊(duì)列容量和maximumPoolSize必須一起考慮。5.2 execute與submit、優(yōu)雅停機(jī)的細(xì)節(jié)execute提交Runnable沒有返回值submit提交Callable時(shí)可以拿到Future。這里有個(gè)容易翻車的點(diǎn)submit返回的Future如果不用get讀取任務(wù)內(nèi)部拋出的異常會(huì)被吞進(jìn)Future不會(huì)打印日志你以為任務(wù)執(zhí)行成功了實(shí)際什么都沒發(fā)生。所以用submit時(shí)要么在get處捕獲ExecutionException要么在任務(wù)內(nèi)部自己try-catch留痕。停機(jī)方法上shutdown是優(yōu)雅關(guān)閉拒絕新任務(wù)但已經(jīng)提交的任務(wù)繼續(xù)執(zhí)行shutdownNow是強(qiáng)制關(guān)閉嘗試中斷正在執(zhí)行的任務(wù)并返回隊(duì)列里還沒執(zhí)行的任務(wù)列表。生產(chǎn)環(huán)境做優(yōu)雅停機(jī)我習(xí)慣shutdown之后加awaitTermination等待一段窗口期確認(rèn)任務(wù)都收尾了再釋放資源。如果直接shutdownNow正在寫數(shù)據(jù)庫的事務(wù)可能被攔腰截?cái)唷?.3 Executors工廠方法為什么被詬病JDK自帶了一堆線程池工廠方法看起來很方便實(shí)際埋著大坑newFixedThreadPool工作隊(duì)列是默認(rèn)無界的LinkedBlockingQueue任務(wù)積壓時(shí)隊(duì)列無限變長內(nèi)存遲早被撐爆newCachedThreadPool最大線程數(shù)是Integer.MAX_VALUE請(qǐng)求一多線程數(shù)會(huì)跟著請(qǐng)求量瘋狂上漲系統(tǒng)可能被巨量線程拖垮newSingleThreadExecutor同樣使用無界隊(duì)列單個(gè)線程慢慢消費(fèi)積壓?jiǎn)栴}被隱藏得更深工廠方法不是不能用于學(xué)習(xí)Demo而是它把線程池最關(guān)鍵的決策全部交給了默認(rèn)值你在生產(chǎn)上無法限制隊(duì)列也無法感知超負(fù)荷。現(xiàn)在很多團(tuán)隊(duì)的代碼規(guī)范里直接禁止使用這些工廠方法要求手動(dòng)new ThreadPoolExecutor把參數(shù)顯式寫出來。不是為了顯擺規(guī)范而是為了出事時(shí)你能看得懂自己的線程池。5.4 自定義線程池的工程習(xí)慣給一個(gè)實(shí)際可用的自定義線程池模板ThreadPoolExecutor executor new ThreadPoolExecutor( 8, // 核心線程數(shù) 16, // 最大線程數(shù) 60L, TimeUnit.SECONDS, // 救急線程空閑60秒回收 new ArrayBlockingQueue(100), // 有界隊(duì)列防止OOM r - { Thread t new Thread(r); t.setName(order-worker- t.getId()); return t; }, new ThreadPoolExecutor.CallerRunsPolicy() );ThreadFactory里給線程命名是必須養(yǎng)成的習(xí)慣。以后線上出問題在jstack里一眼就能分辨哪些線程屬于哪個(gè)業(yè)務(wù)線程池而不是一堆“pool-1-thread-1”。否則你連排查的抓手都沒有。隊(duì)列容量和最大線程數(shù)的組合沒有萬能公式。我的經(jīng)驗(yàn)是先按任務(wù)特性給初值CPU密集型任務(wù)核心線程數(shù)約等于CPU核數(shù)加一IO密集型任務(wù)通常需要更多線程等待網(wǎng)絡(luò)和磁盤。但最終數(shù)值一定要靠壓測(cè)去調(diào)看隊(duì)列積壓趨勢(shì)、線程空閑情況、拒絕策略觸發(fā)次數(shù)。5.5 拒絕策略四選一與鉤子方法拒絕策略有四種取舍很清晰策略行為適用場(chǎng)景AbortPolicy直接拋RejectedExecutionException明確超負(fù)荷必須告警CallerRunsPolicy提交任務(wù)的線程自己執(zhí)行該任務(wù)制造反向背壓放慢提交速度DiscardPolicy靜默丟棄新任務(wù)不推薦丟任務(wù)無感知DiscardOldestPolicy丟棄隊(duì)列里最老的任務(wù)再提交新任務(wù)允許犧牲舊任務(wù)保證新任務(wù)線上最常用CallerRunsPolicy因?yàn)楫?dāng)線程池滿時(shí)由提交任務(wù)的線程自己來跑相當(dāng)于把壓力反向傳回業(yè)務(wù)方提交速度自然下降系統(tǒng)進(jìn)入自我保護(hù)。但要注意提交線程可能因此長時(shí)間阻塞調(diào)用接口的響應(yīng)時(shí)間會(huì)上升必須讓上游有超時(shí)兜底。ThreadPoolExecutor還預(yù)留了beforeExecute、afterExecute和terminated三個(gè)鉤子方法子類覆蓋它們就可以在任務(wù)執(zhí)行前后統(tǒng)一埋點(diǎn)。我們?cè)赼fterExecute里統(tǒng)一記錄每個(gè)任務(wù)耗時(shí)慢任務(wù)TopN一眼可見比在業(yè)務(wù)代碼里到處加stopwatch干凈得多。6. CountDownLatch、CyclicBarrier、Semaphore三個(gè)工具類各自的邊界這三個(gè)工具類經(jīng)常被放在一起比但它們的語義完全不同。簡(jiǎn)單記有人等你完成你等大家一起限制最多幾個(gè)人同時(shí)干活。搞清楚自己是哪個(gè)角色才能選對(duì)工具。6.1 CountDownLatch一次性的任務(wù)完成倒計(jì)時(shí)CountDownLatch的模型是一個(gè)計(jì)數(shù)器。初始化時(shí)設(shè)定N線程每完成一個(gè)任務(wù)就調(diào)用countDown()減一等待方調(diào)用await()阻塞直到計(jì)數(shù)歸零。非常適合“多個(gè)子任務(wù)完成后主線程匯總”的聚合場(chǎng)景。CountDownLatch latch new CountDownLatch(5); for (int i 0; i 5; i) { executor.submit(() - { try { // 調(diào)用下游接口、查詢數(shù)據(jù) } finally { latch.countDown(); } }); } latch.await(10, TimeUnit.SECONDS);兩個(gè)要點(diǎn)countDown必須放在finally里否則子任務(wù)拋異常時(shí)計(jì)數(shù)不減主線程會(huì)一直等下去await要帶超時(shí)時(shí)間避免某個(gè)子任務(wù)卡死導(dǎo)致整個(gè)應(yīng)用無響應(yīng)。CountDownLatch是一次性的用完之后計(jì)數(shù)歸零就廢了想再等下一批任務(wù)只能重新new一個(gè)。6.2 CyclicBarrier可循環(huán)的相互等待屏障CyclicBarrier和CountDownLatch表面相似內(nèi)里不同。CountDownLatch是“主線程等子線程完成”CyclicBarrier是“N個(gè)線程到達(dá)屏障后一起放行”它是線程等線程沒有固定的主從關(guān)系。而且它能循環(huán)使用一輪放行后重置繼續(xù)等下一輪。還有一個(gè)加分項(xiàng)CyclicBarrier可以傳一個(gè)barrierAction在所有線程到達(dá)屏障時(shí)由最后一個(gè)到達(dá)的線程觸發(fā)一次額外動(dòng)作。比如分頁批量處理數(shù)據(jù)每頁數(shù)據(jù)被多個(gè)線程處理完后先執(zhí)行一次匯總統(tǒng)計(jì)再進(jìn)入下一頁。CyclicBarrier的坑在于“屏障破碎”如果某個(gè)線程在等待時(shí)被中斷、超時(shí)或異常退出會(huì)拋BrokenBarrierException屏障進(jìn)入broken狀態(tài)其他所有還在等待的線程也會(huì)跟著異常退出。如果你要做復(fù)雜階段的并行處理必須捕獲BrokenBarrierException并調(diào)用reset()重新建立屏障不能坐視整個(gè)流程卡死。6.3 Semaphore控制并發(fā)數(shù)量的許可信號(hào)Semaphore維護(hù)N個(gè)許可線程acquire()拿到一個(gè)許可就繼續(xù)執(zhí)行release()歸還許可。它控制的核心指標(biāo)是并發(fā)數(shù)不是速率。想限制某個(gè)接口同時(shí)最多允許10個(gè)請(qǐng)求進(jìn)來用它最直接想限制每秒最多請(qǐng)求數(shù)那是RateLimiter的活兩者概念別混。Semaphore semaphore new Semaphore(10, true); public void handleRequest() { try { semaphore.acquire(); // 只有10個(gè)線程能同時(shí)進(jìn)入 } catch (InterruptedException e) { Thread.currentThread().interrupt(); } finally { semaphore.release(); } }acquire和release必須嚴(yán)格配對(duì)release必須放finally。這個(gè)工具最容易踩的坑線程拿到許可后拋異常忘了釋放許可數(shù)量越來越少最終業(yè)務(wù)方全部阻塞在acquire上。還有一點(diǎn)默認(rèn)Semaphore是非公平的但構(gòu)造方法可以傳fair參數(shù)需要排隊(duì)有序時(shí)選公平版本否則新來的線程可能一直插隊(duì)。6.4 三個(gè)工具的選型速判給一張速查表遇到并發(fā)協(xié)作場(chǎng)景可以對(duì)照著選工具核心語義能否復(fù)用典型場(chǎng)景CountDownLatch等待N個(gè)事件完成否并發(fā)結(jié)果聚合、批量任務(wù)結(jié)束后匯總CyclicBarrierN個(gè)線程互相等待齊是多線程分階段同步、每輪匯總Semaphore限制同時(shí)執(zhí)行的線程數(shù)是接口并發(fā)限制、連接池、外部資源限流選型思路我一般是這樣如果你是“被等待的人”用CountDownLatch如果你必須等齊其他同事再開工用CyclicBarrier如果只想限制“全公司同時(shí)只能有幾個(gè)人進(jìn)機(jī)房”用Semaphore。把問題轉(zhuǎn)化成角色關(guān)系工具自己就浮出來了。寫在最后的一點(diǎn)學(xué)習(xí)心得我自己把JUC串起來的路徑是CAS和volatile打底然后啃AQS的state和隊(duì)列設(shè)計(jì)再看Lock、Semaphore、CountDownLatch如何復(fù)用AQS最后才是并發(fā)容器和線程池的參數(shù)細(xì)節(jié)。這套順序最大的好處是每學(xué)一個(gè)新組件都不是從零背API而是給已有的知識(shí)框架掛一個(gè)分支。還有一個(gè)小心得分享給正在入門的人寫并發(fā)代碼前先問自己三個(gè)問題——這里需要互斥訪問共享數(shù)據(jù)嗎需要多個(gè)線程協(xié)作完成一件事嗎需要限制并發(fā)數(shù)量嗎問題一旦定性最合適的工具往往只有一個(gè)而不是靠排列組合。最后再強(qiáng)調(diào)一次那個(gè)肌肉記憶鎖的獲取寫在try之前釋放寫在finally里養(yǎng)成它能少處理很多線上告警。