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