1. 從一次現(xiàn)場卡死說起死鎖到底鎖住了什么做嵌入式開發(fā)的朋友尤其是搞過RTOS多任務(wù)系統(tǒng)的基本都遇到過這種讓人頭皮發(fā)麻的場景板子跑著跑著某個任務(wù)突然不調(diào)度了看門狗嗷嗷叫串口打印停在半句話上按鍵沒反應(yīng)LED保持最后一個狀態(tài)。第一反應(yīng)是程序飛了或者棧溢出了結(jié)果一查既不是HardFault也不是內(nèi)存踩踏而是兩個任務(wù)互相握著對方需要的資源誰也不撒手活活把系統(tǒng)鎖死了。這就是死鎖英文叫Deadlock。在計算機(jī)四級嵌入式考試的操作系統(tǒng)原理部分死鎖是一個反復(fù)出現(xiàn)的核心考點同時也是嵌入式工程里最容易翻車的問題之一。我記得當(dāng)年備考的時候把死鎖的四個必要條件背得滾瓜爛熟但真正在項目里定位死鎖才發(fā)現(xiàn)紙上得來終覺淺考試考的是概念項目考的是眼力。這篇文章我想把死鎖這件事徹底講透從理論定義、四個必要條件到銀行家算法的手工推演再到嵌入式場景下如何預(yù)防、檢測、定位和解除。不光是給準(zhǔn)備四級考試的同學(xué)梳理考點也給正在被項目里偶發(fā)死鎖折磨的工程師一些可以直接上手的排查思路。死鎖一旦理解通透你看代碼的視角會完全不一樣——看到一個任務(wù)持鎖后再去申請另一個鎖你會本能地停下來問一句這個順序別的任務(wù)是不是也一致2. 死鎖的本質(zhì)與四個必要條件缺一不可的死亡組合先明確一個概念死鎖不是程序崩潰而是一組任務(wù)或線程彼此等待對方占用的資源導(dǎo)致所有相關(guān)任務(wù)都無法繼續(xù)推進(jìn)的狀態(tài)。它最隱蔽的地方在于系統(tǒng)表面上還活著——中斷能響應(yīng)、內(nèi)存沒爆、CPU占用率可能還是正常的但業(yè)務(wù)邏輯已經(jīng)徹底停擺。操作系統(tǒng)教材里對死鎖的定義非常嚴(yán)格只有當(dāng)互斥、持有并等待、不可剝奪、循環(huán)等待這四個條件同時滿足時死鎖才會發(fā)生。這四件事缺一個死鎖就形不成。這個表述不光是考試要考的默寫題更是工程排查的索引——你只要打破其中任何一個條件死鎖就能解開。**互斥條件Mutual Exclusion**好理解就是指資源同一時刻只能被一個任務(wù)獨占使用。嵌入式里的典型互斥資源就是互斥鎖Mutex、硬件外設(shè)比如UART、SPI、I2C總線還有DMA通道、Flash寫操作。這些資源天生就不能同時共享這是問題產(chǎn)生的土壤。**持有并等待Hold and Wait**指的是任務(wù)已經(jīng)握住了一個資源同時又在等待另一個資源釋放。用代碼翻譯就是任務(wù)A拿到了鎖1還沒釋放接著去請求鎖2。如果鎖2恰好被任務(wù)B拿著而任務(wù)B又在等鎖1那么兩個任務(wù)就進(jìn)入了一種誰也動彈不得的僵局。**不可剝奪No Preemption**是說任務(wù)持有的資源不能被操作系統(tǒng)強(qiáng)行搶走只能由持有者主動釋放。這在嵌入式RTOS里幾乎是默認(rèn)規(guī)則——你沒法從一個持有互斥鎖的任務(wù)手中硬把鎖搶過來哪怕那個任務(wù)優(yōu)先級更低。正是這個不可剝奪才讓循環(huán)等待能夠真正形成閉環(huán)。**循環(huán)等待Circular Wait**是四個條件里最直觀也最好判斷的存在一個任務(wù)集合 {T1, T2, ..., Tn}T1等T2占的資源T2等T3占的資源以此類推Tn等T1占的資源形成一個環(huán)。嵌入式里最常見的環(huán)就是兩個任務(wù)互相等對方的鎖代碼上看就是A鎖里申請B鎖B鎖里申請A鎖。這四者之間存在嚴(yán)格的邏輯關(guān)系互斥是前提持有并等待是過程不可剝奪是制度空缺循環(huán)等待是最終形態(tài)。實際項目里判斷是否發(fā)生死鎖我習(xí)慣先畫等待圖——每個任務(wù)畫一個節(jié)點任務(wù)如果正在等待某個資源就把資源指向任務(wù)這條邊畫出來。只要圖中出現(xiàn)了環(huán)死鎖就必然存在。這個判斷方法在第四級考試?yán)镆步?jīng)常以判斷系統(tǒng)是否處于死鎖狀態(tài)的形式出現(xiàn)本質(zhì)上就是考你有沒有建立圖中有環(huán)即死鎖的直覺。3. 事前預(yù)防破壞四個條件的工程化打法對嵌入式系統(tǒng)來說死鎖的預(yù)防遠(yuǎn)比事后處理更重要。原因很現(xiàn)實很多設(shè)備部署在現(xiàn)場之后你根本沒法遠(yuǎn)程按解除死鎖按鈕。所以我做項目時的原則是在寫代碼階段就把四條路堵死?？荚?yán)锇堰@部分叫死鎖預(yù)防工程上就是一套具體的編碼規(guī)約。第一條路破壞互斥條件。說實話這條路在嵌入式里最難走因為互斥鎖存在的意義恰恰就是保證互斥。但換個角度想有些資源并不是天生必須互斥的比如一塊數(shù)據(jù)緩沖區(qū)如果改成無鎖設(shè)計——用環(huán)形隊列加原子讀改寫操作讓生產(chǎn)者和消費(fèi)者并發(fā)訪問而不互相阻塞——那互斥條件自然就不存在了。我見過不少項目里用消息隊列給任務(wù)間傳數(shù)據(jù)本來隊列本身就帶互斥保護(hù)結(jié)果有人又額外套了一把全局鎖純屬畫蛇添足反而增加了死鎖風(fēng)險。**第二條路破壞持有并等待。**做法是要求任務(wù)在執(zhí)行臨界區(qū)之前一次性申請所有需要的資源申請不到就一個都不拿。聽起來很美但在嵌入式里操作難度極大資源數(shù)量往往是運(yùn)行期才確定的你沒法提前知道任務(wù)跑起來后要申請幾把鎖而且一次占用多個資源會降低系統(tǒng)的并發(fā)度這對實時性要求高的場景很不友好。我在實際項目里幾乎不用這種方案但考試?yán)锼鳛闃?biāo)準(zhǔn)預(yù)防策略必須會答。第三條路破壞不可剝奪。這是嵌入式RTOS里最常用的思路之一。做法是如果任務(wù)拿著鎖A去申請鎖B但鎖B被別的任務(wù)占用且等待超過一定時間系統(tǒng)允許把鎖A臨時讓出來重新排隊。說得再具體一點很多RTOS內(nèi)核里實現(xiàn)的互斥鎖超時機(jī)制就是這種思想pthread_mutex_timedlockPOSIX環(huán)境下或者RTOS自帶的帶超時參數(shù)的上鎖接口在規(guī)定時間內(nèi)拿不到鎖就返回錯誤碼任務(wù)該干嘛干嘛而不是無休止地阻塞。破壞不可剝奪還有一個更實用的變體叫優(yōu)先級繼承。雖然它主要是為解決優(yōu)先級反轉(zhuǎn)問題提出的但客觀上也能降低死鎖發(fā)生的概率——低優(yōu)先級任務(wù)持有鎖時如果高優(yōu)先級任務(wù)來等這把鎖系統(tǒng)臨時把低優(yōu)先級任務(wù)的優(yōu)先級抬高讓它更快跑完并釋放鎖這樣等待的時間窗口被大幅壓縮死鎖的溫床就變小了。**第四條路破壞循環(huán)等待。**這是工程上最實用、最好落地的一條核心就八個字給資源編號按序申請。比如項目里有三把鎖編號Lock_A 1、Lock_B 2、Lock_C 3規(guī)約要求所有任務(wù)必須嚴(yán)格按從小到大的順序申請鎖——先拿Lock_A才能去拿Lock_B絕不能先拿Lock_B再回頭要Lock_A。這樣所有任務(wù)的申請序列都是同一個偏序關(guān)系環(huán)路根本構(gòu)造不出來循環(huán)等待不攻自破。注意資源排序法對同一類資源有效如果系統(tǒng)里有多組不同類型的資源需要分別制定全局統(tǒng)一的順序。我在一個小項目里就吃過虧當(dāng)時協(xié)議棧和業(yè)務(wù)模塊各自維護(hù)了一套鎖編號兩套編號互不通氣結(jié)果一個任務(wù)先在協(xié)議棧里按協(xié)議棧的序拿了鎖又在業(yè)務(wù)模塊里按業(yè)務(wù)模塊的序去拿鎖另一個任務(wù)正好相反環(huán)形等待依然存在。后來改成全局一張編號表這個問題才斷根。4. 動態(tài)避免銀行家算法的原理與手工推演死鎖預(yù)防屬于靜態(tài)防御總是限制資源的使用方式過于保守。而死鎖避免走的是另一條路允許任務(wù)自由申請資源但在每次分配之前先做一次安全性檢查只有確認(rèn)分配后系統(tǒng)不會進(jìn)入不安全狀態(tài)才真正把資源給出去。這部分最經(jīng)典的就是銀行家算法Bankers Algorithm這也是四級考試?yán)镒羁赡艹鲇嬎泐}的知識點我建議各位一定要親手推演一遍。先解釋一下算法名字的由來。銀行家在給客戶放貸時不會一次性把所有資金都貸出去要留一部分現(xiàn)金保證其他客戶隨時取款。操作系統(tǒng)扮演的就是這個銀行家角色手里的資源就是現(xiàn)金池任務(wù)就是客戶任務(wù)聲明的最大需求就是貸款額度。安全狀態(tài)的定義是存在一個分配序列使得按照這個序列依次推進(jìn)每個任務(wù)最終都能拿到它需要的全部資源并運(yùn)行結(jié)束。這個序列就叫安全序列。算法本身分兩步。第一步是資源分配前的檢查任務(wù)T申請資源后系統(tǒng)先假裝分配給它如果分配后的剩余資源不能滿足任何任務(wù)的最大需求而不是僅僅考慮當(dāng)前申請那就不批準(zhǔn)這次分配。第二步是安全性算法就是找安全序列的流程。我拿一個簡化例子走一遍。假設(shè)系統(tǒng)里有三類資源A、B、C總量分別是(10, 5, 7)當(dāng)前有5個任務(wù)T1到T5。它們的需求矩陣如下考試和實際分析里通常這樣列表任務(wù)最大需求(A,B,C)已分配(A,B,C)還需(A,B,C)T1(7, 5, 3)(0, 1, 0)(7, 4, 3)T2(3, 2, 2)(2, 0, 0)(1, 2, 2)T3(9, 0, 2)(3, 0, 2)(6, 0, 0)T4(2, 2, 2)(2, 1, 1)(0, 1, 1)T5(4, 3, 3)(0, 0, 2)(4, 3, 1)先算可用資源向量?？傎Y源減去所有已分配資源A類10 - (02320) 3B類5 - (10010) 3C類7 - (00212) 2所以Available (3, 3, 2)。然后找還需向量里每一項都 ≤ Available的任務(wù)。T2的還需是(1, 2, 2)都不超過(3, 3, 2)滿足條件。T4還需(0, 1, 1)也滿足。實際嘗試的時候選哪個都行但為了演示規(guī)范流程我選T2先跑。先把T2標(biāo)記為可完成T2運(yùn)行結(jié)束后釋放它占用的全部資源也就是把(2, 0, 0)加回到Available(32, 30, 20) (5, 3, 2)。接著繼續(xù)尋找下一個滿足條件的任務(wù)。此時T4還需(0, 1, 1)Available是(5, 3, 2)顯然滿足。讓T4結(jié)束釋放(2, 1, 1)(52, 31, 21) (7, 4, 3)。再看T1還需(7, 4, 3)正好等于Available(7, 4, 3)滿足。T1結(jié)束后釋放(0, 1, 0)(7, 5, 3)。接著T3還需(6, 0, 0)小于(7, 5, 3)滿足。釋放(3, 0, 2)(10, 5, 5)。最后T5還需(4, 3, 1)滿足釋放(0, 0, 2)系統(tǒng)資源回到接近初始總量。這樣得到的安全序列就是T2 → T4 → T1 → T3 → T5。說明當(dāng)前系統(tǒng)處于安全狀態(tài)可以批準(zhǔn)分配。實際手算的時候有個小技巧優(yōu)先找還需資源量最小的任務(wù)先完成這樣釋放出來的資源最多后面的判斷最寬松。另外要特別注意還需 最大 - 已分配考試?yán)锝?jīng)常不直接給還需列要自己先算出來。銀行家算法的本質(zhì)是以退為進(jìn)它允許系統(tǒng)進(jìn)入一個看似資源緊張的中間狀態(tài)但保證只要有任務(wù)完成就一定存在一條出路。要注意它是在線算法每次分配請求都要跑一遍安全性檢查復(fù)雜度是O(n2×m)級別——n是任務(wù)數(shù)m是資源類型數(shù)。嵌入式系統(tǒng)里任務(wù)數(shù)量動輒幾十上百資源類型也多每次都跑全量檢查在實時性上根本扛不住。所以工業(yè)級的RTOS較少完整實現(xiàn)銀行家算法更多是基于優(yōu)先級、基于超時的啟發(fā)式策略。但考試?yán)锼騺硎侵攸c計算題原理必須吃透。5. 事后處理死鎖的檢測與現(xiàn)場恢復(fù)哪怕預(yù)防做得再好實際項目里還是會有漏網(wǎng)之魚——比如第三方庫的代碼不是你寫的你不知道它內(nèi)部鎖的申請順序再比如中斷里偶發(fā)地調(diào)用了一個可能阻塞的API正好和任務(wù)形成競爭。這時候就需要死鎖檢測機(jī)制以及檢測到死鎖后的恢復(fù)策略。嵌入式RTOS內(nèi)核里比較常見的是周期性檢測內(nèi)核維護(hù)一張資源分配表每運(yùn)行一小段時間就掃描一遍用類似資源分配圖的方法檢查是否出現(xiàn)環(huán)路。一旦檢測到死鎖處理策略通常有以下幾種直接任務(wù)終止。這是最簡單粗暴的。系統(tǒng)檢測到死鎖后從造成死鎖的任務(wù)集合里挑一個犧牲品——一般是優(yōu)先級最低的或者運(yùn)行影響最小的——直接把它的資源全部回收。壞處很明顯被終止的任務(wù)如果是跑關(guān)鍵業(yè)務(wù)的系統(tǒng)狀態(tài)可能已經(jīng)不一致了。所以很多系統(tǒng)不會真的終止任務(wù)而是強(qiáng)制釋放鎖并讓該任務(wù)從阻塞態(tài)返回錯誤碼由業(yè)務(wù)層決定怎么補(bǔ)償。資源搶占與回滾。這是相對溫和的辦法把某個任務(wù)占用的資源強(qiáng)行剝奪讓另一個等待它的任務(wù)先跑等被搶占的任務(wù)再次恢復(fù)時從檢查點checkpoint重新執(zhí)行?；貪L機(jī)制對嵌入式系統(tǒng)來說實現(xiàn)成本比較高需要額外保存任務(wù)的上下文和中間狀態(tài)所以一般只在可靠性要求極高的航空、軌交、醫(yī)療設(shè)備里才會做全套?？撮T狗兜底。這是嵌入式里最常見也最實用的最后一道防線。硬件看門狗或軟件看門狗周期性地檢查各個關(guān)鍵任務(wù)是否還在喂狗——也就是定期刷新一個時間戳。如果某個任務(wù)超過設(shè)定的時間沒刷新就說明它可能被死鎖卡住了立即觸發(fā)系統(tǒng)復(fù)位。代價是系統(tǒng)會丟失當(dāng)前運(yùn)行狀態(tài)但對很多設(shè)備來說自動重啟比永遠(yuǎn)僵死強(qiáng)得多。我在項目里見過不少產(chǎn)品就是靠看門狗把偶發(fā)的死鎖熬過去的雖然不太體面但用戶感知上是偶爾重啟一次而不是設(shè)備變磚。我在實際項目中體會最深的一點是檢測和恢復(fù)是應(yīng)急手段真正要下功夫的是讓死鎖問題能夠復(fù)現(xiàn)和定位。死鎖最惡心的地方在于時序敏感可能跑幾小時甚至幾天才出現(xiàn)一次日志又來不及打印。后面我會專門講定位技巧這里先強(qiáng)調(diào)一個原則務(wù)必在系統(tǒng)里預(yù)留一個內(nèi)核狀態(tài)導(dǎo)出接口——比如通過調(diào)試串口命令隨時可以輸出當(dāng)前每個任務(wù)的運(yùn)行狀態(tài)、等待的鎖對象、持有鎖的列表。有這份數(shù)據(jù)你才能在死鎖發(fā)生的黃金窗口內(nèi)抓住元兇。6. 嵌入式場景特有的隱性死鎖優(yōu)先級反轉(zhuǎn)與中斷上下文嵌入式系統(tǒng)的死鎖和通用操作系統(tǒng)還有個很大的區(qū)別嵌入式里除了任務(wù)之間的資源競爭還疊加了優(yōu)先級體系和中斷上下文這兩個維度會產(chǎn)生一些教科書上沒有直接寫的變體死鎖。優(yōu)先級反轉(zhuǎn)是最經(jīng)典的一個。場景是這樣的任務(wù)L優(yōu)先級最低先拿到了一把鎖正在執(zhí)行臨界區(qū)任務(wù)M優(yōu)先級高一點過來等這把鎖阻塞任務(wù)H優(yōu)先級最高它也來等這把鎖一樣阻塞。如果此時有一個中等優(yōu)先級的任務(wù)N開始運(yùn)行因為L被N搶占了CPU而遲遲不能完成臨界區(qū)釋放鎖H就要一直等N跑完、L再跑完才能拿鎖。這個結(jié)果等于讓低優(yōu)先級的L和M拖死了最高優(yōu)先級的H和死鎖高優(yōu)先級任務(wù)無法推進(jìn)的觀感幾乎一模一樣。解決思路就是前面提到的優(yōu)先級繼承或者更嚴(yán)格的優(yōu)先級天花板——直接把持鎖任務(wù)的優(yōu)先級提到所有可能申請該鎖的任務(wù)的最高優(yōu)先級。我在嵌入式OS相關(guān)課程里看到過大量真題就是考優(yōu)先級反轉(zhuǎn)的發(fā)生條件和兩種對策的區(qū)別這個概念建議結(jié)合死鎖一起記。**中斷上下文中的偽死鎖**是我在項目里踩過的一個深坑。中斷服務(wù)程序里如果調(diào)用了一個會阻塞的鎖接口——很多RTOS為了簡化接口并不在中斷里禁用這種調(diào)用——恰好主循環(huán)里的任務(wù)也持著同一把鎖在等一個更慢的硬件操作中斷就永遠(yuǎn)等不到鎖。而中斷一旦卡住整個系統(tǒng)的時基就亂了其他所有依賴中斷的服務(wù)全部癱瘓癥狀和死鎖幾乎完全一致。這種問題的根治方法只有一個中斷里絕對不能調(diào)用任何可能阻塞的內(nèi)核API。如果確實需要在中斷里和任務(wù)同步數(shù)據(jù)用非阻塞的隊列、信號量或標(biāo)志位任務(wù)側(cè)再去做實際的臨界區(qū)操作。內(nèi)存池死鎖也值得提一嘴。嵌入式系統(tǒng)里動態(tài)內(nèi)存分配通常用固定大小的內(nèi)存池如果任務(wù)A申請了兩塊內(nèi)存、任務(wù)B申請了兩塊內(nèi)存然后互相等待對方釋放內(nèi)存來湊夠自己的第三塊本質(zhì)上和互斥鎖導(dǎo)致的死鎖一模一樣。這類問題比鎖死鎖更隱蔽因為報錯往往不是卡住而是內(nèi)存分配失敗排查方向很容易帶偏。這幾類場景共同說明一件事考試?yán)镏v的經(jīng)典死鎖模型是一個基線真實系統(tǒng)的死鎖往往披著優(yōu)先級、中斷、內(nèi)存分配的外衣出現(xiàn)。你只盯著Mutex去找問題大概率會走很多彎路。7. 現(xiàn)場實戰(zhàn)死鎖問題的排查清單與工具思路講完理論和場景最后分享一套我在實際項目里反復(fù)驗證過的排查流程。死鎖問題之所以讓人崩潰就是因為它偶發(fā)、難復(fù)現(xiàn)、日志缺失。但換個角度想死鎖的本質(zhì)是資源的循環(huán)等待只要你能回答誰在等誰這個問題定位就成功了80%。**第一步固定現(xiàn)場。**發(fā)現(xiàn)系統(tǒng)疑似死鎖時先別急著復(fù)位。立刻通過調(diào)試器中斷系統(tǒng)JTAG/SWD在線調(diào)試模式下暫停內(nèi)核把當(dāng)前所有任務(wù)的PC指針和?；厮輇acktrace拉出來。PC指針會告訴你每個任務(wù)卡在哪個函數(shù)如果多個任務(wù)都卡在鎖相關(guān)的內(nèi)核函數(shù)上比如pend、acquire、interrupt disable附近死鎖嫌疑立刻上升。**第二步梳理鎖資源。**把現(xiàn)場里每個阻塞任務(wù)的等待對象列出來再看當(dāng)前每個對象的持有者是誰。我習(xí)慣畫一個表格格式很簡單但非常有效任務(wù)名當(dāng)前狀態(tài)正在等待的資源該資源持有者Task_Comm阻塞Lock_BTask_SensorTask_Sensor阻塞Lock_ATask_MainTask_Main阻塞Lock_CTask_Comm這張表只要能畫出來成一個環(huán)結(jié)論幾乎是板上釘釘?shù)摹?*第三步復(fù)盤鎖申請順序。**找到環(huán)之后回到代碼里看每個任務(wù)的鎖申請路徑。八成以上情況會發(fā)現(xiàn)某兩個任務(wù)的申請順序不一致一個任務(wù)是先拿A再拿B另一個是先拿B再拿A。把代碼改成統(tǒng)一的順序這個死鎖往往就不治而愈。這一招我用了很多年幾乎百試百靈。**第四步補(bǔ)觀測手段。**如果問題還不能復(fù)現(xiàn)就得加觀測代碼。推薦在每個鎖申請點打印日志時帶上任務(wù)名、鎖ID和當(dāng)前時間戳如果擔(dān)心日志影響實時性可以用環(huán)形日志緩沖寫出問題的前幾秒記錄都留在內(nèi)存里死鎖發(fā)生后通過調(diào)試串口導(dǎo)出。我在一個數(shù)據(jù)采集板卡上就是用這個辦法捕獲到了兩個任務(wù)在某個特定數(shù)據(jù)幀到達(dá)時幾乎同時申請對方鎖的過程問題的因果鏈瞬間就清楚了。**第五步善用RTOS自帶工具。**主流嵌入式RTOS內(nèi)核普遍提供死鎖檢測鉤子或統(tǒng)計信息比如互斥鎖等待超時計數(shù)器、任務(wù)阻塞時間統(tǒng)計。把這些數(shù)據(jù)接入到遠(yuǎn)程監(jiān)控里板子在現(xiàn)場出現(xiàn)異常人在電腦前就能看到是哪個任務(wù)長時間阻塞在哪個鎖上。這個投入回報極高強(qiáng)烈建議有時間就做上。**備考提示**四級考試的死鎖部分題型幾乎是固定的。概念題考四個必要條件畫圖題考資源分配圖和環(huán)路判斷計算題考銀行家算法找安全序列應(yīng)用題考預(yù)防措施的列舉與選擇。只要把銀行家算法的手算流程練熟——尤其是先找滿足條件的任務(wù)、釋放資源、更新Available、循環(huán)這個步驟——基本上就不會丟分。別只背結(jié)論一定要親手算上兩遍。8. 寫在最后死鎖是設(shè)計問題不是運(yùn)氣問題死鎖這東西剛接觸時空對概念感覺很簡單真到項目里又覺得運(yùn)氣太差碰上了。實際上我做過的所有死鎖案例復(fù)盤到最后都是設(shè)計階段埋下的雷要么是鎖的粒度劃分不合理要么是申請順序沒有全局規(guī)約要么是用了等所有資源都齊了再動手這種天然招死鎖的模型。它就像代碼里的內(nèi)存泄漏平時不發(fā)作一旦發(fā)作就是系統(tǒng)級的。我個人現(xiàn)在寫多任務(wù)代碼有個習(xí)慣每加一把鎖都要在代碼注釋里寫明申請順序規(guī)約凡是出現(xiàn)嵌套鎖的場景強(qiáng)制畫等待圖自檢一遍再提交。這套習(xí)慣一開始覺得繁瑣但真幫我避掉了好幾個潛在死鎖。如果你正在被死鎖折磨不妨按上面的排查清單走一遍我猜你很快就能定位到那根鎖死系統(tǒng)的環(huán)。最后留一個問題供你自查現(xiàn)在手上正在開發(fā)的系統(tǒng)里有幾個任務(wù)會嵌套持鎖它們的申請順序是一致的嗎如果現(xiàn)在不確認(rèn)等它在現(xiàn)場給你顏色看就晚了。