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