干實(shí)時(shí)采集系統(tǒng)這行的大概都經(jīng)歷過這樣的至暗時(shí)刻界面上數(shù)據(jù)突然不刷新了進(jìn)程管理器里 CPU 穩(wěn)穩(wěn)地頂在 100%點(diǎn)哪里都沒反應(yīng)最后只能粗暴地殺掉進(jìn)程重啟。如果運(yùn)氣不好連“保存現(xiàn)場(chǎng)”的機(jī)會(huì)都沒有緩沖區(qū)里攢了幾個(gè)小時(shí)的數(shù)據(jù)直接歸零。這種一出現(xiàn)就是卡死、CPU 打滿、必須重啟的問題絕大多數(shù)時(shí)候和業(yè)務(wù)邏輯一點(diǎn)關(guān)系都沒有問題出在程序自身——多線程之間互相掐架誰也不讓誰最后誰也沒法往前挪半步。這就是死鎖Deadlock一個(gè)在并發(fā)編程里談之色變、在多線程實(shí)時(shí)采集系統(tǒng)里最隱蔽也最致命的 Bug。這篇內(nèi)容我打算從根上講透死鎖它到底怎么形成的為什么在實(shí)時(shí)采集系統(tǒng)里特別容易中招遇到 CPU 100% 之后怎么一步步定位以及最后怎么從架構(gòu)和代碼習(xí)慣上把它杜絕掉。不管你是寫 C、Java、C#、Python還是 Delphi今天就拿自己踩過的坑把這件事掰開揉碎了說清楚。1. 先搞清楚死鎖的本質(zhì)不是“鎖壞了”是人堵死了1.1 死鎖的形成需要四個(gè)條件缺一不可死鎖本質(zhì)上是一組線程在等待一個(gè)永遠(yuǎn)不可能被釋放的資源。教科書上總結(jié)為四個(gè)必要條件互斥、持有并等待、不可剝奪、循環(huán)等待。這四句話聽起來很繞但拿現(xiàn)實(shí)生活一比對(duì)就清楚了。想象一個(gè)只有一條車道的窄橋兩邊各來一輛車誰都想先過橋誰也不肯倒車。橋是互斥資源只能一方使用兩車都占著各自的路口不肯退讓持有并等待沒有交警來強(qiáng)制拖走任何一輛不可剝奪于是兩車頭對(duì)頭堵死循環(huán)等待。這四個(gè)條件只要同時(shí)成立系統(tǒng)就卡在這兒了而且永遠(yuǎn)自行解不開只能外部干預(yù)——強(qiáng)制重啟。放到多線程代碼里“車”就是線程“窄橋”就是被鎖保護(hù)的共享數(shù)據(jù)區(qū)。線程 A 持有一把鎖 L1想去拿 L2與此同時(shí)線程 B 持有 L2正排隊(duì)等著 L1。兩邊都認(rèn)為對(duì)方“應(yīng)該先放手”結(jié)果誰都不放手。這就是最經(jīng)典的 ABBA 死鎖A 等 BB 等 A雙方懷里都抱著對(duì)方想要的東西。要注意死鎖不是“程序錯(cuò)了才出現(xiàn)”的恰恰相反絕大部分死鎖代碼在語(yǔ)法上完全正確編譯和單線程運(yùn)行都毫無問題。死鎖是運(yùn)行時(shí)在多線程時(shí)序配合下才會(huì)觸發(fā)的“偶發(fā)炸彈”所以它遠(yuǎn)比普通空指針、數(shù)組越界更難發(fā)現(xiàn)和復(fù)現(xiàn)。1.2 多線程實(shí)時(shí)采集系統(tǒng)為什么是死鎖高發(fā)區(qū)理解了四個(gè)條件再看實(shí)時(shí)采集系統(tǒng)這個(gè)具體場(chǎng)景就會(huì)發(fā)現(xiàn)它幾乎把死鎖的土壤填滿了。實(shí)時(shí)采集系統(tǒng)的基本模型是采集設(shè)備采集卡、傳感器、相機(jī)、串口數(shù)據(jù)不斷地產(chǎn)生原始數(shù)據(jù)流一個(gè)或多個(gè)采集線程高速讀取并寫入共享緩沖區(qū)業(yè)務(wù)處理線程從緩沖區(qū)取數(shù)據(jù)做解析、存儲(chǔ)、顯示或轉(zhuǎn)發(fā)。這個(gè)模型天然就是多線程的——數(shù)據(jù)生產(chǎn)端和數(shù)據(jù)消費(fèi)端速率不匹配中間必須有一個(gè)線程安全的數(shù)據(jù)通道。于是鎖、信號(hào)量、條件變量、消息隊(duì)列這些同步原語(yǔ)一個(gè)都不能少代碼里隨處可見CriticalSection、mutex、synchronized、lock關(guān)鍵字。更要命的還有兩點(diǎn)。第一實(shí)時(shí)性要求高。采集系統(tǒng)里的數(shù)據(jù)是有“保鮮期”的比如音頻 20 毫秒一幀、高頻信號(hào)每秒幾萬點(diǎn)、視頻流一秒鐘幾十幀。線程必須在極短的時(shí)間內(nèi)完成讀寫和交接開發(fā)者為了“快”經(jīng)常在鎖里面做本來不該做的事或者為了省一次拷貝把鎖的粒度拉得很大。鎖的粒度越大持鎖時(shí)間越長(zhǎng)其他線程等待的概率就越高互相鎖死的窗口就越大。第二線程數(shù)量多而且角色不均。采集線程、解析線程、界面刷新線程、日志落盤線程、網(wǎng)絡(luò)轉(zhuǎn)發(fā)線程各自持有不同的鎖。線程多了鎖的獲取順序稍微不一致循環(huán)等待的條件立刻出現(xiàn)。這不是理論推演而是我實(shí)際排查過的絕大多數(shù)案例的真實(shí)路徑。2. 實(shí)戰(zhàn)里死鎖最容易長(zhǎng)在哪些地方2.1 鎖順序不一致最經(jīng)典的 ABBA 死鎖拿 C 寫一段最典型的錯(cuò)誤示范基本是所有死鎖排障的起點(diǎn)。假設(shè)系統(tǒng)里有全局的幀緩沖區(qū)frame_buf和狀態(tài)表status_map兩者各有自己的鎖。線程 A 做數(shù)據(jù)解析習(xí)慣先鎖frame_buf再鎖status_map線程 B 做界面刷新不小心把順序?qū)懛戳讼孺istatus_map再鎖frame_buf。// 線程 A采集解析 void parse_frame(Frame* f) { lock(mutex_frame); // 處理幀數(shù)據(jù)... lock(mutex_status); // 更新狀態(tài)... unlock(mutex_status); unlock(mutex_frame); } // 線程 B界面刷新 void ui_refresh() { lock(mutex_status); // 這里順序反了 // 讀取狀態(tài)快照... lock(mutex_frame); // 等待 frame 鎖 // 復(fù)制幀數(shù)據(jù)... unlock(mutex_frame); unlock(mutex_status); }只要時(shí)序湊巧線程 A 拿到frame_buf鎖、正在等status_map鎖而線程 B 恰好拿著status_map鎖、正在等frame_buf鎖死鎖就成立了。兩邊都卡在鎖等待函數(shù)里不出來CPU 立刻被占滿。這個(gè)模式在單看每一段代碼的時(shí)候幾乎發(fā)現(xiàn)不了問題因?yàn)閮蓚€(gè)線程各自看上去都是“先拿一個(gè)、再用另一個(gè)”邏輯很順。只有把所有線程的加鎖路徑全部羅列出來、畫成一張圖才能看出交叉。這條經(jīng)驗(yàn)我后來一直用于代碼評(píng)審一個(gè)工程里所有涉及多把鎖的路徑必須按統(tǒng)一全局順序加鎖沒有例外。2.2 持鎖調(diào)用回調(diào)函數(shù)鎖里的定時(shí)炸彈比 ABBA 更隱蔽的是“在持鎖的狀態(tài)下調(diào)用了一個(gè)你不知道會(huì)干嘛的函數(shù)”。采集系統(tǒng)里特別常見采集線程在拿到緩沖區(qū)鎖之后為了節(jié)省一次遍歷直接在鎖里調(diào)用了數(shù)據(jù)回調(diào)callback讓上位機(jī)的用戶代碼來處理這一幀數(shù)據(jù)。用戶的回調(diào)里如果又訪問了別的鎖、調(diào)用了 UI 同步函數(shù)、或者干脆向采集線程發(fā)送了一個(gè)同步消息那死鎖就可能在幾十毫秒內(nèi)形成。我印象很深的一次故障就是這樣采集驅(qū)動(dòng)給上層拋事件的線程和上層業(yè)務(wù)處理線程共享一把鎖驅(qū)動(dòng)線程持鎖后調(diào)用回調(diào)回調(diào)里為了防止界面撕裂又調(diào)用了同步 UI 刷新函數(shù)而 UI 刷新線程正在等一下一個(gè)數(shù)據(jù)幀的資源。最后的結(jié)果是采集線程等 UI 線程UI 線程等采集線程系統(tǒng)整體凝固。這個(gè)問題的根源是“未知代碼在持鎖狀態(tài)下被允許任意執(zhí)行”。鎖保護(hù)的應(yīng)該是“對(duì)資源的訪問”而不是“對(duì)資源的訪問之外再串聯(lián)一堆業(yè)務(wù)動(dòng)作”。正確做法是把回調(diào)從鎖內(nèi)挪出去在鎖內(nèi)只拷貝必要數(shù)據(jù)、做好關(guān)鍵標(biāo)記出鎖之后再調(diào)用回調(diào)或者直接把回調(diào)投遞到獨(dú)立的事件隊(duì)列里讓接收線程自行處理。2.3 信號(hào)量和條件變量被誤用的同步原語(yǔ)鎖之外信號(hào)量Semaphore和條件變量Condition Variable也是死鎖的?？投疫@種死鎖“長(zhǎng)得”跟經(jīng)典 ABBA 不一樣更像是一邊在等“永遠(yuǎn)等不來的通知”。典型翻車現(xiàn)場(chǎng)是信號(hào)量的計(jì)數(shù)被透支。比如生產(chǎn)者線程和消費(fèi)者線程之間用信號(hào)量做任務(wù)計(jì)數(shù)生產(chǎn)者每次入隊(duì)sem.post()消費(fèi)者每次出隊(duì)sem.wait()。看起來是標(biāo)準(zhǔn)的計(jì)數(shù)模型但如果某處異常路徑漏了post或者一個(gè)post被兩個(gè)wait同時(shí)消費(fèi)掉計(jì)數(shù)就會(huì)歸零所有消費(fèi)者線程全部阻塞在wait上而生產(chǎn)者因?yàn)榫彌_區(qū)滿了也阻塞在入隊(duì)鎖上。從外部看整個(gè)系統(tǒng)同樣表現(xiàn)為 CPU 100% 和卡死。條件變量則有一個(gè)更隱蔽的坑通知丟失。條件變量的正確用法是“先加鎖檢查條件條件不滿足就 wait 釋放鎖被通知后再重新檢查條件”。但很多初學(xué)者圖省事在沒持鎖的情況下直接調(diào)用 signal或者在 wait 返回之后不重新檢查條件。前者導(dǎo)致通知在其他線程 wait 之前就發(fā)出去了后者導(dǎo)致線程醒過來時(shí)條件依然不成立于是繼續(xù)阻塞造成“假死鎖”。對(duì)于這些同步原語(yǔ)我的建議是能少用就少用能用鎖解決的就別整信號(hào)量。信號(hào)量和條件變量適合做復(fù)雜的調(diào)度模型不適合做“我今天先簡(jiǎn)單用一下”的場(chǎng)景一旦用錯(cuò)排查成本會(huì)成倍上升。2.4 Delphi 多線程里的“自家坑”熱詞里單獨(dú)列了 Delphi 多線程說明這地方確實(shí)水深。Delphi 的老項(xiàng)目在工控和采集領(lǐng)域存量很大很多人手上還捧著多年前的代碼在維護(hù)死鎖問題尤其突出。Delphi 里最常見的死鎖組合是TThread.Synchronize配合臨界區(qū)。Synchronize會(huì)把代碼調(diào)度到主線程執(zhí)行如果主線程正在等待某個(gè)后臺(tái)線程釋放臨界區(qū)而后臺(tái)線程又在Synchronize里等待主線程來執(zhí)行同步過程那兩邊就徹底對(duì)上了。特別是主線程在Application.Run的消息循環(huán)里如果消息循環(huán)被一個(gè)耗時(shí)的鎖等待阻塞Synchronize永遠(yuǎn)不會(huì)被執(zhí)行后臺(tái)線程永遠(yuǎn)等不到結(jié)果。另外 Delphi 的TMonitor是可重入的很多人以為“鎖是同一個(gè)線程可以重復(fù)進(jìn)的”于是套了兩層TMonitor.Enter以為沒事結(jié)果第二層是在另一個(gè)線程的上下文里進(jìn)入的照樣死鎖。再加上 Delphi 里老的TCriticalSection沒有超時(shí)機(jī)制一旦鎖上就無限等連自愈的機(jī)會(huì)都沒有。關(guān)于 Delphi 的實(shí)操建議能不用Synchronize就別用優(yōu)先用TThread.Queue異步投遞所有鎖等待盡量放在線程內(nèi)部循環(huán)里不要放進(jìn)主線程消息路徑老代碼里大量while not Terminated的輪詢邏輯檢查一下輪詢循環(huán)里是否持鎖等待。3. CPU 100% 之后現(xiàn)場(chǎng)排查實(shí)錄3.1 先判斷是死鎖還是忙等Busy Wait遇到 CPU 100%第一件事別慌。死鎖導(dǎo)致的 100% 和忙等導(dǎo)致的 100%處理方法完全不同必須先分清楚。忙等是線程“假裝在工作”在鎖等待循環(huán)里沒有真正掛起而是反復(fù)嘗試獲取鎖、空轉(zhuǎn)消耗 CPU。死鎖更無語(yǔ)線程明明已經(jīng)放棄執(zhí)行、永久阻塞了為什么 CPU 還是 100%因?yàn)殡m然業(yè)務(wù)線程全堵死了但系統(tǒng)的某些清理線程、看門狗線程、或者采集硬件的中斷回調(diào)還在瘋狂重試任務(wù)管理器看到的是整個(gè)進(jìn)程的總 CPU 占用只要有一個(gè)線程在瘋轉(zhuǎn)CPU 就是滿的。判斷手段很直接用 Visual Studio、WinDbg、Delphi 的 IDE 調(diào)試器或者jstackJava分別抓一下各個(gè)線程的調(diào)用棧。如果能看到多個(gè)線程互相等待對(duì)方的鎖棧上有WaitForSingleObject、lock、synchronized等字樣基本可以鎖定死鎖如果看到某個(gè)線程在無限循環(huán)重試則是忙等或者“活鎖”。一個(gè)更快的現(xiàn)場(chǎng)判斷死鎖之后進(jìn)程往往是“完全靜止”的任務(wù)管理器里線程數(shù)量不變但所有線程狀態(tài)都是“不運(yùn)行”忙等則 CPU 占用率有波動(dòng)任務(wù)管理器里能看到個(gè)別線程狀態(tài)閃爍。3.2 抓線程?？唇徊娴却ㄎ凰梨i最有效的手段就是抓取全線程調(diào)用棧。這一步無論什么語(yǔ)言都適用核心思路是“把每個(gè)線程在哪棵樹上吊著”全部拍下來。Windows 上可以用 WinDbg 附加到掛死的進(jìn)程執(zhí)行~* k命令打印所有線程棧然后在輸出里找“等待鎖 A同時(shí)持有鎖 B”這種成對(duì)出現(xiàn)的特征。Java 里直接jstack -l pidjstack會(huì)直接檢測(cè)死鎖輸出“Found one Java-level deadlock”的提示。C 在 Linux 上可以用gdb attach然后thread apply all bt再把所有線程棧里出現(xiàn)的鎖地址梳理一下看看鎖的持有者是否就是等待者。拿個(gè)具體例子說某回排查一個(gè)工業(yè)視覺采集程序抓完棧之后發(fā)現(xiàn)采集線程停在cv::waitKey的 GUI 調(diào)度器上而主線程停在相機(jī) SDK 的采集回調(diào)等待上兩個(gè)線程都握著對(duì)方需要的句柄不放。這類交叉只要把棧一對(duì)就清清楚楚不需要猜。抓棧這個(gè)動(dòng)作最好能做成自動(dòng)化的啟動(dòng)時(shí)就掛一個(gè)熱鍵或者遠(yuǎn)程指令通道卡死之后一鍵生成全棧快照。沒有這個(gè)機(jī)制的死鎖排查每次都要靠調(diào)試器手動(dòng)附加上去在現(xiàn)場(chǎng)環(huán)境里經(jīng)常來不及。3.3 二分法禁用模塊縮小懷疑范圍如果抓棧受限于現(xiàn)場(chǎng)環(huán)境或者抓出來的棧信息不夠全常見于生產(chǎn)環(huán)境不帶調(diào)試符號(hào)的情況那就用工程手段二分法。把系統(tǒng)里的可選功能模塊逐個(gè)關(guān)掉每關(guān)掉一批就嘗試復(fù)現(xiàn)或觀察卡死是否消失。比如先把日志模塊關(guān)掉試試再把界面刷新關(guān)掉試試再把某一路數(shù)據(jù)轉(zhuǎn)發(fā)關(guān)掉試試。每次只調(diào)整一個(gè)維度卡死不再出現(xiàn)那就說明嫌疑集中在這個(gè)模塊的代碼路徑上。這個(gè)方法看著笨但在沒有源碼級(jí)調(diào)試信息的現(xiàn)場(chǎng)特別管用。有一個(gè)注意事項(xiàng)實(shí)時(shí)采集系統(tǒng)的偶發(fā)死鎖往往不是穩(wěn)定復(fù)現(xiàn)的關(guān)掉模塊后“一兩天沒復(fù)現(xiàn)”并不代表真解決了。我的習(xí)慣是每個(gè)配置組合至少跑滿 24 小時(shí)并且記錄每次卡死時(shí)哪些模塊是開啟狀態(tài)用一張矩陣表把“模塊組合 vs 是否卡死”對(duì)照起來逐步逼近真兇。3.4 日志先行給系統(tǒng)裝一個(gè)看門狗哨兵很多長(zhǎng)期無法復(fù)現(xiàn)的死鎖最后都是靠日志揪出來的。日志的關(guān)鍵不是記業(yè)務(wù)數(shù)據(jù)而是記錄“線程在鎖上的等待超時(shí)記錄”。具體做法是在每個(gè)鎖的等待處包一層帶超時(shí)的封裝函數(shù)比如封裝TryEnterCriticalSectionWithTimeout超過比如 3 秒還沒有拿到鎖就主動(dòng)打印一條告警日志內(nèi)容包括當(dāng)前線程、等待的鎖地址、調(diào)用棧。這條日志不需要頻繁觸發(fā)但一旦觸發(fā)十有八九是死鎖的前兆。更進(jìn)一步可以設(shè)計(jì)一個(gè)獨(dú)立的“看門狗線程”每 1~2 秒去檢查各個(gè)工作線程的心跳標(biāo)記心跳超時(shí)就 dump 所有線程棧并寫入本地文件。這個(gè)方案我用了很多年幾乎每次都能在死鎖發(fā)生后拿到完整的“案發(fā)”現(xiàn)場(chǎng)定位效率提升了一個(gè)量級(jí)。3.5 無法復(fù)現(xiàn)的 Bug怎么破標(biāo)題里“最隱蔽”三個(gè)字對(duì)應(yīng)到現(xiàn)實(shí)就是死鎖不是天天出現(xiàn)可能在系統(tǒng)運(yùn)行幾天后的某個(gè)凌晨出現(xiàn)一次殺進(jìn)程重啟后一切復(fù)原然后好幾天不再犯。這種“幽靈死鎖”最折磨人。對(duì)付無法復(fù)現(xiàn)的問題核心思路是“下次出現(xiàn)時(shí)留下足夠信息”。沒有現(xiàn)場(chǎng)證據(jù)再怎么猜都只是猜測(cè)。所以基礎(chǔ)工作必須做在前面部署試試看前面說的看門狗心跳、鎖超時(shí)日志、全線程棧轉(zhuǎn)儲(chǔ)并且轉(zhuǎn)儲(chǔ)文件要自動(dòng)保留多份覆蓋舊文件而不是就保留最新一份。很多問題不是沒出現(xiàn)而是出現(xiàn)的時(shí)候現(xiàn)場(chǎng)早被覆蓋了。另外可以嘗試壓力測(cè)試復(fù)現(xiàn)把采集頻率調(diào)到最高、緩沖區(qū)調(diào)小、界面刷新加速線程間的競(jìng)爭(zhēng)概率會(huì)被放大幾十倍。死鎖是概率問題人為增大競(jìng)爭(zhēng)窗口、延長(zhǎng)運(yùn)行時(shí)間是提高復(fù)現(xiàn)概率最現(xiàn)實(shí)的手段。4. 怎么解怎么防從代碼習(xí)慣到架構(gòu)設(shè)計(jì)4.1 全局統(tǒng)一加鎖順序消除循環(huán)等待既然循環(huán)等待是四條件里唯一“能靠設(shè)計(jì)消除”的那第一道防線就是所有多鎖路徑必須按同一順序。給系統(tǒng)里所有鎖排一個(gè)全局編號(hào)任何時(shí)候都只能從小到大加鎖。還是用上面 A/B 的例子無論線程是誰永遠(yuǎn)先鎖frame_buf再鎖status_map不按這個(gè)順序加的代碼直接就是代碼評(píng)審的一票否決項(xiàng)。這里有個(gè)容易忽略的點(diǎn)同一個(gè)函數(shù)的加鎖順序容易統(tǒng)一跨函數(shù)調(diào)用時(shí)順序容易亂。所以不僅要靠人肉評(píng)審最好引入靜態(tài)檢查工具。比如 C 的clang靜態(tài)分析、Java 的 SpotBugs 死鎖檢測(cè)、Python 的 lock 順序檢查邏輯都可以自動(dòng)化跑一遍。4.2 縮小鎖粒度優(yōu)先無鎖設(shè)計(jì)鎖的粒度越大持鎖時(shí)間越長(zhǎng)沖突概率越高。實(shí)時(shí)采集系統(tǒng)里最應(yīng)該認(rèn)真考慮的是能不能不共用一把“大鎖”而是讓每個(gè)數(shù)據(jù)通道都擁有自己的小鎖甚至直接無鎖化。對(duì)于“一個(gè)生產(chǎn)者和一個(gè)消費(fèi)者”的最典型采集模型完全可以用無鎖環(huán)形隊(duì)列ring buffer來實(shí)現(xiàn)生產(chǎn)者在隊(duì)尾寫入消費(fèi)者在隊(duì)頭讀取只要維護(hù)好讀寫指針的原子更新C 的atomic、Java 的AtomicInteger、Delphi 里的TInterlocked根本不需要鎖。緩沖區(qū)滿了就讓生產(chǎn)者丟棄新數(shù)據(jù)或者覆蓋最舊數(shù)據(jù)一切以實(shí)時(shí)性為先。但這種無鎖結(jié)構(gòu)也有代價(jià)它只適合單生產(chǎn)單消費(fèi)模型多個(gè)生產(chǎn)者同時(shí)寫入時(shí)必須引入額外的原子操作或 CAS 遍歷復(fù)雜度直接上升。我的建議是系統(tǒng)核心路徑用無鎖隊(duì)列邊緣路徑比如日志、配置更新才用鎖不要為了無鎖而無鎖。4.3 給每個(gè)鎖加超時(shí)拒絕無限等待死鎖之所以致命很大程度上是因?yàn)殒i等待是無限期的。線程永遠(yuǎn)等下去系統(tǒng)就永遠(yuǎn)卡下去。如果把“無限等”改成“等不到就放棄”即便真的死鎖了線程也能通過超時(shí)回退來自我恢復(fù)至少能把現(xiàn)場(chǎng)暴露出來。Windows 臨界區(qū)自帶TryEnterCriticalSectionLinux pthread 可以用pthread_mutex_timedlockJava 的ReentrantLock.tryLock(timeout)Python 的acquire(timeout...)C# 的Monitor.TryEnter(lockObj, TimeSpan)——幾乎所有主流語(yǔ)言都提供了帶超時(shí)的鎖獲取接口。以“無超時(shí)的鎖等待”為標(biāo)準(zhǔn)寫法就是一個(gè)立竿見影的整改項(xiàng)。信號(hào)量同樣要帶超時(shí)。WaitForSingleObject(handle, 1000)比單純無限等待好太多等不到就打印日志、繼續(xù)下一次嘗試系統(tǒng)就算遇到短暫沖突也不至于徹底僵死。4.4 鎖內(nèi)絕不做耗時(shí)操作和不認(rèn)識(shí)的調(diào)用這條我視為鐵律鎖保護(hù)的是臨界資源的“讀和寫”鎖內(nèi)不要做數(shù)據(jù)庫(kù)操作、磁盤寫、網(wǎng)絡(luò)請(qǐng)求、UI 同步更不要調(diào)用任何外部注冊(cè)的回調(diào)函數(shù)。為什么因?yàn)殒i內(nèi)一旦調(diào)用了“你控制不了的代碼”你就無法保證那個(gè)代碼會(huì)不會(huì)回頭再拿同一把鎖或者其他線程的鎖?；卣{(diào)往往是死鎖的導(dǎo)火索因?yàn)樗峭獠看a注入到鎖保護(hù)區(qū)域里的一顆定時(shí)炸彈。如果確實(shí)需要在鎖內(nèi)做復(fù)雜處理比如從網(wǎng)絡(luò)收到了配置需要更新共享狀態(tài)那就先把數(shù)據(jù)從鎖內(nèi)拷貝出來在鎖外做處理再用一個(gè)獨(dú)立的鎖或原子提交去更新狀態(tài)。這個(gè)模式叫“臨界區(qū)內(nèi)只留必需品一切可能阻塞的操作全部外置”。4.5 引入看門狗和死鎖檢測(cè)機(jī)制架構(gòu)層面強(qiáng)烈建議給系統(tǒng)設(shè)置一個(gè)“自我診斷”能力?？撮T狗線程剛才提過它負(fù)責(zé)定期檢查關(guān)鍵線程是否還在心跳范圍內(nèi)運(yùn)行一旦超時(shí)立即生成線程棧轉(zhuǎn)儲(chǔ)并且嘗試恢復(fù)比如讓出鎖資源、殺死并重建某個(gè)僵死線程。還有一個(gè)更輕量的檢測(cè)技巧用一個(gè)全局“鎖年齡”計(jì)數(shù)每次鎖被正常釋放時(shí)遞增。如果某把鎖超過一段時(shí)間沒被釋放就有很大概率是死鎖現(xiàn)場(chǎng)。這個(gè)方案實(shí)現(xiàn)成本低卻非常實(shí)用很多工業(yè)軟件就是這么干。4.6 用對(duì)人用好語(yǔ)言特性語(yǔ)言層面也有不少可以借力的地方。C 優(yōu)先用std::scoped_lock或std::lock一次獲取多把鎖避免人為排列順序。Java 的synchronized是可重入的但要注意接口回調(diào)里的鎖嵌套R(shí)eentrantLock有超時(shí)和中斷能力比 synchronized 適合復(fù)雜場(chǎng)景。Python 雖然有 GIL但不代表沒有死鎖threading.Lock在多個(gè)資源的鎖嵌套下照樣死鎖同樣需要遵循加鎖順序原則。Delphi 的TMonitor可以做超時(shí)等待但舊代碼習(xí)慣用TCriticalSection的話還是那句話想盡辦法包一層超時(shí)封裝。5. 常見死鎖場(chǎng)景速查與幾條個(gè)人經(jīng)驗(yàn)5.1 高頻死鎖場(chǎng)景速查表場(chǎng)景典型表現(xiàn)排查線索預(yù)防手段鎖順序不一致ABBA兩個(gè)以上線程堵死在互等棧上出現(xiàn)交叉的鎖等待全局統(tǒng)一鎖編號(hào)順序持鎖調(diào)用回調(diào)外部代碼在鎖內(nèi)又去拿其他鎖棧里能看到回調(diào)函數(shù)被鎖包裹回調(diào)移到鎖外執(zhí)行條件變量通知丟失線程永久阻塞在 wait檢查信號(hào)時(shí)序確認(rèn) wait 之前是否有通知發(fā)出回歸條件循環(huán)檢查持鎖 wait信號(hào)量計(jì)數(shù)透支消費(fèi)者線程全體阻塞計(jì)數(shù)為 0 但緩沖區(qū)仍有數(shù)據(jù)每次 post 與 wait 嚴(yán)格配對(duì)用日志統(tǒng)計(jì)計(jì)數(shù)變化Delphi 的Synchronize反向等待主線程卡死后臺(tái)線程卡死主線程棧阻塞在消息循環(huán)用 Queue 替代 Synchronize遞歸鎖誤用同一線程套兩層鎖在另一線程上下文持有棧上出現(xiàn)兩次同一鎖地址區(qū)分可重入鎖和不可重入鎖5.2 幾條直接可以抄作業(yè)的經(jīng)驗(yàn)第一所有鎖相關(guān)代碼必須放進(jìn)一個(gè)統(tǒng)一的封裝模塊不要散落在業(yè)務(wù)代碼里裸寫。哪怕只是在外面包一層超時(shí)函數(shù)后面排查的時(shí)候受益無窮。第二日志和心跳不能省。在實(shí)時(shí)采集系統(tǒng)里日志不是 debug 工具它是事后還原現(xiàn)場(chǎng)的唯一證據(jù)。你一定不希望死鎖發(fā)生之后只能靠“我記得當(dāng)時(shí)好像…”這句話來破案。第三代碼評(píng)審時(shí)固定問三個(gè)問題這個(gè)函數(shù)持鎖多久持鎖期間調(diào)用什么另一個(gè)線程同時(shí)會(huì)拿什么鎖這三個(gè)問題只要答不利索代碼就別合進(jìn)去。第四時(shí)不時(shí)給系統(tǒng)人為制造一下競(jìng)爭(zhēng)壓力。比如故意把采集緩沖區(qū)改小、提高刷新頻率讓線程碰撞的概率變大。死鎖這種概率性問題暴露得越早越好不要等到生產(chǎn)線現(xiàn)場(chǎng)才讓它現(xiàn)形。第五萬一真的在運(yùn)行現(xiàn)場(chǎng)碰到死鎖第一時(shí)間做的事不是亂點(diǎn)鼠標(biāo)而是立刻抓全線程?；蛘咿D(zhuǎn)儲(chǔ)文件然后再?zèng)Q定殺不殺進(jìn)程。手里沒有證據(jù)就重啟下次八成還會(huì)再踩同一個(gè)坑。我自己這些年折騰下來最深的一個(gè)體會(huì)是死鎖從來不是“改一行代碼就能解決”的問題它更像是系統(tǒng)設(shè)計(jì)階段的負(fù)債越晚還利息越高。與其等它爆發(fā)了再熬夜排查不如在設(shè)計(jì)初期就把鎖的用法、全局順序、超時(shí)機(jī)制、看門狗方案一并想清楚。多線程實(shí)時(shí)采集系統(tǒng)的核心目標(biāo)是“穩(wěn)”而“穩(wěn)”的起點(diǎn)就是讓死鎖這個(gè)幽靈從根上就沒有容身之處。