等待图里有环，就能杀事务吗？先把锁证据放回同一个快照

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