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