等待图很适合解释数据库阻塞事务 T1 等 T2T2 等 T3T3 又等 T1。画出这个环以后自动终止一个会话似乎顺理成章。问题是三条边真的同时存在吗合并历史可能制造一个不存在的死锁采集器先查到 T1→T2隔一会儿查到 T2→T3又从旧缓存拿到 T3→T1。如果中间已经发生提交、回滚或会话重连拼起来的环只是采集产物。进程号复用也会把旧持有者误认成新事务。PostgreSQL 锁文档介绍了死锁检测以及一致的加锁顺序。数据库有自己的事务语义与检测机制外围 Agent 应先解释锁记录、查询和事务年龄不能仅凭跨时间的图覆盖数据库判断。其他锁类型、多实例协调和分布式事务还需要各自的语义。图里“candidate cycle”很关键环是进一步核查的入口。若资源有多个实例、锁模式兼容单纯的有向边还不足以表达全部等待条件。以下例子限定为每条边确实表示阻塞等待的简化模型。把快照标识做成算法输入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))这个断言验证了旧边不会污染新图并未实现数据库的一致性快照。真实采集要记录数据库实例、事务身份、锁对象、模式和查询时间把客户端生成的同一个字符串贴到多次查询上并不会自动获得原子性。解锁动作需要第二次确认如果最终需要终止事务先重查目标身份和当前等待关系检查业务重试是否幂等、回滚成本有多大再让有权限的操作人或受控流程决定。把最长事务默认当作牺牲者也可能中断一项成本很高但即将完成的工作。本文只运行离线图算法没有连接数据库、制造死锁或终止会话。Agent 值得自动化的是证据收集与解释哪条边来自哪里是否仍然有效缺什么才能下结论。动作越不可逆越不能靠一张漂亮的环图省掉核实。
