在数千个并发事务下，如何预防死锁（deadlock）？

Question

IT Interview Practice · Accepted Answer

**以一致的全局顺序获取锁，让事务保持简短，在安全的地方降低隔离级别，并在死锁仍然发生时重试失败者。**死锁是一个环：事务 A 持有行 1 并等待行 2，而 B 持有行 2 并等待行 1——谁都无法前进，于是 DB 杀掉其中一个。

## 你必须打破的这个环

```text
   Tx A                              Tx B
   holds row 1  ──── waits ────▶ row 2 (held by B)
        ▲                              │
        │ waits                        │ holds
        └────────── row 1 ◀────────────┘
                (cycle = deadlock; DB aborts one victim)
```

## 策略

- **一致的锁顺序。**如果每个事务总是以相同的顺序锁定行（例如主键升序），环就不可能形成——A 和 B 都先抢行 1，因此其中一个只是等待。这是最大的单一杠杆。一个经典 bug：一次以 `(from, to)` 顺序锁定账户的转账，会与反向转账形成死锁；始终按 `min(id), max(id)` 加锁。
- **简短事务。**尽可能短地持有锁——在 `BEGIN` **之前**做好验证、网络调用和读取，然后快速地加锁、写入并 `COMMIT`。长事务会扩大形成环和锁等待的窗口。
- **在安全处降低隔离级别。**`SERIALIZABLE` 会获取更多/范围锁，也更易死锁；`READ COMMITTED`（Postgres 默认）加锁更少。使用仍能满足正确性的最弱隔离级别。
- **死锁时重试。**死锁是短暂的。捕获死锁错误（Postgres `40P01`、MySQL `1213`），并以小退避重试整个事务。在规模化下某些争用不可避免，因此重试是一张安全网，而非锁顺序的替代品。

## 面试视角

面试官检查你是否知道死锁是**靠设计来预防的，而不只是被捕获**。仅说"重试"是一个弱回答——出色的回答以**一致的锁顺序**和**简短事务**开头，然后为残余的部分加上重试。一个常见陷阱：假设应用必须检测死锁；实际上是 **DB 检测到环并为你中止一个牺牲者（victim）**——你的工作是锁顺序加上一个重试循环。

**权衡：**当访问模式是动态的或跨多张表时，严格的顺序会很难做到；更低的隔离级别有你必须推理清楚的异常（不可重复读，non-repeatable reads）风险。重试循环必须是**幂等的**且有上限，否则一个热点冲突会变成一场重试风暴。死锁预防其实是锁纪律加上有界的重试，而非单一的银弹。

你必须打破的这个环

策略

面试视角

相关问题