2. 死鎖的本質(zhì)不是bug是資源分配的“死局”先想一個(gè)生活場(chǎng)景一條很窄的單行橋上兩輛車迎面相遇誰都不肯倒車結(jié)果誰都過不去。如果兩輛車一直僵持那這條橋就徹底廢了。操作系統(tǒng)里的死鎖Deadlock就是這個(gè)味道——一組進(jìn)程線程各自占著一些資源又在等對(duì)方手里的資源而且誰都不主動(dòng)放手結(jié)果所有進(jìn)程全部卡死系統(tǒng)調(diào)度再努力也白搭。在計(jì)算機(jī)四級(jí)嵌入式考綱里死鎖是操作系統(tǒng)原理的必考核心而且這塊內(nèi)容和實(shí)際嵌入式系統(tǒng)的穩(wěn)定性關(guān)系極大。你可以把它理解成“資源分配里的死局”每個(gè)進(jìn)程都像在飯桌上搶菜但每個(gè)人的筷子都被別人拿著大家大眼瞪小眼誰也沒法繼續(xù)吃。死鎖的本質(zhì)不是程序邏輯寫錯(cuò)了雖然邏輯設(shè)計(jì)不當(dāng)往往是誘因而是“資源分配策略”和“進(jìn)程推進(jìn)順序”共同作用下的系統(tǒng)性僵局。它不同于普通的程序崩潰——崩潰至少是“有個(gè)錯(cuò)誤被逮住了”而死鎖是“所有進(jìn)程看起來都活著但沒有任何一個(gè)能繼續(xù)推進(jìn)”。這就是為什么嵌入式系統(tǒng)里死鎖問題特別讓人頭疼現(xiàn)象不是立刻崩而是系統(tǒng)“慢慢咽氣”或者干脆在某次特定運(yùn)行條件下才暴露。2.1 四個(gè)必要條件缺一不可才算死鎖判斷一個(gè)系統(tǒng)是否可能發(fā)生死鎖先看四個(gè)必要條件。這四者在嵌入式考試?yán)飵缀跏潜乇晨键c(diǎn)而且它們之間是“同時(shí)滿足”的關(guān)系不是“或”。第一個(gè)條件互斥Mutual Exclusion資源同一時(shí)刻只能被一個(gè)進(jìn)程占用。比如一個(gè)串口、一塊共享內(nèi)存、一個(gè)硬件定時(shí)器這些資源天然具有互斥性。如果資源可以無限共享那根本不會(huì)因?yàn)椤罢加谩倍a(chǎn)生等待。第二個(gè)條件持有并等待Hold and Wait進(jìn)程已經(jīng)占著一些資源又在等待別的資源。這個(gè)過程不會(huì)主動(dòng)釋放已經(jīng)拿到手的資源。典型場(chǎng)景進(jìn)程A獲得打印機(jī)又去申請(qǐng)掃描儀進(jìn)程B獲得掃描儀又去申請(qǐng)打印機(jī)。雙方都“抱著自己的不放又惦記別人的”。第三個(gè)條件不可剝奪No Preemption進(jìn)程所占資源不能被系統(tǒng)強(qiáng)行搶走只能由持有者主動(dòng)釋放。注意嵌入式實(shí)時(shí)系統(tǒng)里有些資源其實(shí)是可以被剝奪的比如通過優(yōu)先級(jí)繼承或資源重置但如果所有資源都設(shè)計(jì)成不可剝奪死鎖風(fēng)險(xiǎn)就會(huì)上升。第四個(gè)條件循環(huán)等待Circular Wait存在一個(gè)進(jìn)程等待環(huán)路P1等P2的資源P2等P3的資源P3等P1的資源形成一個(gè)閉合環(huán)。這是死鎖最直觀的“形態(tài)特征”也是我們?cè)谙到y(tǒng)設(shè)計(jì)中最容易通過資源排序來破壞的一個(gè)條件。把這四個(gè)條件記成一句話互斥、持有等待、不可剝奪、循環(huán)等待。只要打破任意一個(gè)死鎖就不可能成立。備考時(shí)遇到判斷題或分析題第一件事就是拿這四個(gè)條件去套題干場(chǎng)景。2.2 一個(gè)最小死鎖示例拿串口和DMA通道說事嵌入式系統(tǒng)里最常見的死鎖場(chǎng)景之一就是多個(gè)任務(wù)搶共享外設(shè)資源。我寫一個(gè)極簡的偽代碼示例幫你直觀感受死鎖的誕生過程// 任務(wù)1先拿串口再拿DMA通道 void task1(void) { lock(serial_port); // 步驟1獲得串口 lock(dma_channel); // 步驟2等DMA通道此時(shí)可能被任務(wù)2占著 // 使用串口DMA傳輸數(shù)據(jù) unlock(dma_channel); unlock(serial_port); } // 任務(wù)2先拿DMA通道再拿串口 void task2(void) { lock(dma_channel); // 步驟1獲得DMA通道 lock(serial_port); // 步驟2等串口此時(shí)可能被任務(wù)1占著 // 使用DMA串口接收數(shù)據(jù) unlock(serial_port); unlock(dma_channel); }如果任務(wù)1執(zhí)行完lock(serial_port)后調(diào)度器切到任務(wù)2任務(wù)2執(zhí)行完lock(dma_channel)那循環(huán)等待就形成了任務(wù)1等待DMA通道任務(wù)2等待串口誰都不松手。這個(gè)例子在真實(shí)嵌入式系統(tǒng)中很常見——特別是用多個(gè)外設(shè)做數(shù)據(jù)采集與傳輸時(shí)資源申請(qǐng)順序不一致就會(huì)埋雷。提示判斷死鎖的關(guān)鍵并不是“兩個(gè)任務(wù)都在等”而是“等待是否形成了環(huán)”。如果任務(wù)2的執(zhí)行順序調(diào)整為“先拿串口再拿DMA通道”和任務(wù)1保持一致就不會(huì)有環(huán)也就不會(huì)死鎖。這里“資源順序”就是破局的第一把鑰匙。3. 死鎖的三種解法預(yù)防、避免、檢測(cè)恢復(fù)從系統(tǒng)工程角度看處理死鎖有三種思路它們的側(cè)重點(diǎn)完全不同。嵌入式考試?yán)锝?jīng)常會(huì)把這三種思路放在一起對(duì)比考察讓你判斷某個(gè)系統(tǒng)用了哪種策略。我用一張表格快速梳理一下策略類型核心思路優(yōu)點(diǎn)缺點(diǎn)典型應(yīng)用場(chǎng)景死鎖預(yù)防Prevention從源頭破壞四個(gè)必要條件之一簡單、確定性高資源利用率偏低小型嵌入式裸機(jī)系統(tǒng)死鎖避免Avoidance動(dòng)態(tài)判斷資源分配是否安全不安全就不分配資源利用率較高需要預(yù)知進(jìn)程最大需求實(shí)現(xiàn)復(fù)雜銀行家算法為代表的通用OS死鎖檢測(cè)與恢復(fù)Detection Recovery允許死鎖發(fā)生周期性檢測(cè)并解除不限制進(jìn)程行為檢測(cè)延遲、恢復(fù)代價(jià)高大型服務(wù)器、數(shù)據(jù)庫系統(tǒng)3.1 死鎖預(yù)防從設(shè)計(jì)上絕掉后路預(yù)防的核心思想特別簡單讓四個(gè)必要條件至少一個(gè)永遠(yuǎn)不成立。具體手法如下破壞互斥條件讓資源變成“可同時(shí)共享”。但嵌入式系統(tǒng)里串口、I2C總線、Flash寫入這類資源天生就是互斥的不可能讓兩個(gè)任務(wù)同時(shí)寫同一個(gè)串口所以這個(gè)條件實(shí)際上很難破壞。這也是為什么“破壞互斥”在實(shí)際系統(tǒng)中極少被采用——資源本身的物理屬性決定了它必須互斥。破壞持有并等待條件要求進(jìn)程在運(yùn)行前一次性申請(qǐng)所有需要的資源申請(qǐng)不到就一個(gè)都不拿。這種“全有或全無”的分配方式實(shí)現(xiàn)了“不允許邊持有邊等待”但從資源利用率角度看很浪費(fèi)——任務(wù)可能只需要5%的CPU時(shí)間卻要把所有相關(guān)資源都占滿。在資源緊張的嵌入式系統(tǒng)里這種方案往往不劃算。破壞不可剝奪條件允許系統(tǒng)強(qiáng)行收回資源。這個(gè)方案在嵌入式實(shí)時(shí)系統(tǒng)里是比較實(shí)用的——當(dāng)一個(gè)高優(yōu)先級(jí)任務(wù)需要的資源被低優(yōu)先級(jí)任務(wù)占著時(shí)RTOS可以通過優(yōu)先級(jí)繼承機(jī)制或資源重置來剝奪。但注意剝奪資源可能造成數(shù)據(jù)丟失或狀態(tài)不一致比如一個(gè)正在寫Flash的進(jìn)程被強(qiáng)行打斷Flash里的數(shù)據(jù)可能就廢了。所以“破壞不可剝奪”要謹(jǐn)慎用一般只適合可重置、損失可容忍的資源。破壞循環(huán)等待條件給所有資源編號(hào)要求所有任務(wù)必須按編號(hào)從小到大申請(qǐng)資源。這是嵌入式領(lǐng)域最常用也最有效的預(yù)防手段因?yàn)樗鼜倪壿嬌献尛h(huán)路永遠(yuǎn)無法形成。只要每個(gè)任務(wù)都遵循“先拿低編號(hào)資源再拿高編號(hào)資源”那所有等待方向都是一致的不可能出現(xiàn)“P1等P2P2又等P1”的循環(huán)。我對(duì)資源編號(hào)法的評(píng)價(jià)是它簡單、可操作性強(qiáng)、對(duì)系統(tǒng)性能影響小代價(jià)是編程時(shí)需要額外遵守一套申請(qǐng)順序規(guī)范。一個(gè)典型的做法是// 定義資源編號(hào) #define RES_LOCK_SERIAL 1 // 串口鎖 #define RES_LOCK_DMA 2 // DMA通道鎖 #define RES_LOCK_SPI 3 // SPI總線鎖 #define RES_LOCK_FLASH 4 // Flash寫鎖 // 所有任務(wù)只能按編號(hào)升序申請(qǐng)資源 // 例如先申請(qǐng)串口(1)再申請(qǐng)DMA(2)最后申請(qǐng)F(tuán)lash(4) void task_capture_and_store(void) { lock(RES_LOCK_SERIAL); lock(RES_LOCK_DMA); lock(RES_LOCK_FLASH); // 執(zhí)行采集存儲(chǔ) unlock(RES_LOCK_FLASH); unlock(RES_LOCK_DMA); unlock(RES_LOCK_SERIAL); }這套方式的本質(zhì)是“把并發(fā)問題轉(zhuǎn)化為順序問題”在工程上非常香。實(shí)際嵌入式開發(fā)里很多成熟的RTOS方案比如基于信號(hào)量或互斥鎖的資源管理都會(huì)建議開發(fā)者對(duì)共享資源做編號(hào)管理目的不是別的就是防止死鎖。3.2 死鎖避免銀行家算法與安全狀態(tài)死鎖避免的代表算法就是著名的銀行家算法Bankers Algorithm。它的思路有點(diǎn)像銀行貸款審批銀行在放貸前要確認(rèn)這筆錢貸出去后系統(tǒng)里還剩下足夠的錢能讓所有客戶最多完成他們的需求。如果可以就放貸如果不可以就拒絕免得客戶最后還不上錢把銀行拖垮。對(duì)應(yīng)到操作系統(tǒng)里資源就是“錢”進(jìn)程就是“客戶”。銀行家算法要求每個(gè)進(jìn)程提前聲明自己“最多需要多少資源”Max。系統(tǒng)手里有一個(gè)“剩余資源向量”Available。每次進(jìn)程申請(qǐng)資源時(shí)系統(tǒng)做一次安全性檢查假設(shè)把這筆資源分配給你剩下的資源能否讓所有進(jìn)程都走到終點(diǎn)。如果能當(dāng)前狀態(tài)就是“安全狀態(tài)”Safe State可以分配否則就拒絕分配讓進(jìn)程等。安全性檢查算法本身不難核心就是模擬推進(jìn)找“剩余資源能滿足其最大需求”的進(jìn)程讓它執(zhí)行完畢、釋放資源然后再找下一個(gè)直到所有進(jìn)程都能完成。如果存在一個(gè)完整的安全執(zhí)行序列就說明系統(tǒng)是安全的。但在嵌入式領(lǐng)域銀行家算法的應(yīng)用非常有限原因有三個(gè)難以預(yù)知每個(gè)任務(wù)的資源最大需求。嵌入式系統(tǒng)里很多任務(wù)是動(dòng)態(tài)創(chuàng)建、動(dòng)態(tài)申請(qǐng)資源的提前聲明Max值很麻煩。檢查算法本身有一定開銷在實(shí)時(shí)性要求高的系統(tǒng)中這個(gè)開銷不可忽視。嵌入式系統(tǒng)資源種類繁多每個(gè)任務(wù)可能要鎖串口、鎖I2C、鎖DMA、鎖Flash、鎖內(nèi)存池資源矩陣規(guī)模一大更新和檢查的成本就上去了。所以我個(gè)人建議考試要會(huì)用銀行家算法做題主要是安全序列推導(dǎo)但做嵌入式工程時(shí)優(yōu)先考慮資源編號(hào)法這類預(yù)防手段。銀行家算法更適合通用操作系統(tǒng)、數(shù)據(jù)庫這類資源種類少但并發(fā)度高的場(chǎng)景。3.3 死鎖檢測(cè)與恢復(fù)事后的“救火隊(duì)”檢測(cè)與恢復(fù)策略的思路是不預(yù)防、不避免讓死鎖發(fā)生然后事后發(fā)現(xiàn)并救回來。系統(tǒng)在運(yùn)行過程中周期性檢查“當(dāng)前資源分配圖”是否存在環(huán)路如果存在環(huán)路說明有死鎖就啟動(dòng)恢復(fù)機(jī)制。環(huán)路檢測(cè)的關(guān)鍵是維護(hù)一張“資源分配圖”Resource Allocation Graph圖中包含兩類節(jié)點(diǎn)進(jìn)程節(jié)點(diǎn)和資源節(jié)點(diǎn)。當(dāng)一個(gè)進(jìn)程申請(qǐng)一個(gè)資源時(shí)畫一條從進(jìn)程指向資源的“請(qǐng)求邊”當(dāng)一個(gè)進(jìn)程占有一個(gè)資源時(shí)畫一條從資源指向進(jìn)程的“分配邊”。如果圖中存在環(huán)就說明死鎖發(fā)生了?；謴?fù)手段一般有三種直接終止一個(gè)或多個(gè)進(jìn)程簡單粗暴終止哪個(gè)進(jìn)程需要權(quán)衡犧牲優(yōu)先級(jí)最低、工作量最少的那個(gè)通常是較好的選擇。資源搶占從某個(gè)進(jìn)程手里搶走資源分配給另一個(gè)進(jìn)程但被搶的進(jìn)程需要回滾到安全點(diǎn)。這在嵌入式場(chǎng)景里實(shí)現(xiàn)成本很高因?yàn)楹芏嗤庠O(shè)根本無法“回滾”。人工介入嵌入式系統(tǒng)出現(xiàn)死鎖時(shí)很多時(shí)候只能靠看門狗Watchdog復(fù)位系統(tǒng)。這也算是一種“恢復(fù)”——代價(jià)是整個(gè)系統(tǒng)重啟實(shí)時(shí)性任務(wù)全部被打斷。說實(shí)話在嵌入式領(lǐng)域檢測(cè)與恢復(fù)策略通常是最后的底線手段不是首選。真正靠譜的系統(tǒng)設(shè)計(jì)要在“資源申請(qǐng)順序”和“鎖粒度”上下功夫盡量做到“死鎖不發(fā)生”。4. 嵌入式RTOS里的經(jīng)典死鎖場(chǎng)景互斥鎖與優(yōu)先級(jí)反轉(zhuǎn)嵌入式系統(tǒng)里用的最多的是RTOS實(shí)時(shí)操作系統(tǒng)而RTOS里死鎖問題的呈現(xiàn)方式和通用OS還不太一樣額外疊加了一個(gè)“優(yōu)先級(jí)反轉(zhuǎn)”Priority Inversion的坑。這塊內(nèi)容考試?yán)锝?jīng)常和死鎖放一起考因?yàn)樗鼈z在癥狀上很像都是任務(wù)卡住不動(dòng)。但處理方式完全不同我在這里單獨(dú)拎出來講清楚。4.1 優(yōu)先級(jí)反轉(zhuǎn)癥狀像死鎖但解法完全不同先看一個(gè)經(jīng)典場(chǎng)景系統(tǒng)有三個(gè)任務(wù)優(yōu)先級(jí)從高到低分別是T1高、T2中、T3低。T3先運(yùn)行拿到了一把互斥鎖。T1就緒搶占CPU嘗試拿同一把鎖但鎖被T3占著T1阻塞等待。T2此時(shí)就緒它不搶鎖但它的優(yōu)先級(jí)比T3高于是T2搶占CPU運(yùn)行。T3被T2搶占了CPU但還抱著鎖不放。T1還在等鎖。T2一直運(yùn)行T3一直無法推進(jìn)鎖就一直無法釋放T1就一直卡死。從表面上看這就像死鎖高優(yōu)先級(jí)任務(wù)T1在等一個(gè)永遠(yuǎn)可能等不到的鎖。但嚴(yán)格來說這不是死鎖——因?yàn)檫@里沒有“循環(huán)等待”T3并沒有在等T1的資源它只是被T2搶占導(dǎo)致無法釋放鎖。這是一種“優(yōu)先級(jí)反轉(zhuǎn)”問題。解決優(yōu)先級(jí)反轉(zhuǎn)的標(biāo)準(zhǔn)手段是優(yōu)先級(jí)繼承Priority Inheritance和優(yōu)先級(jí)天花板Priority Ceiling優(yōu)先級(jí)繼承當(dāng)高優(yōu)先級(jí)任務(wù)T1等待低優(yōu)先級(jí)任務(wù)T3持有的鎖時(shí)把T3的優(yōu)先級(jí)臨時(shí)提升到T1的級(jí)別讓T3盡快運(yùn)行、盡快釋放鎖。優(yōu)先級(jí)天花板給每把鎖設(shè)定一個(gè)“天花板優(yōu)先級(jí)”等于所有可能使用該鎖的任務(wù)的最高優(yōu)先級(jí)。任何任務(wù)拿到鎖時(shí)它的優(yōu)先級(jí)自動(dòng)升到天花板級(jí)別。這兩個(gè)機(jī)制能有效避免“中等優(yōu)先級(jí)任務(wù)長期搶占導(dǎo)致高優(yōu)先級(jí)任務(wù)餓死”的惡性現(xiàn)象。需要注意的是優(yōu)先級(jí)繼承解決的是“反轉(zhuǎn)”問題而不是死鎖。如果你的系統(tǒng)同時(shí)存在優(yōu)先級(jí)反轉(zhuǎn)和資源申請(qǐng)順序不一致那就要雙管齊下一邊用優(yōu)先級(jí)繼承/天花板一邊用資源編號(hào)法。注意考試?yán)锝?jīng)常有這種陷阱題——“系統(tǒng)中有多個(gè)任務(wù)互相等待對(duì)方持有的資源且形成了循環(huán)等待”問你這是什么問題。答案是死鎖。但如果題干改成“高優(yōu)先級(jí)任務(wù)等待低優(yōu)先級(jí)任務(wù)釋放鎖中等優(yōu)先級(jí)任務(wù)一直搶占CPU”那答案就是優(yōu)先級(jí)反轉(zhuǎn)。把這兩種現(xiàn)象的判定特征理清楚基本不會(huì)錯(cuò)。4.2 RTOS互斥鎖使用時(shí)的三個(gè)實(shí)操建議在實(shí)際嵌入式項(xiàng)目里互斥鎖Mutex的使用有幾個(gè)成熟經(jīng)驗(yàn)值得遵守建議一所有任務(wù)對(duì)同一組共享資源的加鎖順序必須一致。這是預(yù)防死鎖最核心的工程紀(jì)律。假設(shè)項(xiàng)目里有串口和Flash兩個(gè)共享資源那就規(guī)定所有任務(wù)只能“先鎖串口再鎖Flash”不允許出現(xiàn)“先Flash后串口”的寫法。代碼Review時(shí)要重點(diǎn)盯這一條。建議二鎖的持有時(shí)間盡量短。鎖的范圍越小、持有鎖的時(shí)間越短發(fā)生死鎖和性能瓶頸的概率就越低。一個(gè)常見的反面案例是有人在中斷處理里加鎖或者在長時(shí)間計(jì)算過程中一直持有鎖這些都會(huì)讓系統(tǒng)變得極其脆弱。中斷上下文里一般只做標(biāo)記或數(shù)據(jù)拷貝不要直接加鎖等待。建議三使用超時(shí)機(jī)制給鎖加上“護(hù)欄”。很多RTOS的互斥鎖API支持超時(shí)參數(shù)比如等待50ms、100ms等。給鎖等待加上超時(shí)后即使因?yàn)槟承┎豢深A(yù)知的原因真的發(fā)生了死鎖任務(wù)也不會(huì)無限期卡死而是會(huì)超時(shí)返回錯(cuò)誤碼這樣系統(tǒng)就有機(jī)會(huì)進(jìn)行恢復(fù)或上報(bào)異常。雖然超時(shí)機(jī)制并不能根除死鎖但它能把“死局”變成“可察覺、可恢復(fù)的異?！痹诠こ汤锾貏e實(shí)用。4.3 用信號(hào)量與互斥鎖的區(qū)別再看一遍死鎖嵌入式系統(tǒng)里還有一類并發(fā)原語叫信號(hào)量Semaphore。信號(hào)量分二值信號(hào)量和計(jì)數(shù)信號(hào)量兩種二值信號(hào)量和互斥鎖在用法上特別像但兩者有本質(zhì)區(qū)別互斥鎖Mutex有“所有權(quán)”概念誰加的鎖只能由誰釋放適合保護(hù)共享資源。信號(hào)量Semaphore沒有所有權(quán)概念一個(gè)任務(wù)釋放信號(hào)量另一個(gè)任務(wù)可以獲取信號(hào)量常用于任務(wù)間“事件通知”或“計(jì)數(shù)資源管理”。從死鎖風(fēng)險(xiǎn)看互斥鎖必須要關(guān)注“加鎖順序”否則死鎖概率很高信號(hào)量由于沒有所有權(quán)它更多用于“生產(chǎn)者-消費(fèi)者”模型死鎖風(fēng)險(xiǎn)相對(duì)低一些但依然存在比如兩個(gè)任務(wù)都等待對(duì)方發(fā)信號(hào)量就會(huì)形成“活鎖”式的僵局。我見過不少嵌入式開發(fā)新手在項(xiàng)目里不加區(qū)分地混用互斥鎖和信號(hào)量結(jié)果出現(xiàn)問題后很難排查。我的建議是保護(hù)共享資源優(yōu)先用互斥鎖任務(wù)間通信或事件通知優(yōu)先用信號(hào)量。這樣邏輯清晰出問題也好定位。5. 死鎖排查一個(gè)真實(shí)的嵌入式故障分析過程前面講了原理和預(yù)防手段但真實(shí)項(xiàng)目中死鎖問題往往不會(huì)在你寫完代碼的當(dāng)下就暴露出來。它通常是在某次壓力測(cè)試、某次極端時(shí)序下突然出現(xiàn)的。下面我分享一個(gè)模擬項(xiàng)目X中“系統(tǒng)間歇性卡死”的排查實(shí)錄幫你理解真實(shí)場(chǎng)景里的死鎖長什么樣。5.1 故障現(xiàn)象與初步判斷模擬項(xiàng)目X是一套基于某RTOS的嵌入式數(shù)據(jù)采集系統(tǒng)里面有4個(gè)主要任務(wù)采集任務(wù)C負(fù)責(zé)從傳感器讀取數(shù)據(jù)通過DMA搬運(yùn)到內(nèi)存然后通過串口發(fā)送。顯示任務(wù)D負(fù)責(zé)把采集到的數(shù)據(jù)在屏幕上刷新。存儲(chǔ)任務(wù)S負(fù)責(zé)把壓縮后的數(shù)據(jù)寫入外部Flash。通信任務(wù)N負(fù)責(zé)通過以太網(wǎng)口上報(bào)數(shù)據(jù)。某天測(cè)試時(shí)發(fā)現(xiàn)系統(tǒng)偶爾運(yùn)行十幾分鐘后所有任務(wù)全部停住串口不再輸出屏幕畫面定格看門狗沒有觸發(fā)板子“假死”。當(dāng)時(shí)第一反應(yīng)是“系統(tǒng)卡在死循環(huán)里了”。但用調(diào)試器掛上去一看發(fā)現(xiàn)各個(gè)任務(wù)都停在lock調(diào)用上CPU占用率卻不為零——這說明不是死循環(huán)而是多個(gè)任務(wù)在互相等待鎖。我立刻開始抓資源申請(qǐng)順序。通過調(diào)試器查看每個(gè)任務(wù)當(dāng)前持有的鎖和正在等待的鎖很快就還原出真實(shí)的死鎖鏈路任務(wù)C持有串口鎖正在等Flash寫鎖任務(wù)S持有Flash寫鎖正在等串口鎖。兩個(gè)任務(wù)互相等環(huán)形成了。這就是教科書級(jí)別的死鎖。5.2 根因分析為什么之前沒被發(fā)現(xiàn)問題根因是任務(wù)C和任務(wù)S的加鎖順序不一致。任務(wù)C的代碼路徑里是先鎖串口、再鎖Flash而任務(wù)S的代碼路徑里是先鎖Flash、再鎖串口。正常情況下兩個(gè)任務(wù)同時(shí)運(yùn)行且恰好“交錯(cuò)申請(qǐng)”的概率不高所以前期測(cè)試沒暴露。但在壓力測(cè)試中數(shù)據(jù)量增大任務(wù)C和任務(wù)S并發(fā)執(zhí)行的頻率大幅提升死鎖觸發(fā)概率就上來了。這也解釋了為什么死鎖問題最怕“偶現(xiàn)”——它和時(shí)間、負(fù)載強(qiáng)相關(guān)單次功能測(cè)試往往覆蓋不到。我們?cè)诖aReview階段沒有嚴(yán)格要求“全局統(tǒng)一資源編號(hào)”所以在設(shè)計(jì)階段就埋下了隱患。5.3 解決方案與經(jīng)驗(yàn)沉淀我當(dāng)時(shí)的修復(fù)方案很簡單但很有效給共享資源定義全局編號(hào)規(guī)定任務(wù)C和任務(wù)S都必須按“串口鎖 - Flash寫鎖”的順序申請(qǐng)。改完代碼后壓力測(cè)試連續(xù)跑48小時(shí)死鎖再?zèng)]復(fù)現(xiàn)。從這個(gè)案例里我總結(jié)出三條嵌入式死鎖排查經(jīng)驗(yàn)經(jīng)驗(yàn)一用調(diào)試器看任務(wù)棧和鎖狀態(tài)準(zhǔn)確定位環(huán)。不要靠猜。先在調(diào)試環(huán)境里掛到目標(biāo)板上查看每個(gè)任務(wù)的“持有鎖列表”和“等待鎖列表”還原出完整的資源申請(qǐng)圖。只要發(fā)現(xiàn)環(huán)就百分之百是死鎖。經(jīng)驗(yàn)二代碼Review階段就要檢查和統(tǒng)一加鎖順序。很多死鎖問題是“設(shè)計(jì)階段不統(tǒng)一、寫代碼時(shí)各寫各的”造成的。如果項(xiàng)目里有多個(gè)人并行開發(fā)一定要在資源鎖的使用規(guī)范上達(dá)成一致最好寫在編碼規(guī)范里。經(jīng)驗(yàn)三引入“鎖超時(shí)”作為源碼級(jí)保護(hù)。給所有l(wèi)ock調(diào)用加上超時(shí)參數(shù)一旦超時(shí)就記錄日志并嘗試恢復(fù)。這樣即使預(yù)防措施沒到位問題也能被快速定位不至于在現(xiàn)場(chǎng)“假死”時(shí)無從下手。另外補(bǔ)充一點(diǎn)在嵌入式系統(tǒng)里死鎖伴隨的常見癥狀往往是“任務(wù)無響應(yīng)、看門狗未觸發(fā)”。很多人看到這種現(xiàn)象會(huì)先懷疑中斷或任務(wù)優(yōu)先級(jí)配置但如果你能在調(diào)試器里看到多個(gè)任務(wù)卡在lock上那基本可以直接鎖定死鎖方向。6. 死鎖考點(diǎn)拆解與備考做題技巧最后這部分專門服務(wù)備考計(jì)算機(jī)四級(jí)嵌入式的同學(xué)。死鎖在考綱里屬于“操作系統(tǒng)原理”的難點(diǎn)模塊出題形式以選擇、判斷、簡答為主偶爾會(huì)有“安全性分析”類的大題。我結(jié)合真題風(fēng)格梳理了幾個(gè)高頻考點(diǎn)和做題技巧。6.1 高頻考點(diǎn)清單考點(diǎn)一死鎖的四個(gè)必要條件。題目通常是“以下哪個(gè)條件不是死鎖的必要條件”或者“下列哪種情況不屬于死鎖的四個(gè)必要條件之一”。這類題的干擾項(xiàng)很喜歡設(shè)置“饑餓”“活鎖”“優(yōu)先級(jí)反轉(zhuǎn)”等概念你需要把死鎖和這些相鄰概念嚴(yán)格區(qū)分開。考點(diǎn)二死鎖預(yù)防的四種方法。核心是每種方法破壞哪個(gè)條件。比如“資源一次性申請(qǐng)”對(duì)應(yīng)破壞“持有并等待”“資源編號(hào)排序法”對(duì)應(yīng)破壞“循環(huán)等待”“允許搶占”對(duì)應(yīng)破壞“不可剝奪”?？键c(diǎn)三銀行家算法的安全序列推導(dǎo)。給你一張進(jìn)程-資源需求表讓你判斷系統(tǒng)是否安全以及求一個(gè)安全執(zhí)行序列。這類題目看起來復(fù)雜但只要有固定的解題套路模擬分配并反復(fù)掃描就能穩(wěn)定拿分?？键c(diǎn)四資源分配圖與死鎖判斷。給一張資源分配圖問是否存在死鎖。判斷方法是找環(huán)資源分配圖里有環(huán)且有向環(huán)上每類資源數(shù)量都滿足“占滿”條件那死鎖成立。要注意的是一般圖論里有環(huán)還不一定死鎖比如資源數(shù)量大于1時(shí)環(huán)內(nèi)某個(gè)資源還有盈余要結(jié)合“資源實(shí)例數(shù)量”仔細(xì)看?？键c(diǎn)五死鎖與饑餓、活鎖的區(qū)別。死鎖是“永久相互等待”饑餓是“進(jìn)程長期得不到資源但系統(tǒng)還在推進(jìn)”活鎖是“進(jìn)程狀態(tài)在變化但就是無法實(shí)現(xiàn)真正的推進(jìn)”。三者極易混淆做題時(shí)要把定義咬準(zhǔn)。6.2 銀行家算法做題步驟完整示例我用一個(gè)小數(shù)據(jù)量的例子演示一遍標(biāo)準(zhǔn)解法假設(shè)系統(tǒng)有3類資源A、B、C總量分別是10, 5, 7。當(dāng)前系統(tǒng)里有如下5個(gè)進(jìn)程它們的最大需求Max、已分配Allocation、剩余需求量Need如下進(jìn)程Max (A,B,C)Allocation (A,B,C)Need (A,B,C) Max - AllocationP0(7, 5, 3)(0, 1, 0)(7, 4, 3)P1(3, 2, 2)(2, 0, 0)(1, 2, 2)P2(9, 0, 2)(3, 0, 2)(6, 0, 0)P3(2, 2, 2)(2, 1, 1)(0, 1, 1)P4(4, 3, 3)(0, 0, 2)(4, 3, 1)當(dāng)前分配總量A類023207B類100102C類002125。 剩余資源向量Available 總資源量 - 當(dāng)前分配總量 (10-7, 5-2, 7-5) (3, 3, 2)。接下來找一個(gè)能“滿足Need且不超過Available”的進(jìn)程P0需要(7,4,3)Available是(3,3,2)不夠跳過。P1需要(1,2,2)Available是(3,3,2)夠。讓P1執(zhí)行完畢釋放它的Allocation2,0,0Available變?yōu)?32, 30, 20)(5,3,2)。繼續(xù)找P3需要(0,1,1)Available(5,3,2)夠。讓P3執(zhí)行完釋放(2,1,1)Available變?yōu)?7,4,3)。再找P4需要(4,3,1)Available(7,4,3)夠。讓P4執(zhí)行完釋放(0,0,2)Available變?yōu)?7,4,5)。再找P0需要(7,4,3)Available(7,4,5)夠。讓P0執(zhí)行完釋放Allocation(0,1,0)Available變?yōu)?7,5,5)。最后P2需要(6,0,0)Available(7,5,5)夠。全部進(jìn)程都能完成。安全序列之一是P1 - P3 - P4 - P0 - P2。做題時(shí)只要按這個(gè)流程走基本不會(huì)失分。關(guān)鍵點(diǎn)是每次模擬執(zhí)行完一個(gè)進(jìn)程后Available要加上它的Allocation然后再找下一個(gè)可以執(zhí)行的進(jìn)程。不要搞混“Need”和“Allocation”——釋放資源時(shí)釋放的是Allocation不是Need。6.3 考場(chǎng)上容易踩的三個(gè)坑坑一分不清“死鎖”和“不安全狀態(tài)”。不安全狀態(tài)是“可能發(fā)生死鎖”并不是“一定發(fā)生死鎖”。銀行家算法拒絕的資源請(qǐng)求會(huì)使系統(tǒng)進(jìn)入不安全狀態(tài)但拒絕它之后系統(tǒng)依然是安全的。做題時(shí)要注意安全狀態(tài)一定不會(huì)死鎖但不安全狀態(tài)不一定立刻死鎖。坑二把“循環(huán)等待”當(dāng)成死鎖的充分條件。資源分配圖里有環(huán)不一定死鎖例如環(huán)內(nèi)的某類資源還有空閑實(shí)例但四個(gè)必要條件全滿足時(shí)就一定死鎖?？荚?yán)锵矚g用“有環(huán)死鎖”這種不嚴(yán)謹(jǐn)說法當(dāng)干擾項(xiàng)?？尤梆囸I”和“死鎖”混為一談。饑餓的進(jìn)程并沒有形成循環(huán)等待只是某個(gè)進(jìn)程一直得不到資源。比如低優(yōu)先級(jí)任務(wù)長期被高優(yōu)先級(jí)任務(wù)搶占就是一種饑餓但它不是死鎖。判斷時(shí)先看“有沒有環(huán)”。7. 最后的實(shí)戰(zhàn)建議死鎖防治要在“設(shè)計(jì)階段”下手回頭看這篇文章你會(huì)發(fā)現(xiàn)死鎖問題的本質(zhì)在于“并發(fā)資源分配”這個(gè)系統(tǒng)設(shè)計(jì)問題而不是簡單的編碼錯(cuò)誤。它決定了你的系統(tǒng)在極端負(fù)載下是穩(wěn)定運(yùn)行還是突然假死。我個(gè)人在嵌入式項(xiàng)目里的體會(huì)是死鎖防治要前置到架構(gòu)設(shè)計(jì)階段而不是等出了問題再靠檢測(cè)和恢復(fù)兜底。具體來說可以在項(xiàng)目啟動(dòng)時(shí)就做這幾件事第一梳理所有共享資源和它們的使用者做一張“資源-任務(wù)矩陣”。哪個(gè)任務(wù)會(huì)用到哪些資源、什么順序申請(qǐng)全部畫出來。只要在矩陣?yán)锇l(fā)現(xiàn)“加鎖順序有交叉”的跡象立刻調(diào)整設(shè)計(jì)。第二寫編碼規(guī)范時(shí)明確資源申請(qǐng)順序和鎖使用邊界。特別是多人協(xié)作的項(xiàng)目如果每個(gè)人都有自己的加鎖習(xí)慣死鎖風(fēng)險(xiǎn)會(huì)成倍增加。規(guī)范里可以強(qiáng)制要求所有互斥鎖申請(qǐng)必須按資源編號(hào)升序進(jìn)行如果確實(shí)需要反序申請(qǐng)必須走評(píng)審流程。第三在系統(tǒng)聯(lián)調(diào)階段加入“鎖等待超時(shí)監(jiān)控”和“周期性狀態(tài)快照”。給每個(gè)任務(wù)增加一個(gè)“當(dāng)前等待鎖”的狀態(tài)變量在調(diào)試打印里定期輸出。一旦出現(xiàn)異常等待超過閾值日志里就能直接看到“哪個(gè)任務(wù)在等哪把鎖”排查效率會(huì)提升一個(gè)數(shù)量級(jí)。第四最后再分享一個(gè)小技巧如果實(shí)在沒辦法給所有鎖加超時(shí)那么在代碼里加一個(gè)“看門狗喂狗注釋約定”——凡是持有鎖超過約定時(shí)間的代碼路徑都要在注釋里寫明原因。這樣未來排查時(shí)可以直接通過日志和代碼注釋快速縮小范圍。死鎖防治不是一個(gè)高深的理論問題而是一個(gè)非常依賴工程紀(jì)律和前置設(shè)計(jì)的實(shí)踐問題。把這篇文章里提到的“四個(gè)必要條件”“資源編號(hào)法”“鎖超時(shí)”“調(diào)試定位”結(jié)合起來你的嵌入式系統(tǒng)就會(huì)穩(wěn)很多?？荚噷用姘雁y行家算法的做題步驟練熟把死鎖與饑餓、優(yōu)先級(jí)反轉(zhuǎn)的區(qū)分邊界理清這塊分?jǐn)?shù)基本就能穩(wěn)拿。