等待圖很適合解釋數(shù)據(jù)庫阻塞事務(wù) T1 等 T2T2 等 T3T3 又等 T1。畫出這個環(huán)以后自動終止一個會話似乎順理成章。問題是三條邊真的同時存在嗎合并歷史可能制造一個不存在的死鎖采集器先查到 T1→T2隔一會兒查到 T2→T3又從舊緩存拿到 T3→T1。如果中間已經(jīng)發(fā)生提交、回滾或會話重連拼起來的環(huán)只是采集產(chǎn)物。進(jìn)程號復(fù)用也會把舊持有者誤認(rèn)成新事務(wù)。PostgreSQL 鎖文檔介紹了死鎖檢測以及一致的加鎖順序。數(shù)據(jù)庫有自己的事務(wù)語義與檢測機(jī)制外圍 Agent 應(yīng)先解釋鎖記錄、查詢和事務(wù)年齡不能僅憑跨時間的圖覆蓋數(shù)據(jù)庫判斷。其他鎖類型、多實例協(xié)調(diào)和分布式事務(wù)還需要各自的語義。圖里“candidate cycle”很關(guān)鍵環(huán)是進(jìn)一步核查的入口。若資源有多個實例、鎖模式兼容單純的有向邊還不足以表達(dá)全部等待條件。以下例子限定為每條邊確實表示阻塞等待的簡化模型。把快照標(biāo)識做成算法輸入from collections import defaultdict def cycle_in_snapshot(rows, snapshot): graph defaultdict(list) for waiter, owner, snap in rows: if snap snapshot: graph[waiter].append(owner) visited, active, stack set(), set(), [] def walk(node): if node in active: return stack[stack.index(node):] [node] if node in visited: return None visited.add(node); active.add(node); stack.append(node) for other in graph.get(node, []): found walk(other) if found: return found stack.pop(); active.remove(node) return None for node in list(graph): found walk(node) if found: return found return None rows [(T1, T2, s1), (T2, T3, s1), (T3, T1, s0)] assert cycle_in_snapshot(rows, s1) is None rows.append((T3, T1, s1)) assert cycle_in_snapshot(rows, s1) [T1, T2, T3, T1] print(cycle_in_snapshot(rows, s1))這個斷言驗證了舊邊不會污染新圖并未實現(xiàn)數(shù)據(jù)庫的一致性快照。真實采集要記錄數(shù)據(jù)庫實例、事務(wù)身份、鎖對象、模式和查詢時間把客戶端生成的同一個字符串貼到多次查詢上并不會自動獲得原子性。解鎖動作需要第二次確認(rèn)如果最終需要終止事務(wù)先重查目標(biāo)身份和當(dāng)前等待關(guān)系檢查業(yè)務(wù)重試是否冪等、回滾成本有多大再讓有權(quán)限的操作人或受控流程決定。把最長事務(wù)默認(rèn)當(dāng)作犧牲者也可能中斷一項成本很高但即將完成的工作。本文只運行離線圖算法沒有連接數(shù)據(jù)庫、制造死鎖或終止會話。Agent 值得自動化的是證據(jù)收集與解釋哪條邊來自哪里是否仍然有效缺什么才能下結(jié)論。動作越不可逆越不能靠一張漂亮的環(huán)圖省掉核實。