企业官网建设流程全解析

等待图很适合解释数据库阻塞：事务 T1 等 T2，T2 等 T3，T3 又等 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 值得自动化的是证据收集与解释：哪条边来自哪里，是否仍然有效，缺什么才能下结论。动作越不可逆，越不能靠一张漂亮的环图省掉核实。