事务与MVCC：死锁预防策略

可视化演示

展示系统处理流水线、实时性能指标曲线及多方案对比分析，包含数据流转、吞吐延迟监控与方案评估。

死锁问题根源

后厨最怕的不是菜做不完，而是两个人扛着工具互不相让：A握刀要锅，B端锅要刀，谁先松手谁吃亏。这就是死锁的微缩模型——每个厨师都是“有把握、有念想、不放、互相等”。

数据库的并发控制里，两个事务同时更新两张表也会出现一模一样的僵局。数据库专家把这幅惨状拆成了四个缺一不可的“性格特征”，统称死锁四必要条件：互斥（一条数据同一时刻只允许一个事务使用，像一把菜刀不可能同时给两个人剁肉）；持有并等待（事务拿着已获得的锁、又去申请别的锁，像握着菜刀不撒手还向别人借炒锅）；不可抢占（锁只能由持有者主动释放，别人不能劈手去抢）；环路等待（多个事务形成“你等我、我等它、它等你”的环形链）。

四个条件同时成立，死锁才会发生。这给了我们一个漂亮的突破口：只要打破其中任意一个，死锁就从“可能”变成“不可能”。后面所有预防策略，本质上都是选择性地拆掉某根柱子。

四个条件就像撑起一间“死锁屋”的四根柱子，后面所有预防策略都是定向拆柱——拆掉任意一根，屋顶就塌不下来。

预防思想总览

既然四根柱子一起撑着死锁屋，管理员只需“拆一根”就能让屋子盖不起来。最省事的拆法有三类：让厨师一次把做菜需要的工具全备齐（破除持有并等待）；允许管理员在紧急时收回闲置工具（破除不可抢占）；规定按编号单向取工具或按资历定优先级（破除环路等待）。

预防是“事前立法”，区别于死锁检测的“事后执法”。InnoDB 默认用锁等待超时（innodb_lock_wait_timeout）来兜底：等锁超过阈值就报错回滚。这就像厨房已经堵死了才喊保安来疏导；而预防协议是在加锁规则层面就把环路从“概率事件”变成“不可能事件”，不需要建立等待图，也没有检测延迟。

本文的主角是三条预防路线：资源有序分配直接对“环路等待”动手；Wait-Die 与 Wound-Wait 用时间戳给事务排定“资历”，让等待关系严格单向化，同样是破除环路。它们的共同点是不需要事后救火，规则前置。

检测像“堵车后交警来疏导”，预防像“入口挂上单向行驶标志”。好的厨师长从不等到厨房瘫了才动手，而是进门就把规矩立好。

资源有序分配

管理员最简单的一招：给每件厨具钉上独一无二的编号，1号炒锅、2号汤勺、3号砧板……规矩只有一条，拿工具必须从小编号往大编号拿，拿了2号就绝不能再回头拿1号。

换成数据库语言，“资源编号”可以对应行号、索引键、分区号。任何事务要加锁，必须沿着编号递增的方向申请。这样等待关系永远是“编号小的事务 → 编号大的事务”，不可能绕成环——因为环上必然存在一次“回头拿小号”的机会，而规则恰好禁止了它。这条规则无回滚、无抢占、无饥饿，实现成本极低。

但它的代价同样明显：资源编号一旦定下就全局固定，很难与业务自然的加锁顺序一致。比如业务习惯“先扣库存再写订单”，编号却规定先写订单再扣库存，开发者只能别扭地改变加锁顺序。为了硬凑顺序，还可能被迫多申请一些本不需要的资源，造成“锁升级”，反而降低并发度。

这规矩像“进厨房一律往编号更大的方向拿”，简单粗暴；但厨师想先拿炒锅再拿铲子时就会骂娘。管理者必须权衡规矩的简单和厨师的顺手。

Wait-Die协议

后来厨房来了位资历很老的厨师，管理员换了一套“按资历”的规矩。每位厨师进门领一个“进门号”——时间戳 TS，号越小资历越老。Wait-Die 的规则是：老厨师要用的工具被年轻厨师占着，老厨师站在旁边等；年轻厨师要用的工具被老厨师占着，年轻厨师立刻放下所有工具、重新排队。

技术化表述：事务 Ti 请求被 Tj 持有的锁时，若 TS(Ti) < TS(Tj)，Ti 等待；否则 Ti 回滚（die）。注意回滚的一定是“年轻的请求者”，老事务永远不必回滚。这保证“资历越老越安全”——占着资源的人不用怕，伸手要资源的人反而可能被劝退。

Wait-Die 是非抢占式的：老事务从不夺锁，只是等。它无死锁的证明很干净：若 Ti 等待 Tj，必然 TS(Ti) < TS(Tj)，等待关系沿时间戳严格递减；若存在环，绕一圈就会出现 TS(T1) < TS(T2) < … < TS(T1) 的矛盾。代价是年轻事务可能反复 die、反复重来，整体回滚率偏高，尤其在高冲突场景下。

Wait-Die 像“年轻人给老师傅让灶台”：老师傅说“我等会儿就行”，年轻人一看老师傅要用，赶紧收料重新排队。有礼貌，但年轻人来回折腾很费功夫。

Wound-Wait协议

Wound-Wait 是 Wait-Die 的“镜像版本”，把优先级反转过来：老厨师绝不等待，他看上的工具可以直接从年轻人手里拿走（wound，伤害），年轻人只能收手回滚；只有年轻厨师要用的工具被老厨师占着时，年轻人才等待。

技术化表述：若 TS(Ti) < TS(Tj)，Ti 伤害 Tj——Tj 回滚并释放所有锁，Ti 立即获得锁；否则 Ti 等待。与 Wait-Die 的关键差异是“谁是回滚者”：Wait-Die 回滚年轻的请求者，Wound-Wait 回滚年轻的持有者。

Wound-Wait 是抢占式的，需要底层锁管理器具备“强制释放某事务未完成锁”的能力，意味着 undo 日志和锁表要能精确清理。它天然无饥饿：任何老事务都不会被回滚，只会不断抢到所需资源并最终完成；代价是年轻事务可能反复被伤害，产生级联回滚。

Wound-Wait 像“老师傅直接端走年轻人的锅”，高效但霸道。年轻人被赶走几次后，后厨的菜可能洒一地——回滚写日志的开销就是那些洒落的菜。

策略对比选型

三套预防制度没有绝对好坏，只有“合不合适”。选择的两个关键指标是回滚率（年轻人被劝退或赶走的次数）和等待开销（师傅们站着不干活的时间）。

从回滚率看，Wound-Wait 优于 Wait-Die：Wait-Die 中年轻事务可能反复 die，积累的工作统统作废；Wound-Wait 中时间戳越小越安全，老事务永远不被回滚，回滚集中在刚起步的新事务上，整体损失更小。从等待开销看，Wait-Die 不抢占、不需要强制资源回收，锁管理器实现更简单；而 Wound-Wait 的每次抢占都要清理被伤害事务的 undo 状态，引擎层成本更高。

工程实际中，InnoDB 这类单机数据库并不把预防当默认方案，而是靠 MVCC（多版本并发控制）+ 锁等待超时 + 死锁检测组合兜底：MVCC 让读写互不阻塞，锁冲突范围大幅缩小，死锁概率天然下降。但在分库分表、分布式数据库（如 TiDB、OceanBase）里，跨节点的锁等待关系无法靠单一等待图实时检测，基于时间戳的 Wait-Die / Wound-Wait 就派上用场，成为“以回滚换无死锁”的兜底协议。

小饭馆（单机）客流低，用“简单提醒 + 堵了再疏导”就够了；连锁大饭店（分布式）必须一开始就用资历规矩。选哪套制度，看客流多少（冲突强度）和师傅贵不贵（事务成本）。

AI 应用场景

Python 演示

"""Deadlock prevention simulation: wait-die vs wound-wait"""  class Transaction:    def __init__(self, name, ts):        self.name = name        self.ts = ts            # 时间戳, 越小代表事务越老        self.holds = []         # 已持有的资源列表  class LockManager:    def __init__(self, protocol):        self.protocol = protocol    # 'wait-die' 或 'wound-wait'        self.owners = {}            # 资源 -> 持有事务        self.events = []            # 事件日志     def request(self, tx, res):        holder = self.owners.get(res)        if holder is None:            self.owners[res] = tx            tx.holds.append(res)            self.events.append('%s gets %s' % (tx.name, res))            return 'grant'        if holder is tx:            return 'grant'        if self.protocol == 'wait-die':            if tx.ts < holder.ts:                self.events.append('%s waits %s(holder %s)' % (tx.name, res, holder.name))                return 'wait'            self._abort(tx, 'die')            return 'abort'        if tx.ts < holder.ts:            self._abort(holder, 'wound')            self.owners[res] = tx            tx.holds.append(res)            self.events.append('%s steals %s' % (tx.name, res))            return 'grant'        self.events.append('%s waits %s(holder %s)' % (tx.name, res, holder.name))        return 'wait'     def _abort(self, tx, reason):        self.events.append('%s aborts(%s)' % (tx.name, reason))        for r in list(tx.holds):            self.owners.pop(r, None)        tx.holds = []  def simulate(protocol):    lm = LockManager(protocol)    t1 = Transaction('T1', ts=1)   # 老事务    t2 = Transaction('T2', ts=2)   # 年轻事务    lm.request(t1, 'R1')    lm.request(t2, 'R2')    lm.request(t1, 'R2')           # 老事务申请被年轻事务持有的锁    lm.request(t2, 'R1')           # 年轻事务申请被老事务持有的锁    print('=== %s ===' % protocol)    for e in lm.events:        print(' ', e)  if __name__ == '__main__':    simulate('wait-die')    simulate('wound-wait')

1. self.owners = {}一张“资源登记表”，像每个厨具挂着“谁在用”的牌子，锁管理器靠它判断冲突。
2. if tx.ts < holder.ts:时间戳比较是两套协议唯一的裁判标准：号小者老、号大者少。
3. self._abort(tx, 'die')wait-die 让年轻的请求者回滚，放手所有资源重新排队。
4. self._abort(holder, 'wound')wound-wait 让老的请求者把年轻的持有者赶走。
5. if __name__ == '__main__':直接运行这个文件，就能看到同一冲突下两套协议的分岔结局。

常见误区

面试题