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