戰(zhàn)：從四個(gè)必要條件到j(luò)stack排查與工程化預(yù)防)
上周又有人在群里發(fā)了一張線程轉(zhuǎn)儲(chǔ)截圖問(wèn)“線程狀態(tài)全是WAITING服務(wù)也不報(bào)錯(cuò)業(yè)務(wù)就是不動(dòng)是不是死鎖”我一看那圖上兩條線程互等對(duì)方釋放鎖就知道又是老場(chǎng)面了。多線程死鎖這東西面試題里年年考理論背得滾瓜爛熟可真到線上出問(wèn)題時(shí)能一眼認(rèn)出來(lái)并快速處理的人其實(shí)不多。這篇文章就圍繞多線程死鎖展開(kāi)先說(shuō)清楚它的本質(zhì)和四個(gè)必要條件然后用一個(gè)賬戶轉(zhuǎn)賬的真實(shí)案例一步步復(fù)現(xiàn)死鎖現(xiàn)場(chǎng)再講線上排查的完整鏈路jstack、JConsole、數(shù)據(jù)庫(kù)鎖日志這些工具怎么配合用最后給出修復(fù)方案和工程化的預(yù)防手段。適合正在學(xué)并發(fā)編程的初學(xué)者也適合寫(xiě)過(guò)多線程代碼、但還沒(méi)被死鎖“教育”過(guò)的開(kāi)發(fā)者。1. 死鎖是并發(fā)編程里最安靜的故障1.1 線上死鎖長(zhǎng)什么樣死鎖在線上有個(gè)很坑的特點(diǎn)它不會(huì)讓進(jìn)程崩潰不會(huì)拋出異常不會(huì)像OOM那樣直接留下日志。你只會(huì)發(fā)現(xiàn)某個(gè)接口突然超時(shí)然后超時(shí)的請(qǐng)求越來(lái)越多緊接著線程池被占滿健康檢查開(kāi)始失敗最后整臺(tái)機(jī)器被流量調(diào)度系統(tǒng)摘掉。我見(jiàn)過(guò)最典型的案例是這樣的一個(gè)支付回調(diào)服務(wù)白天業(yè)務(wù)量平穩(wěn)還好一到晚上賬務(wù)批處理任務(wù)跑起來(lái)就會(huì)有幾個(gè)交易卡住。重啟服務(wù)就好了但過(guò)了幾個(gè)小時(shí)又出現(xiàn)。剛開(kāi)始大家以為是數(shù)據(jù)庫(kù)慢查詢后來(lái)抓線程棧才看見(jiàn)賬務(wù)批處理線程持有一把鎖在處理回調(diào)的線程等待而回調(diào)線程也持有一把鎖批處理線程正在等它。兩邊誰(shuí)也不讓誰(shuí)業(yè)務(wù)就停了下來(lái)。這類問(wèn)題的可怕之處在于它在測(cè)試環(huán)境很難復(fù)現(xiàn)。單元測(cè)試?yán)飪蓚€(gè)線程按順序跑根本不會(huì)出現(xiàn)競(jìng)態(tài)即使偶發(fā)一次重啟就好報(bào)錯(cuò)日志為零很容易被當(dāng)成“偶發(fā)網(wǎng)絡(luò)抖動(dòng)”略過(guò)。1.2 死鎖和普通性能問(wèn)題有什么不同普通性能問(wèn)題比如慢SQL、Full GC、CPU飆高通常都有明顯的“癥狀指標(biāo)”要么響應(yīng)時(shí)間上去要么CPU利用率異常要么內(nèi)存曲線陡增。而死鎖的癥狀非常隱蔽CPU利用率可能很低內(nèi)存也正常線程池里的線程卻全部卡在BLOCKED或WAITING狀態(tài)活活把一個(gè)可以3秒內(nèi)完成的請(qǐng)求拖到超時(shí)。用個(gè)生活類比死鎖就像是兩輛車在窄橋上迎面相遇彼此都占著自己這邊的車道同時(shí)堅(jiān)持讓對(duì)方讓路。沒(méi)有一輛車壞掉也沒(méi)有人違規(guī)可交通就是永遠(yuǎn)癱瘓了。排查這類問(wèn)題不能靠看CPU和日志必須直接看線程在等什么。我平時(shí)排查的第一步永遠(yuǎn)是找到那些長(zhǎng)期處于BLOCKED或WAITING狀態(tài)的線程打印它們的堆棧看它們分別持有什么鎖、正在請(qǐng)求什么鎖。只要看到一條“A持有X等YB持有Y等X”的循環(huán)鏈基本就可以鎖定死鎖。2. 四個(gè)必要條件差一個(gè)都鎖不死想理解死鎖為什么發(fā)生先要記住一個(gè)經(jīng)典結(jié)論死鎖發(fā)生產(chǎn)生的核心原因可以歸納為四個(gè)條件它們必須同時(shí)滿足缺一不可。這也是為什么所有修復(fù)方案本質(zhì)都是在“破壞其中一個(gè)條件”。2.1 互斥沒(méi)法改的前提第一個(gè)條件是互斥同一時(shí)刻一個(gè)共享資源只能被一個(gè)線程占用。鎖的語(yǔ)義天然就是互斥的讀寫(xiě)鎖里寫(xiě)鎖是互斥的數(shù)據(jù)庫(kù)的行鎖也是互斥的分布式鎖更是專門(mén)做互斥的。這個(gè)條件在絕大多數(shù)場(chǎng)景下不能也無(wú)需被破壞。我們加鎖的目的正是為了保證互斥訪問(wèn)如果去掉互斥那并發(fā)安全就無(wú)從談起。所以修復(fù)死鎖時(shí)不要去動(dòng)這個(gè)條件。2.2 持有并等待嵌套加鎖的元兇第二個(gè)條件叫持有并等待線程已經(jīng)持有一把鎖同時(shí)還想去獲取另一把鎖在等待第二把鎖的過(guò)程中它不釋放第一把鎖。這是我自己寫(xiě)代碼時(shí)最常踩的坑。比如一個(gè)賬戶轉(zhuǎn)賬功能轉(zhuǎn)賬操作需要同時(shí)鎖定轉(zhuǎn)出賬戶和轉(zhuǎn)入賬戶防止余額被并發(fā)修改。如果先鎖from賬戶再去鎖to賬戶而另一個(gè)線程正好反過(guò)來(lái)先鎖了to賬戶再去鎖from賬戶持有并等待的條件就成立了。記住一句話每出現(xiàn)一次“持有一把鎖再去拿另一把鎖”就是往死鎖的方向邁了一步。不是每次都會(huì)死鎖但一旦時(shí)機(jī)配合死鎖就是必然。2.3 不可剝奪鎖釋放點(diǎn)決定了死局第三個(gè)條件是不可剝奪線程已經(jīng)獲得的鎖在自己主動(dòng)釋放之前不能被其他線程強(qiáng)行奪走。Java的synchronized和ReentrantLock在默認(rèn)語(yǔ)義下都是不可剝奪的synchronized連中斷都不響應(yīng)ReentrantLock還得靠lockInterruptibly才能響應(yīng)中斷。數(shù)據(jù)庫(kù)的行鎖也是這樣事務(wù)沒(méi)提交之前其他事務(wù)只能等著。這個(gè)條件告訴我們鎖的釋放時(shí)機(jī)完全掌握在持有者手里。如果持有者因?yàn)榫W(wǎng)絡(luò)、等待、外部調(diào)用阻塞住了那所有等待這把鎖的線程都會(huì)被拖下水。2.4 循環(huán)等待最后一個(gè)條件第四個(gè)條件是循環(huán)等待存在一組線程它們互相等待對(duì)方持有的資源形成一個(gè)首尾相接的等待環(huán)。比如線程A持有鎖1等待鎖2線程B持有鎖2等待鎖1這就是最簡(jiǎn)單的兩節(jié)點(diǎn)環(huán)。3. 用賬戶轉(zhuǎn)賬復(fù)現(xiàn)一次標(biāo)準(zhǔn)的死鎖過(guò)程3.1 從業(yè)務(wù)邏輯到代碼模型理論講多了容易飄直接看一段能跑的死鎖代碼。假設(shè)有個(gè)最簡(jiǎn)單的銀行賬戶系統(tǒng)Account類維護(hù)余額和一把自己的鎖class Account { private final int id; private int balance; private final ReentrantLock lock new ReentrantLock(); public Account(int id, int balance) { this.id id; this.balance balance; } public void deposit(int amount) { balance amount; } public void withdraw(int amount) { balance - amount; } public void lock() { lock.lock(); } public void unlock() { lock.unlock(); } }轉(zhuǎn)賬方法天然需要鎖定兩個(gè)賬戶防止轉(zhuǎn)賬過(guò)程中余額被并發(fā)修改static void transfer(Account from, Account to, int amount) { from.lock(); try { to.lock(); try { from.withdraw(amount); to.deposit(amount); } finally { to.unlock(); } } finally { from.unlock(); } }這段代碼從功能上完全“正確”既不丟錢也不重復(fù)扣錢可它隱含了一個(gè)致命問(wèn)題鎖的順序不一致。只要調(diào)用方向相反就會(huì)埋下死鎖的種子。3.2 完整復(fù)現(xiàn)代碼與運(yùn)行結(jié)果下面用兩個(gè)線程讓死鎖必然發(fā)生。設(shè)想賬戶A余額1000賬戶B余額1000。線程1執(zhí)行“從A轉(zhuǎn)100到B”線程2同時(shí)執(zhí)行“從B轉(zhuǎn)200到A”public class DeadlockDemo { public static void main(String[] args) throws Exception { Account a new Account(1, 1000); Account b new Account(2, 1000); Thread t1 new Thread(() - transfer(a, b, 100), T1); Thread t2 new Thread(() - transfer(b, a, 200), T2); t1.start(); t2.start(); t1.join(); t2.join(); System.out.println(transfer done); } }如果運(yùn)氣好跑一兩次可能不會(huì)死鎖因?yàn)榫€程啟動(dòng)順序和調(diào)度時(shí)機(jī)決定了是否真的形成交叉等待。為了穩(wěn)定復(fù)現(xiàn)可以在線程1鎖定from之后加一個(gè)小小的停頓讓兩個(gè)線程能卡在對(duì)方節(jié)點(diǎn)上Thread t1 new Thread(() - { a.lock(); try { Thread.sleep(100); b.lock(); try { a.withdraw(100); b.deposit(100); } finally { b.unlock(); } } catch (InterruptedException e) { Thread.currentThread().interrupt(); } finally { a.unlock(); } }, T1);這樣跑程序大概率會(huì)直接卡住永遠(yuǎn)打印不出“transfer done”。兩個(gè)線程都持有一把鎖同時(shí)等待對(duì)方的那把鎖恰好滿足前面說(shuō)的全部四個(gè)條件。3.3 數(shù)據(jù)庫(kù)行鎖同樣會(huì)死鎖眼光放大一點(diǎn)多線程死鎖不止發(fā)生在Java內(nèi)存鎖上數(shù)據(jù)庫(kù)表里同樣有死鎖。兩個(gè)事務(wù)同時(shí)更新兩條記錄但更新順序相反就會(huì)觸發(fā)數(shù)據(jù)庫(kù)行鎖死鎖。比如事務(wù)A先更新user_id1的行再更新user_id2的行事務(wù)B先更新user_id2的行再更新user_id1的行。由于行鎖互斥兩個(gè)事務(wù)互相等待對(duì)方提交數(shù)據(jù)庫(kù)死鎖檢測(cè)器介入后會(huì)回滾其中一個(gè)事務(wù)讓另一個(gè)繼續(xù)執(zhí)行。這給業(yè)務(wù)代碼的啟示是即使服務(wù)端沒(méi)有任何鎖只要SQL事務(wù)里涉及多條記錄的更新就存在數(shù)據(jù)庫(kù)層面的行鎖死鎖風(fēng)險(xiǎn)。修復(fù)思路其實(shí)一樣讓事務(wù)內(nèi)的多條SQL語(yǔ)句總是按同一順序更新數(shù)據(jù)即可。4. 線上排查死鎖的三板斧與完整鏈路4.1 先確認(rèn)“卡住”是不是死鎖線上遇到接口超時(shí)、線程池耗盡第一步不是找死鎖而是先確認(rèn)現(xiàn)象?？淳€程是不是大面積長(zhǎng)時(shí)間處于BLOCKED或WAITING狀態(tài)以及有沒(méi)有一條清晰的等待鏈。常見(jiàn)誤區(qū)是只要看到WAITING就覺(jué)得是死鎖。實(shí)際上線程在Object.wait()或LockSupport.park()的時(shí)候也是WAITING狀態(tài)很多是正常的等待喚醒機(jī)制。只有“等待的鎖正被另一個(gè)線程持有而那個(gè)線程也在等鎖”才是死鎖。所以排查一定要拿線程棧逐線程分析不能光看狀態(tài)名。4.2 jstack找Java級(jí)死鎖jstack是排查Java死鎖最趁手的工具用法很簡(jiǎn)單jstack pid thread_dump.txt如果JVM檢測(cè)到Java級(jí)別的死鎖會(huì)在線程棧頂部明確輸出“Found one Java-level deadlock”字樣并列出死鎖線程的等待關(guān)系格式大致如下Found one Java-level deadlock: T2: waiting to lock monitor 0x00007f (object 0x0000000012345678, a Account), which is held by T1 T1: waiting to lock monitor 0x00007f (object 0x00000000abcdef01, a Account), which is held by T2 Java stack information for the threads listed above: ...看到這個(gè)頭問(wèn)題就基本定性了。建議連續(xù)抓兩三次線程棧間隔幾秒確認(rèn)等待鏈穩(wěn)定存在避免抓到半路正在釋放鎖的瞬時(shí)狀態(tài)。不過(guò)要注意一點(diǎn)jstack能自動(dòng)檢測(cè)的是synchronized和ReentrantLock等Java管程對(duì)象上的死鎖。如果死鎖發(fā)生在AQS內(nèi)部的顯式條件隊(duì)列之間或者鎖是通過(guò)Unsafe這類底層機(jī)制實(shí)現(xiàn)的jstack不一定能自動(dòng)給出“Found deadlock”的結(jié)論這時(shí)候就要手動(dòng)解析線程棧里的“waiting to lock”和“l(fā)ocked”信息。4.3 JConsole與ThreadMXBean兜底生產(chǎn)環(huán)境如果不好執(zhí)行命令行可以用JConsole連上進(jìn)程在線程頁(yè)簽里看線程狀態(tài)和堆棧界面很直觀雙擊任何一條線程就能看到它的調(diào)用棧和鎖持有情況。如果想把死鎖檢測(cè)做成自動(dòng)化Java標(biāo)準(zhǔn)庫(kù)提供了ThreadMXBeanThreadMXBean tmb ManagementFactory.getThreadMXBean(); long[] deadlockedIds tmb.findDeadlockedThreads(); if (deadlockedIds ! null) { for (long id : deadlockedIds) { ThreadInfo info tmb.getThreadInfo(id); System.out.println(deadlocked thread: info.getThreadName()); } }注意兩個(gè)方法的區(qū)別findDeadlockedThreads能檢測(cè)到包括java.util.concurrent鎖在內(nèi)的死鎖findMonitorDeadlockedThreads只能檢測(cè)到monitor鎖也就是synchronized相關(guān)的死鎖。建議用前者。在自動(dòng)化回歸測(cè)試?yán)锟梢栽谒胁l(fā)用例跑完后調(diào)用一次findDeadlockedThreads一旦返回非空就直接讓測(cè)試失敗。這是成本最低的死鎖防線比靠人工review代碼靠譜得多。4.4 數(shù)據(jù)庫(kù)死鎖的排查路徑數(shù)據(jù)庫(kù)死鎖的排查鏈路不同重點(diǎn)看兩個(gè)地方一是數(shù)據(jù)庫(kù)自己的死鎖日志MySQL 5.7以上默認(rèn)開(kāi)啟innodb_print_all_deadlocks時(shí)可以打印到錯(cuò)誤日志或者用SHOW ENGINE INNODB STATUS查看最近一次死鎖的事務(wù)詳情二是應(yīng)用日志里是否出現(xiàn)錯(cuò)誤碼1213(MySQL死鎖)或類似“Deadlock found”的報(bào)錯(cuò)。拿到數(shù)據(jù)庫(kù)死鎖日志后重點(diǎn)看“WAITING FOR THIS LOCK TO BE GRANTED”和“HOLDS THE LOCK”這兩段就能還原出兩個(gè)事務(wù)分別持有哪一行鎖、等待哪一行鎖。修復(fù)手段通常是讓事務(wù)內(nèi)的SQL執(zhí)行順序統(tǒng)一或者在業(yè)務(wù)層面上按某個(gè)唯一鍵排序后再執(zhí)行批量更新。5. 修復(fù)死鎖的幾種思路以及它們的代價(jià)5.1 全局排序用規(guī)則破壞循環(huán)等待最經(jīng)典的修復(fù)死鎖方案就是打破循環(huán)等待這個(gè)條件給所有需要加鎖的資源定義一個(gè)全局順序所有線程一律按照這個(gè)順序加鎖不允許跳過(guò)或倒序。賬戶轉(zhuǎn)賬的例子可以改成按賬戶ID排序后加鎖static void transfer(Account from, Account to, int amount) { Account first from.id to.id ? from : to; Account second from.id to.id ? to : from; first.lock(); try { second.lock(); try { from.withdraw(amount); to.deposit(amount); } finally { second.unlock(); } } finally { first.unlock(); } }這樣無(wú)論外部傳入的轉(zhuǎn)賬方向如何內(nèi)部都是先鎖ID小的賬戶、再鎖ID大的賬戶。兩個(gè)線程不可能出現(xiàn)“你等我我等你”的環(huán)形等待。這個(gè)方案看起來(lái)簡(jiǎn)單實(shí)際落地有幾個(gè)坑。最典型的是如果資源本身沒(méi)有天然的ID順序比如一組對(duì)象池里的連接對(duì)象可以退一步用System.identityHashCode排序但哈希值可能會(huì)沖突沖突時(shí)要再準(zhǔn)備一個(gè)“打破平局”的鎖或比較規(guī)則否則排序就失效了。我一般會(huì)直接在業(yè)務(wù)對(duì)象里加一個(gè)自增ID盡量不依賴哈希。5.2 有界等待用超時(shí)打破僵局如果說(shuō)全局排序是“從設(shè)計(jì)上讓死鎖不可能發(fā)生”那有界等待就是在“賭死鎖就算發(fā)生也最多等一個(gè)超時(shí)時(shí)間”。Java的ReentrantLock提供了tryLock方法可以指定最長(zhǎng)等待時(shí)間if (first.lock().tryLock(1, TimeUnit.SECONDS)) { try { if (second.lock().tryLock(1, TimeUnit.SECONDS)) { try { // 執(zhí)行轉(zhuǎn)賬 } finally { second.unlock(); } } else { // 獲取第二把鎖超時(shí)放棄本次操作可記錄日志后重試 } } finally { first.unlock(); } }這里的關(guān)鍵細(xì)節(jié)是第二把鎖獲取失敗時(shí)一定要先釋放已經(jīng)獲取到的第一把鎖再做補(bǔ)償。否則雖然避免了循環(huán)等待卻可能演變成“單個(gè)線程長(zhǎng)時(shí)間占著一把鎖不放”一樣把系統(tǒng)拖垮。tryLock超時(shí)時(shí)長(zhǎng)的設(shè)置也很有講究。太短比如50毫秒在高峰期可能因?yàn)殒i競(jìng)爭(zhēng)稍微激烈就頻繁失敗太長(zhǎng)比如10秒請(qǐng)求堆積起來(lái)還是會(huì)把線程池耗盡。我一般先設(shè)1秒再根據(jù)業(yè)務(wù)尖峰的實(shí)測(cè)情況調(diào)整。5.3 減少鎖嵌套消滅持鎖等鎖的根源全局排序和超時(shí)都是控制手段真正治本的是減少嵌套加鎖。如果一段邏輯根本不需要同時(shí)持有兩把鎖那就沒(méi)有持鎖等鎖的機(jī)會(huì)死鎖自然無(wú)從談起。賬戶轉(zhuǎn)賬其實(shí)有別的實(shí)現(xiàn)思路比如把賬戶余額改成AtomicLong用CAS自旋把先扣款再入賬的過(guò)程做對(duì)或者用一個(gè)單一的重入鎖保護(hù)整個(gè)轉(zhuǎn)賬模塊避免鎖了兩個(gè)對(duì)象還可以借助數(shù)據(jù)庫(kù)事務(wù)把多賬戶扣減放在同一個(gè)事務(wù)里用數(shù)據(jù)庫(kù)的行鎖去保證一致性應(yīng)用層就不需要自己加鎖了。這些方案各有取舍。全局單一鎖實(shí)現(xiàn)簡(jiǎn)單但會(huì)犧牲并發(fā)度數(shù)據(jù)庫(kù)事務(wù)可靠但會(huì)拉長(zhǎng)連接占用時(shí)間。我之前在一個(gè)訂單系統(tǒng)里見(jiàn)過(guò)把“鎖兩個(gè)對(duì)象”改成“鎖一個(gè)賬戶服務(wù)對(duì)象”的做法并發(fā)量上來(lái)后吞吐直接掉了一半后來(lái)改成按賬戶緯度分桶加鎖才在并發(fā)和一致性之間找到平衡。5.4 四種方案怎么選方案破壞的條件適用場(chǎng)景主要代價(jià)全局鎖排序循環(huán)等待資源有天然ID或有明確順序需要侵入調(diào)用方約束tryLock有界等待持有并等待/不可剝奪無(wú)法控制鎖順序且允許失敗重試超時(shí)設(shè)置難可能頻繁失敗減少嵌套/單鎖持有并等待業(yè)務(wù)能接受鎖粒度粗或可無(wú)鎖化并發(fā)度降低或改造成本高鎖超時(shí)放棄重試持有并等待分布式系統(tǒng)鎖競(jìng)爭(zhēng)不極端重試風(fēng)暴風(fēng)險(xiǎn)需要兜底自動(dòng)檢測(cè)死鎖恢復(fù)人力資源干預(yù)已有監(jiān)控體系允許自動(dòng)回滾需要額外監(jiān)控組件依賴JVM/DB檢測(cè)實(shí)際項(xiàng)目里幾乎沒(méi)有一場(chǎng)死鎖修復(fù)只靠單一方案。我的建議是能用全局排序就用全局排序這是成本最低、最不容易出錯(cuò)的同時(shí)給所有Lock加超時(shí)作為最后一道保險(xiǎn)再把監(jiān)控和自動(dòng)檢測(cè)接上保證出了問(wèn)題能在幾分鐘內(nèi)發(fā)現(xiàn)。6. 預(yù)防死鎖的工程化做法和我在代碼評(píng)審里常說(shuō)的幾句話6.1 加鎖規(guī)范必須寫(xiě)進(jìn)團(tuán)隊(duì)約定死鎖問(wèn)題的修復(fù)成本遠(yuǎn)大于預(yù)防成本所以工程上的預(yù)防比互聯(lián)網(wǎng)上的“事后方案”更重要。團(tuán)隊(duì)里應(yīng)該有一個(gè)明確的加鎖規(guī)范內(nèi)容不用多三條就夠第一禁止嵌套加鎖。如果一個(gè)方法已經(jīng)持有一把鎖內(nèi)部不要再去獲取另一把鎖。特殊情況下必須嵌套要在代碼注釋里寫(xiě)清楚鎖順序比如“先鎖orderLock再鎖userLock任何地方都不許反著來(lái)”。第二禁止在持鎖狀態(tài)下做耗時(shí)操作。不要在鎖內(nèi)調(diào)用外部RPC、執(zhí)行慢SQL、做大量IO或一切可能長(zhǎng)時(shí)間阻塞的動(dòng)作。這條不僅防死鎖還防“隱式死鎖”一個(gè)線程持鎖后卡在網(wǎng)絡(luò)請(qǐng)求上其他線程全部等著看起來(lái)像死鎖其實(shí)是鎖被長(zhǎng)時(shí)間占而不放。第三統(tǒng)一使用帶超時(shí)的鎖。除非是極端短臨界區(qū)且明確不會(huì)嵌套否則盡量不要用無(wú)條件的lock()能用tryLock就tryLock。這不是慫是給系統(tǒng)留退路。6.2 代碼評(píng)審時(shí)盯哪幾行我review代碼時(shí)遇到并發(fā)相關(guān)改動(dòng)會(huì)特別盯幾個(gè)點(diǎn)有沒(méi)有出現(xiàn)兩層以上的鎖嵌套嵌套加鎖時(shí)鎖的獲取順序是否全局一致持有鎖的臨界區(qū)內(nèi)有沒(méi)有調(diào)用外部方法以及線程池任務(wù)里是否獲取了鎖卻不交還。有一個(gè)很容易忽略的場(chǎng)景是在回調(diào)、監(jiān)聽(tīng)器或異步線程里獲取鎖然后和主流程的鎖形成交叉。這種代碼最容易隱藏循環(huán)等待因?yàn)檎{(diào)用鏈跨了線程只有完整的線程棧才能暴露出來(lái)。所以每次上線前組織一次并發(fā)代碼走查把涉及鎖的調(diào)用鏈畫(huà)出來(lái)比出事了再抓dump省很多時(shí)間。6.3 壓測(cè)和自動(dòng)檢測(cè)怎么配合壓測(cè)階段建議做兩件事。一是寫(xiě)一個(gè)專門(mén)的并發(fā)回歸用例用CountDownLatch讓多個(gè)線程同時(shí)起跑反復(fù)執(zhí)行高競(jìng)爭(zhēng)的轉(zhuǎn)賬、更新操作連續(xù)跑幾千次。二是給測(cè)試用例掛上ThreadMXBean檢測(cè)在用例結(jié)束后自動(dòng)查一次findDeadlockedThreads發(fā)現(xiàn)有死鎖立即輸出失敗標(biāo)志。這樣只要死鎖出現(xiàn)過(guò)一次就能被當(dāng)作測(cè)試失敗抓到而不是等到下一次線上事故。上線之后運(yùn)維監(jiān)控里要有一條針對(duì)線程狀態(tài)的指標(biāo)某個(gè)線程池的線程數(shù)量達(dá)到上限或者大量線程持續(xù)BLOCKED超過(guò)一定時(shí)間就應(yīng)該觸發(fā)告警。這些信號(hào)加上定期抓取的線程?？煺栈揪蜆?gòu)成了一個(gè)“死鎖雷達(dá)”。6.4 我踩過(guò)的幾個(gè)坑希望你別踩第一個(gè)坑是復(fù)現(xiàn)困難導(dǎo)致誤判。線上線程卡住第一反應(yīng)是死鎖但抓了線程棧發(fā)現(xiàn)都在等同一個(gè)分布式鎖而分布式鎖因?yàn)槌钟姓哌M(jìn)程崩潰沒(méi)有釋放這叫“鎖泄漏”不是死鎖。處理方式完全不同一個(gè)是找循環(huán)等待一個(gè)是給分布式鎖加過(guò)期時(shí)間。第二個(gè)坑是修完A轉(zhuǎn)賬死鎖過(guò)了幾周B模塊又出現(xiàn)類似問(wèn)題。這是因?yàn)橹恍蘖司唧w場(chǎng)景沒(méi)有把鎖順序規(guī)范推廣到全局。后來(lái)我把所有需要鎖多個(gè)資源的入口都強(qiáng)制走同一個(gè)“鎖排序工具類”才把這個(gè)口子堵上。第三個(gè)坑是tryLock獲取成功之后忘了在finally里釋放。出現(xiàn)死鎖時(shí)通過(guò)超時(shí)自愈了但因?yàn)樯賹?xiě)一個(gè)unlock導(dǎo)致鎖一直被持有系統(tǒng)反而慢慢沒(méi)并發(fā)度了。這個(gè)錯(cuò)誤比死鎖更難排查因?yàn)榫€程棧顯示的是“持鎖”不是“等待”痛過(guò)一次之后就長(zhǎng)記性了。多線程死鎖不會(huì)因?yàn)槟惚呈炝怂膫€(gè)必要條件就遠(yuǎn)離你的代碼。真正讓它遠(yuǎn)離的是把鎖順序?qū)戇M(jìn)規(guī)范、把超時(shí)機(jī)制當(dāng)成習(xí)慣、把檢測(cè)手段接進(jìn)回歸流程。希望這些實(shí)戰(zhàn)經(jīng)驗(yàn)對(duì)你有所幫助下次你看到線程棧上的“Found one Java-level deadlock”時(shí)能少走幾步彎路。 多線程死鎖實(shí)戰(zhàn)：從四個(gè)必要條件到j(luò)stack排查與工程化預(yù)防
上周又有人在群里發(fā)了一張線程轉(zhuǎn)儲(chǔ)截圖問(wèn)“線程狀態(tài)全是WAITING服務(wù)也不報(bào)錯(cuò)業(yè)務(wù)就是不動(dòng)是不是死鎖”我一看那圖上兩條線程互等對(duì)方釋放鎖就知道又是老場(chǎng)面了。多線程死鎖這東西面試題里年年考理論背得滾瓜爛熟可真到線上出問(wèn)題時(shí)能一眼認(rèn)出來(lái)并快速處理的人其實(shí)不多。這篇文章就圍繞多線程死鎖展開(kāi)先說(shuō)清楚它的本質(zhì)和四個(gè)必要條件然后用一個(gè)賬戶轉(zhuǎn)賬的真實(shí)案例一步步復(fù)現(xiàn)死鎖現(xiàn)場(chǎng)再講線上排查的完整鏈路jstack、JConsole、數(shù)據(jù)庫(kù)鎖日志這些工具怎么配合用最后給出修復(fù)方案和工程化的預(yù)防手段。適合正在學(xué)并發(fā)編程的初學(xué)者也適合寫(xiě)過(guò)多線程代碼、但還沒(méi)被死鎖“教育”過(guò)的開(kāi)發(fā)者。1. 死鎖是并發(fā)編程里最安靜的故障1.1 線上死鎖長(zhǎng)什么樣死鎖在線上有個(gè)很坑的特點(diǎn)它不會(huì)讓進(jìn)程崩潰不會(huì)拋出異常不會(huì)像OOM那樣直接留下日志。你只會(huì)發(fā)現(xiàn)某個(gè)接口突然超時(shí)然后超時(shí)的請(qǐng)求越來(lái)越多緊接著線程池被占滿健康檢查開(kāi)始失敗最后整臺(tái)機(jī)器被流量調(diào)度系統(tǒng)摘掉。我見(jiàn)過(guò)最典型的案例是這樣的一個(gè)支付回調(diào)服務(wù)白天業(yè)務(wù)量平穩(wěn)還好一到晚上賬務(wù)批處理任務(wù)跑起來(lái)就會(huì)有幾個(gè)交易卡住。重啟服務(wù)就好了但過(guò)了幾個(gè)小時(shí)又出現(xiàn)。剛開(kāi)始大家以為是數(shù)據(jù)庫(kù)慢查詢后來(lái)抓線程棧才看見(jiàn)賬務(wù)批處理線程持有一把鎖在處理回調(diào)的線程等待而回調(diào)線程也持有一把鎖批處理線程正在等它。兩邊誰(shuí)也不讓誰(shuí)業(yè)務(wù)就停了下來(lái)。這類問(wèn)題的可怕之處在于它在測(cè)試環(huán)境很難復(fù)現(xiàn)。單元測(cè)試?yán)飪蓚€(gè)線程按順序跑根本不會(huì)出現(xiàn)競(jìng)態(tài)即使偶發(fā)一次重啟就好報(bào)錯(cuò)日志為零很容易被當(dāng)成“偶發(fā)網(wǎng)絡(luò)抖動(dòng)”略過(guò)。1.2 死鎖和普通性能問(wèn)題有什么不同普通性能問(wèn)題比如慢SQL、Full GC、CPU飆高通常都有明顯的“癥狀指標(biāo)”要么響應(yīng)時(shí)間上去要么CPU利用率異常要么內(nèi)存曲線陡增。而死鎖的癥狀非常隱蔽CPU利用率可能很低內(nèi)存也正常線程池里的線程卻全部卡在BLOCKED或WAITING狀態(tài)活活把一個(gè)可以3秒內(nèi)完成的請(qǐng)求拖到超時(shí)。用個(gè)生活類比死鎖就像是兩輛車在窄橋上迎面相遇彼此都占著自己這邊的車道同時(shí)堅(jiān)持讓對(duì)方讓路。沒(méi)有一輛車壞掉也沒(méi)有人違規(guī)可交通就是永遠(yuǎn)癱瘓了。排查這類問(wèn)題不能靠看CPU和日志必須直接看線程在等什么。我平時(shí)排查的第一步永遠(yuǎn)是找到那些長(zhǎng)期處于BLOCKED或WAITING狀態(tài)的線程打印它們的堆棧看它們分別持有什么鎖、正在請(qǐng)求什么鎖。只要看到一條“A持有X等YB持有Y等X”的循環(huán)鏈基本就可以鎖定死鎖。2. 四個(gè)必要條件差一個(gè)都鎖不死想理解死鎖為什么發(fā)生先要記住一個(gè)經(jīng)典結(jié)論死鎖發(fā)生產(chǎn)生的核心原因可以歸納為四個(gè)條件它們必須同時(shí)滿足缺一不可。這也是為什么所有修復(fù)方案本質(zhì)都是在“破壞其中一個(gè)條件”。2.1 互斥沒(méi)法改的前提第一個(gè)條件是互斥同一時(shí)刻一個(gè)共享資源只能被一個(gè)線程占用。鎖的語(yǔ)義天然就是互斥的讀寫(xiě)鎖里寫(xiě)鎖是互斥的數(shù)據(jù)庫(kù)的行鎖也是互斥的分布式鎖更是專門(mén)做互斥的。這個(gè)條件在絕大多數(shù)場(chǎng)景下不能也無(wú)需被破壞。我們加鎖的目的正是為了保證互斥訪問(wèn)如果去掉互斥那并發(fā)安全就無(wú)從談起。所以修復(fù)死鎖時(shí)不要去動(dòng)這個(gè)條件。2.2 持有并等待嵌套加鎖的元兇第二個(gè)條件叫持有并等待線程已經(jīng)持有一把鎖同時(shí)還想去獲取另一把鎖在等待第二把鎖的過(guò)程中它不釋放第一把鎖。這是我自己寫(xiě)代碼時(shí)最常踩的坑。比如一個(gè)賬戶轉(zhuǎn)賬功能轉(zhuǎn)賬操作需要同時(shí)鎖定轉(zhuǎn)出賬戶和轉(zhuǎn)入賬戶防止余額被并發(fā)修改。如果先鎖from賬戶再去鎖to賬戶而另一個(gè)線程正好反過(guò)來(lái)先鎖了to賬戶再去鎖from賬戶持有并等待的條件就成立了。記住一句話每出現(xiàn)一次“持有一把鎖再去拿另一把鎖”就是往死鎖的方向邁了一步。不是每次都會(huì)死鎖但一旦時(shí)機(jī)配合死鎖就是必然。2.3 不可剝奪鎖釋放點(diǎn)決定了死局第三個(gè)條件是不可剝奪線程已經(jīng)獲得的鎖在自己主動(dòng)釋放之前不能被其他線程強(qiáng)行奪走。Java的synchronized和ReentrantLock在默認(rèn)語(yǔ)義下都是不可剝奪的synchronized連中斷都不響應(yīng)ReentrantLock還得靠lockInterruptibly才能響應(yīng)中斷。數(shù)據(jù)庫(kù)的行鎖也是這樣事務(wù)沒(méi)提交之前其他事務(wù)只能等著。這個(gè)條件告訴我們鎖的釋放時(shí)機(jī)完全掌握在持有者手里。如果持有者因?yàn)榫W(wǎng)絡(luò)、等待、外部調(diào)用阻塞住了那所有等待這把鎖的線程都會(huì)被拖下水。2.4 循環(huán)等待最后一個(gè)條件第四個(gè)條件是循環(huán)等待存在一組線程它們互相等待對(duì)方持有的資源形成一個(gè)首尾相接的等待環(huán)。比如線程A持有鎖1等待鎖2線程B持有鎖2等待鎖1這就是最簡(jiǎn)單的兩節(jié)點(diǎn)環(huán)。3. 用賬戶轉(zhuǎn)賬復(fù)現(xiàn)一次標(biāo)準(zhǔn)的死鎖過(guò)程3.1 從業(yè)務(wù)邏輯到代碼模型理論講多了容易飄直接看一段能跑的死鎖代碼。假設(shè)有個(gè)最簡(jiǎn)單的銀行賬戶系統(tǒng)Account類維護(hù)余額和一把自己的鎖class Account { private final int id; private int balance; private final ReentrantLock lock new ReentrantLock(); public Account(int id, int balance) { this.id id; this.balance balance; } public void deposit(int amount) { balance amount; } public void withdraw(int amount) { balance - amount; } public void lock() { lock.lock(); } public void unlock() { lock.unlock(); } }轉(zhuǎn)賬方法天然需要鎖定兩個(gè)賬戶防止轉(zhuǎn)賬過(guò)程中余額被并發(fā)修改static void transfer(Account from, Account to, int amount) { from.lock(); try { to.lock(); try { from.withdraw(amount); to.deposit(amount); } finally { to.unlock(); } } finally { from.unlock(); } }這段代碼從功能上完全“正確”既不丟錢也不重復(fù)扣錢可它隱含了一個(gè)致命問(wèn)題鎖的順序不一致。只要調(diào)用方向相反就會(huì)埋下死鎖的種子。3.2 完整復(fù)現(xiàn)代碼與運(yùn)行結(jié)果下面用兩個(gè)線程讓死鎖必然發(fā)生。設(shè)想賬戶A余額1000賬戶B余額1000。線程1執(zhí)行“從A轉(zhuǎn)100到B”線程2同時(shí)執(zhí)行“從B轉(zhuǎn)200到A”public class DeadlockDemo { public static void main(String[] args) throws Exception { Account a new Account(1, 1000); Account b new Account(2, 1000); Thread t1 new Thread(() - transfer(a, b, 100), T1); Thread t2 new Thread(() - transfer(b, a, 200), T2); t1.start(); t2.start(); t1.join(); t2.join(); System.out.println(transfer done); } }如果運(yùn)氣好跑一兩次可能不會(huì)死鎖因?yàn)榫€程啟動(dòng)順序和調(diào)度時(shí)機(jī)決定了是否真的形成交叉等待。為了穩(wěn)定復(fù)現(xiàn)可以在線程1鎖定from之后加一個(gè)小小的停頓讓兩個(gè)線程能卡在對(duì)方節(jié)點(diǎn)上Thread t1 new Thread(() - { a.lock(); try { Thread.sleep(100); b.lock(); try { a.withdraw(100); b.deposit(100); } finally { b.unlock(); } } catch (InterruptedException e) { Thread.currentThread().interrupt(); } finally { a.unlock(); } }, T1);這樣跑程序大概率會(huì)直接卡住永遠(yuǎn)打印不出“transfer done”。兩個(gè)線程都持有一把鎖同時(shí)等待對(duì)方的那把鎖恰好滿足前面說(shuō)的全部四個(gè)條件。3.3 數(shù)據(jù)庫(kù)行鎖同樣會(huì)死鎖眼光放大一點(diǎn)多線程死鎖不止發(fā)生在Java內(nèi)存鎖上數(shù)據(jù)庫(kù)表里同樣有死鎖。兩個(gè)事務(wù)同時(shí)更新兩條記錄但更新順序相反就會(huì)觸發(fā)數(shù)據(jù)庫(kù)行鎖死鎖。比如事務(wù)A先更新user_id1的行再更新user_id2的行事務(wù)B先更新user_id2的行再更新user_id1的行。由于行鎖互斥兩個(gè)事務(wù)互相等待對(duì)方提交數(shù)據(jù)庫(kù)死鎖檢測(cè)器介入后會(huì)回滾其中一個(gè)事務(wù)讓另一個(gè)繼續(xù)執(zhí)行。這給業(yè)務(wù)代碼的啟示是即使服務(wù)端沒(méi)有任何鎖只要SQL事務(wù)里涉及多條記錄的更新就存在數(shù)據(jù)庫(kù)層面的行鎖死鎖風(fēng)險(xiǎn)。修復(fù)思路其實(shí)一樣讓事務(wù)內(nèi)的多條SQL語(yǔ)句總是按同一順序更新數(shù)據(jù)即可。4. 線上排查死鎖的三板斧與完整鏈路4.1 先確認(rèn)“卡住”是不是死鎖線上遇到接口超時(shí)、線程池耗盡第一步不是找死鎖而是先確認(rèn)現(xiàn)象?？淳€程是不是大面積長(zhǎng)時(shí)間處于BLOCKED或WAITING狀態(tài)以及有沒(méi)有一條清晰的等待鏈。常見(jiàn)誤區(qū)是只要看到WAITING就覺(jué)得是死鎖。實(shí)際上線程在Object.wait()或LockSupport.park()的時(shí)候也是WAITING狀態(tài)很多是正常的等待喚醒機(jī)制。只有“等待的鎖正被另一個(gè)線程持有而那個(gè)線程也在等鎖”才是死鎖。所以排查一定要拿線程棧逐線程分析不能光看狀態(tài)名。4.2 jstack找Java級(jí)死鎖jstack是排查Java死鎖最趁手的工具用法很簡(jiǎn)單jstack pid thread_dump.txt如果JVM檢測(cè)到Java級(jí)別的死鎖會(huì)在線程棧頂部明確輸出“Found one Java-level deadlock”字樣并列出死鎖線程的等待關(guān)系格式大致如下Found one Java-level deadlock: T2: waiting to lock monitor 0x00007f (object 0x0000000012345678, a Account), which is held by T1 T1: waiting to lock monitor 0x00007f (object 0x00000000abcdef01, a Account), which is held by T2 Java stack information for the threads listed above: ...看到這個(gè)頭問(wèn)題就基本定性了。建議連續(xù)抓兩三次線程棧間隔幾秒確認(rèn)等待鏈穩(wěn)定存在避免抓到半路正在釋放鎖的瞬時(shí)狀態(tài)。不過(guò)要注意一點(diǎn)jstack能自動(dòng)檢測(cè)的是synchronized和ReentrantLock等Java管程對(duì)象上的死鎖。如果死鎖發(fā)生在AQS內(nèi)部的顯式條件隊(duì)列之間或者鎖是通過(guò)Unsafe這類底層機(jī)制實(shí)現(xiàn)的jstack不一定能自動(dòng)給出“Found deadlock”的結(jié)論這時(shí)候就要手動(dòng)解析線程棧里的“waiting to lock”和“l(fā)ocked”信息。4.3 JConsole與ThreadMXBean兜底生產(chǎn)環(huán)境如果不好執(zhí)行命令行可以用JConsole連上進(jìn)程在線程頁(yè)簽里看線程狀態(tài)和堆棧界面很直觀雙擊任何一條線程就能看到它的調(diào)用棧和鎖持有情況。如果想把死鎖檢測(cè)做成自動(dòng)化Java標(biāo)準(zhǔn)庫(kù)提供了ThreadMXBeanThreadMXBean tmb ManagementFactory.getThreadMXBean(); long[] deadlockedIds tmb.findDeadlockedThreads(); if (deadlockedIds ! null) { for (long id : deadlockedIds) { ThreadInfo info tmb.getThreadInfo(id); System.out.println(deadlocked thread: info.getThreadName()); } }注意兩個(gè)方法的區(qū)別findDeadlockedThreads能檢測(cè)到包括java.util.concurrent鎖在內(nèi)的死鎖findMonitorDeadlockedThreads只能檢測(cè)到monitor鎖也就是synchronized相關(guān)的死鎖。建議用前者。在自動(dòng)化回歸測(cè)試?yán)锟梢栽谒胁l(fā)用例跑完后調(diào)用一次findDeadlockedThreads一旦返回非空就直接讓測(cè)試失敗。這是成本最低的死鎖防線比靠人工review代碼靠譜得多。4.4 數(shù)據(jù)庫(kù)死鎖的排查路徑數(shù)據(jù)庫(kù)死鎖的排查鏈路不同重點(diǎn)看兩個(gè)地方一是數(shù)據(jù)庫(kù)自己的死鎖日志MySQL 5.7以上默認(rèn)開(kāi)啟innodb_print_all_deadlocks時(shí)可以打印到錯(cuò)誤日志或者用SHOW ENGINE INNODB STATUS查看最近一次死鎖的事務(wù)詳情二是應(yīng)用日志里是否出現(xiàn)錯(cuò)誤碼1213(MySQL死鎖)或類似“Deadlock found”的報(bào)錯(cuò)。拿到數(shù)據(jù)庫(kù)死鎖日志后重點(diǎn)看“WAITING FOR THIS LOCK TO BE GRANTED”和“HOLDS THE LOCK”這兩段就能還原出兩個(gè)事務(wù)分別持有哪一行鎖、等待哪一行鎖。修復(fù)手段通常是讓事務(wù)內(nèi)的SQL執(zhí)行順序統(tǒng)一或者在業(yè)務(wù)層面上按某個(gè)唯一鍵排序后再執(zhí)行批量更新。5. 修復(fù)死鎖的幾種思路以及它們的代價(jià)5.1 全局排序用規(guī)則破壞循環(huán)等待最經(jīng)典的修復(fù)死鎖方案就是打破循環(huán)等待這個(gè)條件給所有需要加鎖的資源定義一個(gè)全局順序所有線程一律按照這個(gè)順序加鎖不允許跳過(guò)或倒序。賬戶轉(zhuǎn)賬的例子可以改成按賬戶ID排序后加鎖static void transfer(Account from, Account to, int amount) { Account first from.id to.id ? from : to; Account second from.id to.id ? to : from; first.lock(); try { second.lock(); try { from.withdraw(amount); to.deposit(amount); } finally { second.unlock(); } } finally { first.unlock(); } }這樣無(wú)論外部傳入的轉(zhuǎn)賬方向如何內(nèi)部都是先鎖ID小的賬戶、再鎖ID大的賬戶。兩個(gè)線程不可能出現(xiàn)“你等我我等你”的環(huán)形等待。這個(gè)方案看起來(lái)簡(jiǎn)單實(shí)際落地有幾個(gè)坑。最典型的是如果資源本身沒(méi)有天然的ID順序比如一組對(duì)象池里的連接對(duì)象可以退一步用System.identityHashCode排序但哈希值可能會(huì)沖突沖突時(shí)要再準(zhǔn)備一個(gè)“打破平局”的鎖或比較規(guī)則否則排序就失效了。我一般會(huì)直接在業(yè)務(wù)對(duì)象里加一個(gè)自增ID盡量不依賴哈希。5.2 有界等待用超時(shí)打破僵局如果說(shuō)全局排序是“從設(shè)計(jì)上讓死鎖不可能發(fā)生”那有界等待就是在“賭死鎖就算發(fā)生也最多等一個(gè)超時(shí)時(shí)間”。Java的ReentrantLock提供了tryLock方法可以指定最長(zhǎng)等待時(shí)間if (first.lock().tryLock(1, TimeUnit.SECONDS)) { try { if (second.lock().tryLock(1, TimeUnit.SECONDS)) { try { // 執(zhí)行轉(zhuǎn)賬 } finally { second.unlock(); } } else { // 獲取第二把鎖超時(shí)放棄本次操作可記錄日志后重試 } } finally { first.unlock(); } }這里的關(guān)鍵細(xì)節(jié)是第二把鎖獲取失敗時(shí)一定要先釋放已經(jīng)獲取到的第一把鎖再做補(bǔ)償。否則雖然避免了循環(huán)等待卻可能演變成“單個(gè)線程長(zhǎng)時(shí)間占著一把鎖不放”一樣把系統(tǒng)拖垮。tryLock超時(shí)時(shí)長(zhǎng)的設(shè)置也很有講究。太短比如50毫秒在高峰期可能因?yàn)殒i競(jìng)爭(zhēng)稍微激烈就頻繁失敗太長(zhǎng)比如10秒請(qǐng)求堆積起來(lái)還是會(huì)把線程池耗盡。我一般先設(shè)1秒再根據(jù)業(yè)務(wù)尖峰的實(shí)測(cè)情況調(diào)整。5.3 減少鎖嵌套消滅持鎖等鎖的根源全局排序和超時(shí)都是控制手段真正治本的是減少嵌套加鎖。如果一段邏輯根本不需要同時(shí)持有兩把鎖那就沒(méi)有持鎖等鎖的機(jī)會(huì)死鎖自然無(wú)從談起。賬戶轉(zhuǎn)賬其實(shí)有別的實(shí)現(xiàn)思路比如把賬戶余額改成AtomicLong用CAS自旋把先扣款再入賬的過(guò)程做對(duì)或者用一個(gè)單一的重入鎖保護(hù)整個(gè)轉(zhuǎn)賬模塊避免鎖了兩個(gè)對(duì)象還可以借助數(shù)據(jù)庫(kù)事務(wù)把多賬戶扣減放在同一個(gè)事務(wù)里用數(shù)據(jù)庫(kù)的行鎖去保證一致性應(yīng)用層就不需要自己加鎖了。這些方案各有取舍。全局單一鎖實(shí)現(xiàn)簡(jiǎn)單但會(huì)犧牲并發(fā)度數(shù)據(jù)庫(kù)事務(wù)可靠但會(huì)拉長(zhǎng)連接占用時(shí)間。我之前在一個(gè)訂單系統(tǒng)里見(jiàn)過(guò)把“鎖兩個(gè)對(duì)象”改成“鎖一個(gè)賬戶服務(wù)對(duì)象”的做法并發(fā)量上來(lái)后吞吐直接掉了一半后來(lái)改成按賬戶緯度分桶加鎖才在并發(fā)和一致性之間找到平衡。5.4 四種方案怎么選方案破壞的條件適用場(chǎng)景主要代價(jià)全局鎖排序循環(huán)等待資源有天然ID或有明確順序需要侵入調(diào)用方約束tryLock有界等待持有并等待/不可剝奪無(wú)法控制鎖順序且允許失敗重試超時(shí)設(shè)置難可能頻繁失敗減少嵌套/單鎖持有并等待業(yè)務(wù)能接受鎖粒度粗或可無(wú)鎖化并發(fā)度降低或改造成本高鎖超時(shí)放棄重試持有并等待分布式系統(tǒng)鎖競(jìng)爭(zhēng)不極端重試風(fēng)暴風(fēng)險(xiǎn)需要兜底自動(dòng)檢測(cè)死鎖恢復(fù)人力資源干預(yù)已有監(jiān)控體系允許自動(dòng)回滾需要額外監(jiān)控組件依賴JVM/DB檢測(cè)實(shí)際項(xiàng)目里幾乎沒(méi)有一場(chǎng)死鎖修復(fù)只靠單一方案。我的建議是能用全局排序就用全局排序這是成本最低、最不容易出錯(cuò)的同時(shí)給所有Lock加超時(shí)作為最后一道保險(xiǎn)再把監(jiān)控和自動(dòng)檢測(cè)接上保證出了問(wèn)題能在幾分鐘內(nèi)發(fā)現(xiàn)。6. 預(yù)防死鎖的工程化做法和我在代碼評(píng)審里常說(shuō)的幾句話6.1 加鎖規(guī)范必須寫(xiě)進(jìn)團(tuán)隊(duì)約定死鎖問(wèn)題的修復(fù)成本遠(yuǎn)大于預(yù)防成本所以工程上的預(yù)防比互聯(lián)網(wǎng)上的“事后方案”更重要。團(tuán)隊(duì)里應(yīng)該有一個(gè)明確的加鎖規(guī)范內(nèi)容不用多三條就夠第一禁止嵌套加鎖。如果一個(gè)方法已經(jīng)持有一把鎖內(nèi)部不要再去獲取另一把鎖。特殊情況下必須嵌套要在代碼注釋里寫(xiě)清楚鎖順序比如“先鎖orderLock再鎖userLock任何地方都不許反著來(lái)”。第二禁止在持鎖狀態(tài)下做耗時(shí)操作。不要在鎖內(nèi)調(diào)用外部RPC、執(zhí)行慢SQL、做大量IO或一切可能長(zhǎng)時(shí)間阻塞的動(dòng)作。這條不僅防死鎖還防“隱式死鎖”一個(gè)線程持鎖后卡在網(wǎng)絡(luò)請(qǐng)求上其他線程全部等著看起來(lái)像死鎖其實(shí)是鎖被長(zhǎng)時(shí)間占而不放。第三統(tǒng)一使用帶超時(shí)的鎖。除非是極端短臨界區(qū)且明確不會(huì)嵌套否則盡量不要用無(wú)條件的lock()能用tryLock就tryLock。這不是慫是給系統(tǒng)留退路。6.2 代碼評(píng)審時(shí)盯哪幾行我review代碼時(shí)遇到并發(fā)相關(guān)改動(dòng)會(huì)特別盯幾個(gè)點(diǎn)有沒(méi)有出現(xiàn)兩層以上的鎖嵌套嵌套加鎖時(shí)鎖的獲取順序是否全局一致持有鎖的臨界區(qū)內(nèi)有沒(méi)有調(diào)用外部方法以及線程池任務(wù)里是否獲取了鎖卻不交還。有一個(gè)很容易忽略的場(chǎng)景是在回調(diào)、監(jiān)聽(tīng)器或異步線程里獲取鎖然后和主流程的鎖形成交叉。這種代碼最容易隱藏循環(huán)等待因?yàn)檎{(diào)用鏈跨了線程只有完整的線程棧才能暴露出來(lái)。所以每次上線前組織一次并發(fā)代碼走查把涉及鎖的調(diào)用鏈畫(huà)出來(lái)比出事了再抓dump省很多時(shí)間。6.3 壓測(cè)和自動(dòng)檢測(cè)怎么配合壓測(cè)階段建議做兩件事。一是寫(xiě)一個(gè)專門(mén)的并發(fā)回歸用例用CountDownLatch讓多個(gè)線程同時(shí)起跑反復(fù)執(zhí)行高競(jìng)爭(zhēng)的轉(zhuǎn)賬、更新操作連續(xù)跑幾千次。二是給測(cè)試用例掛上ThreadMXBean檢測(cè)在用例結(jié)束后自動(dòng)查一次findDeadlockedThreads發(fā)現(xiàn)有死鎖立即輸出失敗標(biāo)志。這樣只要死鎖出現(xiàn)過(guò)一次就能被當(dāng)作測(cè)試失敗抓到而不是等到下一次線上事故。上線之后運(yùn)維監(jiān)控里要有一條針對(duì)線程狀態(tài)的指標(biāo)某個(gè)線程池的線程數(shù)量達(dá)到上限或者大量線程持續(xù)BLOCKED超過(guò)一定時(shí)間就應(yīng)該觸發(fā)告警。這些信號(hào)加上定期抓取的線程?？煺栈揪蜆?gòu)成了一個(gè)“死鎖雷達(dá)”。6.4 我踩過(guò)的幾個(gè)坑希望你別踩第一個(gè)坑是復(fù)現(xiàn)困難導(dǎo)致誤判。線上線程卡住第一反應(yīng)是死鎖但抓了線程棧發(fā)現(xiàn)都在等同一個(gè)分布式鎖而分布式鎖因?yàn)槌钟姓哌M(jìn)程崩潰沒(méi)有釋放這叫“鎖泄漏”不是死鎖。處理方式完全不同一個(gè)是找循環(huán)等待一個(gè)是給分布式鎖加過(guò)期時(shí)間。第二個(gè)坑是修完A轉(zhuǎn)賬死鎖過(guò)了幾周B模塊又出現(xiàn)類似問(wèn)題。這是因?yàn)橹恍蘖司唧w場(chǎng)景沒(méi)有把鎖順序規(guī)范推廣到全局。后來(lái)我把所有需要鎖多個(gè)資源的入口都強(qiáng)制走同一個(gè)“鎖排序工具類”才把這個(gè)口子堵上。第三個(gè)坑是tryLock獲取成功之后忘了在finally里釋放。出現(xiàn)死鎖時(shí)通過(guò)超時(shí)自愈了但因?yàn)樯賹?xiě)一個(gè)unlock導(dǎo)致鎖一直被持有系統(tǒng)反而慢慢沒(méi)并發(fā)度了。這個(gè)錯(cuò)誤比死鎖更難排查因?yàn)榫€程棧顯示的是“持鎖”不是“等待”痛過(guò)一次之后就長(zhǎng)記性了。多線程死鎖不會(huì)因?yàn)槟惚呈炝怂膫€(gè)必要條件就遠(yuǎn)離你的代碼。真正讓它遠(yuǎn)離的是把鎖順序?qū)戇M(jìn)規(guī)范、把超時(shí)機(jī)制當(dāng)成習(xí)慣、把檢測(cè)手段接進(jìn)回歸流程。希望這些實(shí)戰(zhàn)經(jīng)驗(yàn)對(duì)你有所幫助下次你看到線程棧上的“Found one Java-level deadlock”時(shí)能少走幾步彎路。