1. 項目概述從“卡死”到“疏通”的系統(tǒng)工程在后臺系統(tǒng)開發(fā)或者數(shù)據(jù)庫運維的日常里最讓人頭疼的瞬間之一莫過于系統(tǒng)突然“卡住”不動了。前端的請求轉(zhuǎn)著圈圈后端的日志停滯不前CPU和內(nèi)存占用看起來卻不高。這時候有經(jīng)驗的工程師腦子里第一個蹦出來的詞很可能就是“死鎖”。這玩意兒不像內(nèi)存泄漏那樣緩慢侵蝕也不像CPU跑滿那樣聲勢浩大它更像是一場悄無聲息的交通癱瘓幾個關(guān)鍵線程或事務(wù)互相握住了對方需要的“鑰匙”卻又在等待對方先松手結(jié)果就是大家集體“擺爛”誰也動不了。今天要聊的“死鎖的處理策略——檢測和解除”就是一套應(yīng)對這種系統(tǒng)性癱瘓的“應(yīng)急救援方案”。它不追求百分百的預(yù)防那屬于“避免”和“預(yù)防”策略的范疇而是承認死鎖可能發(fā)生并建立一套機制來及時發(fā)現(xiàn)它然后安全地“拆除”它讓系統(tǒng)恢復(fù)暢通。無論是Java多線程程序里的鎖順序問題還是MySQL數(shù)據(jù)庫中并發(fā)的UPDATE語句甚至是操作系統(tǒng)內(nèi)核的資源爭奪死鎖檢測與解除都是保障系統(tǒng)最終可用性的關(guān)鍵安全網(wǎng)。這篇文章我們就深入這套“事后諸葛亮”但至關(guān)重要的策略拆解其核心原理、主流實現(xiàn)方案以及你在實操中一定會遇到的坑。2. 死鎖檢測的核心原理與算法實現(xiàn)死鎖檢測的本質(zhì)是在系統(tǒng)運行的某一時刻拍一張“快照”然后分析這張快照里是否存在循環(huán)等待的條件。這個條件就是著名的“死鎖四個必要條件”互斥、持有并等待、不可剝奪、循環(huán)等待。檢測算法主要就是針對“循環(huán)等待”這個條件進行建模和探查。2.1 資源分配圖與等待圖模型最直觀的模型是資源分配圖。在這個有向圖中有兩種節(jié)點進程或線程節(jié)點和資源節(jié)點。從進程指向資源的邊表示進程請求該資源但尚未獲得從資源指向進程的邊表示該資源已分配給該進程。當圖中出現(xiàn)一個閉合的環(huán)路時死鎖就發(fā)生了。然而在實際的系統(tǒng)實現(xiàn)中特別是數(shù)據(jù)庫管理系統(tǒng)這種資源類型繁多的場景維護完整的資源分配圖開銷較大。因此更常用的是一種簡化模型等待圖。等待圖只關(guān)注進程或事務(wù)節(jié)點。如果進程A正在等待一個被進程B占用的資源那么就畫一條從A指向B的邊。這樣問題就簡化為在等待圖中是否存在環(huán)一旦檢測到環(huán)就意味著環(huán)上的所有進程都陷入了死鎖。注意等待圖模型隱含了一個假設(shè)即一個資源同一時間只能被一個進程占用互斥。這對于鎖這類資源是成立的但對于一些可共享的資源如信號量初始值大于1則需要更復(fù)雜的模型或轉(zhuǎn)換。2.2 基于深度優(yōu)先搜索的環(huán)檢測算法對于等待圖的環(huán)檢測最直接的算法是深度優(yōu)先搜索。系統(tǒng)需要維護一個全局的等待關(guān)系表。檢測器會定期比如每隔幾秒或根據(jù)特定條件如某個事務(wù)等待超時被觸發(fā)執(zhí)行以下步驟構(gòu)建等待圖遍歷當前的鎖信息或等待隊列構(gòu)建出以事務(wù)為節(jié)點的有向圖。初始化為所有節(jié)點標記“未訪問”。深度遍歷從任意一個“未訪問”的節(jié)點開始DFS。在DFS過程中需要維護一個“當前路徑”的?；蛘咄ㄟ^顏色標記法白色-未訪問灰色-訪問中黑色-已訪問完成。發(fā)現(xiàn)環(huán)在遍歷節(jié)點N時如果發(fā)現(xiàn)它的某個后繼節(jié)點M的狀態(tài)是“灰色”即正在當前DFS路徑上那么就找到了一個從M到...到N再到M的環(huán)。環(huán)上的所有節(jié)點事務(wù)即為死鎖參與者。選擇犧牲者一旦檢測到環(huán)就需要選擇一個或多個“犧牲者”進行回滾以打破死鎖。選擇策略我們會在解除策略部分詳細討論。一個簡單的DFS檢測偽代碼示例顏色標記法def detect_deadlock(wait_for_graph): # 顏色狀態(tài)0白色(未訪問), 1灰色(訪問中), 2黑色(已結(jié)束) color {node: 0 for node in wait_for_graph} deadlock_victims [] def dfs(node, path): if color[node] 1: # 找到環(huán) # 從當前路徑path中找到環(huán)的起始位置 cycle_start_index path.index(node) cycle path[cycle_start_index:] deadlock_victims.extend(cycle) return True if color[node] 2: return False color[node] 1 path.append(node) for neighbor in wait_for_graph.get(node, []): if dfs(neighbor, path): # 如果已經(jīng)找到環(huán)可以提前結(jié)束本輪DFS但可能還有其他獨立環(huán) pass path.pop() color[node] 2 return False for node in wait_for_graph: if color[node] 0: dfs(node, []) return list(set(deadlock_victims)) # 去重2.3 數(shù)據(jù)庫中的死鎖檢測以InnoDB為例以MySQL的InnoDB存儲引擎為例它的死鎖檢測機制非常經(jīng)典。InnoDB使用一個等待圖來追蹤事務(wù)間的鎖等待關(guān)系。檢測算法做了高度優(yōu)化主動檢測當一個事務(wù)嘗試獲取鎖需要等待時InnoDB會立即觸發(fā)一次死鎖檢測而不是等待定時器。這能更快地發(fā)現(xiàn)死鎖。深度限制為了防止檢測算法本身消耗過多資源特別是在高并發(fā)下等待圖可能非常復(fù)雜InnoDB設(shè)置了檢測深度限制。如果搜索的深度超過了限制例如200步就認為死鎖檢測成本過高會視為發(fā)生了死鎖并選擇回滾當前請求鎖的事務(wù)。代價評估InnoDB在選擇犧牲者時會評估回滾哪個事務(wù)的“代價”更小。通常修改了更少數(shù)據(jù)行的事務(wù)會被優(yōu)先選為犧牲者。實操心得在數(shù)據(jù)庫運維中SHOW ENGINE INNODB STATUS命令的輸出里的LATEST DETECTED DEADLOCK部分是分析死鎖現(xiàn)場的第一手資料。它會清晰地畫出等待關(guān)系并告訴你最終哪個事務(wù)被回滾了。定期檢查這個信息是定位和優(yōu)化應(yīng)用中潛在死鎖問題的關(guān)鍵。3. 死鎖解除的策略與抉擇檢測到死鎖只是第一步如何安全地解除它讓系統(tǒng)恢復(fù)同時盡量減少損失才是策略的核心。解除死鎖的本質(zhì)就是打破四個必要條件中的至少一個。在檢測并定位到死鎖環(huán)之后我們通常通過“剝奪資源”來打破“不可剝奪”或“持有并等待”條件具體操作就是回滾一個或多個事務(wù)。3.1 選擇犧牲者的權(quán)衡藝術(shù)選擇回滾哪個事務(wù)犧牲者是一個需要權(quán)衡的決策。常見的策略包括最小代價優(yōu)先這是最常用的策略。評估回滾各個死鎖事務(wù)所需的“代價”選擇代價最小的那個。代價的衡量標準可以是已執(zhí)行的計算時間回滾一個已經(jīng)運行了10分鐘的事務(wù)比回滾一個剛運行1秒的事務(wù)損失更大。已修改的數(shù)據(jù)量回滾一個修改了10000行的事務(wù)比回滾一個只修改了1行的事務(wù)更“重”。InnoDB主要采用此標準。事務(wù)的“年齡”通常更年輕的事務(wù)作為犧牲者影響更小。涉及的數(shù)據(jù)重要性較難量化某些關(guān)鍵數(shù)據(jù)的事務(wù)優(yōu)先級可能更高。最近啟動的事務(wù)優(yōu)先基于“年輕事務(wù)持有鎖較少回滾代價低”的假設(shè)。涉及資源最少的事務(wù)優(yōu)先打破最小的環(huán)影響面最小。優(yōu)先級策略為事務(wù)設(shè)置人工優(yōu)先級總是回滾低優(yōu)先級的事務(wù)。這需要應(yīng)用層配合。實現(xiàn)上系統(tǒng)會維護事務(wù)的元數(shù)據(jù)開始時間、已修改頁面的列表等。當需要選擇時遍歷死鎖環(huán)中的所有事務(wù)根據(jù)上述策略計算一個“代價分”選出分數(shù)最低的作為犧牲者。3.2 回滾操作全部回滾與部分回滾選定犧牲者后就需要執(zhí)行回滾。全部回滾這是最簡單粗暴的方式直接終止犧牲者事務(wù)并回滾其開始以來的所有操作。這對于短事務(wù)或讀寫事務(wù)是合適的。數(shù)據(jù)庫通過Undo Log可以高效地完成此操作。部分回滾也稱為“回退到安全點”。在某些復(fù)雜的場景或應(yīng)用邏輯中我們可能希望只回滾到死鎖發(fā)生前的某個點而不是事務(wù)起點。這需要事務(wù)系統(tǒng)支持保存點的機制。犧牲者回滾到最后一個保存點釋放其持有的部分鎖從而打破死鎖然后事務(wù)有可能被重新啟動。這種方式對應(yīng)用更友好但實現(xiàn)復(fù)雜。重要提示無論采用哪種回滾都必須確保原子性和持久性?；貪L操作本身必須是一個原子操作并且回滾后的狀態(tài)必須被持久化。同時系統(tǒng)需要向客戶端返回明確的錯誤信息如MySQL的ERROR 1213 (40001): Deadlock found when trying to get lock以便應(yīng)用程序能夠進行重試或其他處理。3.3 解除策略的副作用與應(yīng)對死鎖解除并非沒有代價性能損耗頻繁的死鎖檢測和回滾會消耗CPU和IO資源。如果系統(tǒng)死鎖過于頻繁檢測和解除的開銷本身就會成為性能瓶頸。業(yè)務(wù)邏輯中斷被回滾的事務(wù)意味著業(yè)務(wù)操作失敗前端用戶可能會看到操作失敗提示需要重試。這影響用戶體驗?；铈i風(fēng)險在極端情況下可能發(fā)生“活鎖”。即兩個或多個事務(wù)不斷被選為犧牲者并回滾然后又立即重試再次陷入死鎖如此循環(huán)導(dǎo)致事務(wù)永遠無法完成。這通常需要引入隨機延遲重試機制來避免。我的踩坑記錄在一次高并發(fā)的庫存扣減場景中我們曾遇到間歇性的死鎖。采用默認的最小修改行數(shù)策略回滾后發(fā)現(xiàn)總是后來啟動的、只扣減1件庫存的“小事務(wù)”被回滾。這導(dǎo)致這些用戶的購買請求失敗率異常高。后來我們調(diào)整了策略結(jié)合事務(wù)年齡和修改行數(shù)并在應(yīng)用層為重試邏輯增加了指數(shù)退避算法才平穩(wěn)度過了促銷高峰。這說明默認策略不一定最優(yōu)需要結(jié)合業(yè)務(wù)特點進行考量。4. 檢測與解除的工程化實踐理論上的算法和策略最終要落地到具體的系統(tǒng)中。不同的系統(tǒng)操作系統(tǒng)、數(shù)據(jù)庫、分布式中間件有其獨特的實現(xiàn)方式和優(yōu)化技巧。4.1 檢測頻率與觸發(fā)機制定時 vs 事件驅(qū)動什么時候運行死鎖檢測算法這是一個權(quán)衡開銷和及時性的問題。定時檢測系統(tǒng)設(shè)置一個固定的時間間隔如每5秒、每1分鐘啟動檢測。優(yōu)點是實現(xiàn)簡單可以將檢測開銷平均分攤開。缺點是死鎖發(fā)生后最長需要等待一個檢測周期才能被發(fā)現(xiàn)響應(yīng)不及時。事件驅(qū)動檢測當新的“等待邊”產(chǎn)生時即一個事務(wù)/進程因申請資源而阻塞時立即觸發(fā)檢測。這能保證死鎖幾乎被即時發(fā)現(xiàn)如上文提到的InnoDB。缺點是在高并發(fā)下頻繁的阻塞可能導(dǎo)致檢測被頻繁觸發(fā)開銷集中可能影響系統(tǒng)吞吐量?；旌喜呗哉壑械霓k法。采用事件驅(qū)動但對檢測頻率設(shè)置一個下限如每秒最多觸發(fā)N次或者當系統(tǒng)負載較低時采用事件驅(qū)動負載高時切換為周期較長的定時檢測。實操建議對于在線交易處理系統(tǒng)推薦使用事件驅(qū)動或高頻率的定時檢測以快速響應(yīng)死鎖減少用戶等待時間。對于后臺批處理系統(tǒng)可以采用較低頻率的定時檢測以節(jié)省資源。4.2 分布式系統(tǒng)死鎖檢測的挑戰(zhàn)在單機系統(tǒng)中等待圖信息是集中的檢測相對直接。但在分布式系統(tǒng)中資源和進程分散在不同的節(jié)點上構(gòu)建全局的等待圖變得異常困難。主流的分布式死鎖檢測方法有集中式檢測指定一個節(jié)點作為協(xié)調(diào)者。所有其他節(jié)點定期或在等待事件發(fā)生時向協(xié)調(diào)者發(fā)送本地等待信息。協(xié)調(diào)者匯總成全局圖進行檢測。問題在于協(xié)調(diào)者單點故障和通信開銷。分布式檢測沒有中心節(jié)點。每個節(jié)點運行自己的檢測算法并通過在進程間傳遞“探針”消息來發(fā)現(xiàn)環(huán)路。例如 Chandy-Misra-Haas 算法。這種方式容錯性好但算法復(fù)雜消息數(shù)量可能較多?；谌挚煺盏臋z測利用分布式快照算法如Chandy-Lamport算法獲取系統(tǒng)在某一時刻的一致性全局狀態(tài)然后在這個快照上運行檢測算法。這更適用于事后分析而非實時解除。由于分布式死鎖檢測的復(fù)雜性和性能開銷許多現(xiàn)代分布式數(shù)據(jù)系統(tǒng)如Google Spanner、CockroachDB采用了不同的思路盡可能避免死鎖而不是檢測它。例如通過全局唯一、單調(diào)遞增的時間戳來規(guī)定所有事務(wù)的鎖獲取順序悲觀鎖或者使用樂觀并發(fā)控制在提交時再檢測沖突并讓沖突的事務(wù)中止這從本質(zhì)上避免了持有并等待形成的環(huán)。4.3 工具與監(jiān)控讓死鎖可視化對于開發(fā)和運維人員不能只依賴系統(tǒng)自動解除死鎖更需要主動發(fā)現(xiàn)和根除死鎖的根源。這就需要監(jiān)控工具。數(shù)據(jù)庫層面MySQL InnoDB如前所述使用SHOW ENGINE INNODB STATUS\G。更進階的可以開啟innodb_print_all_deadlocks配置將所有死鎖信息打印到錯誤日志中便于集中收集分析。PostgreSQL查看pg_stat_activity視圖結(jié)合pg_locks視圖來分析鎖等待。日志中也會記錄死鎖信息。SQL Server使用 SQL Profiler 跟蹤Deadlock graph事件或查詢系統(tǒng)視圖sys.dm_tran_locks和sys.dm_os_waiting_tasks。應(yīng)用層面Java為例線程轉(zhuǎn)儲當Java應(yīng)用疑似死鎖時使用jstack pid命令或kill -3 pid獲取線程轉(zhuǎn)儲。在轉(zhuǎn)儲文件末尾JVM通常會明確提示Found one Java-level deadlock:并列出死鎖線程的詳細堆棧信息。VisualVM, JProfiler 等工具這些圖形化工具可以連接至運行的JVM直接檢測并展示死鎖線程。監(jiān)控告警將數(shù)據(jù)庫的死鎖計數(shù)器如Innodb_deadlocks或應(yīng)用日志中的死鎖錯誤關(guān)鍵字納入監(jiān)控系統(tǒng)如 Prometheus Grafana, ELK并設(shè)置告警閾值。當死鎖頻率超過一定范圍時及時通知研發(fā)人員介入排查。5. 從解除到預(yù)防根除死鎖的治本之策雖然檢測與解除是重要的安全網(wǎng)但一個健康的系統(tǒng)應(yīng)該追求的是盡可能少地觸發(fā)這個安全網(wǎng)。因此在理解了如何“救火”之后我們必須思考如何“防火”。5.1 通過設(shè)計模式避免死鎖在應(yīng)用代碼層面遵循一些成熟的設(shè)計模式可以極大降低死鎖概率固定順序獲取鎖這是避免死鎖最經(jīng)典、最有效的方法。如果系統(tǒng)中所有線程都按照一個全局約定的、固定的順序去申請鎖例如總是先鎖表A再鎖表B最后鎖表C那么循環(huán)等待的條件就不可能成立。這需要在對業(yè)務(wù)和數(shù)據(jù)進行全局梳理的基礎(chǔ)上進行設(shè)計。鎖超時機制不給鎖設(shè)置無限的等待時間。使用tryLock(long timeout, TimeUnit unit)這樣的方法在獲取鎖失敗一段時間后主動放棄并回滾已做的工作或進行重試。這打破了“持有并等待”條件因為等待不是無限的但可能帶來活鎖問題需要配合隨機退避的重試策略。使用更高級的并發(fā)工具在Java中可以多使用java.util.concurrent包下的高級工具如ConcurrentHashMap、CopyOnWriteArrayList、Semaphore、CountDownLatch等。它們內(nèi)部實現(xiàn)了更高效的并發(fā)控制很多時候可以替代顯式的鎖減少死鎖風(fēng)險?？s小鎖的粒度與范圍盡量使用行級鎖而非表級鎖鎖住盡可能少的數(shù)據(jù)和盡可能短的時間。在事務(wù)中將最可能產(chǎn)生沖突的操作往后放盡快提交事務(wù)釋放鎖。5.2 數(shù)據(jù)庫事務(wù)設(shè)計最佳實踐數(shù)據(jù)庫是死鎖的重災(zāi)區(qū)良好的事務(wù)設(shè)計至關(guān)重要保持事務(wù)短小精悍事務(wù)執(zhí)行時間越長持有鎖的時間就越長與其他事務(wù)沖突的概率就越大。避免在事務(wù)中進行遠程調(diào)用、復(fù)雜的計算或人機交互。以一致的順序訪問數(shù)據(jù)這和“固定順序獲取鎖”同理。如果多個事務(wù)都需要更新用戶表和訂單表約定好都先更新用戶表再更新訂單表。合理使用索引UPDATE或DELETE語句的WHERE條件如果沒有合適的索引可能會升級為表鎖或鎖住大量不必要的行極易引發(fā)死鎖。確保高頻更新語句能用上索引?？紤]使用樂觀鎖對于沖突不那么頻繁的場景可以使用版本號或時間戳的樂觀鎖機制。先讀取數(shù)據(jù)并記錄版本更新時檢查版本是否變化。這避免了在整個事務(wù)期間持有悲觀鎖從源頭減少了死鎖可能。謹慎使用SELECT ... FOR UPDATE明確你真的需要這條語句來鎖定讀取的行。不必要的悲觀鎖是死鎖的溫床。5.3 壓力測試與混沌工程在系統(tǒng)上線前或進行重大變更后進行有針對性的壓力測試是發(fā)現(xiàn)潛在死鎖問題的有效手段。模擬高并發(fā)場景使用JMeter、LoadRunner等工具模擬遠高于日常峰值的并發(fā)用戶執(zhí)行那些涉及核心資源更新的業(yè)務(wù)流。關(guān)注長尾延遲在壓力測試中不僅要看平均響應(yīng)時間和吞吐量更要關(guān)注P99、P99999分位、99.9分位的延遲。死鎖往往會導(dǎo)致少量請求的響應(yīng)時間異常飆升。引入混沌工程思想在測試環(huán)境甚至預(yù)發(fā)布環(huán)境可以故意制造一些“混亂”比如隨機延遲某個數(shù)據(jù)庫操作的響應(yīng)、隨機殺死某個服務(wù)實例觀察系統(tǒng)在異常情況下的行為看死鎖檢測與解除機制是否能正確工作。死鎖的處理從被動的檢測解除到主動的預(yù)防避免是一個系統(tǒng)工程。它要求開發(fā)者不僅了解底層的算法和機制更要具備良好的架構(gòu)設(shè)計意識和嚴謹?shù)木幊塘?xí)慣。把系統(tǒng)想象成一個復(fù)雜的交通網(wǎng)絡(luò)死鎖檢測與解除就是那套應(yīng)急清障和事故快處流程而良好的編碼規(guī)范和架構(gòu)設(shè)計則是科學(xué)的道路規(guī)劃、清晰的交通標志和司機線程的守法意識。兩者結(jié)合才能保障系統(tǒng)這座“城市”的長期暢通與穩(wěn)定。