什么是死锁？如何避免和解决

面试记录 2026-09-17

题目：什么是死锁？如何避免和解决

难度：low

标签：db/mysql/transaction, mysql/deadlock, difficulty/low

评分：⭐⭐⭐☆（3/5）

我的回答

说一下什么是死锁。死锁是多个线程对一组资源的竞争，然后大家相互拿到了不同的资源，又互不相互相不能释放，然后大家都在等待其他的线程释放资源，最终导致整个程序的锁死，各个资源都无法进行下一步工作。举个例子，例如一组资源为 1234，这时候线程 A 拿到了资源 1，线程 B 拿到了资源 2，线程 C 拿到了资源 3，这时 A 想要拿资源 2 的时候，发现资源 2 被 B 拿了，A 无法访问，这时候 B 想要拿资源 1 的时候，发现资源被 A 拿了。也无法访问，相互就锁死了。如果大家没有等待的条件，大家都会等到整个线程崩溃。但是如果想要破坏这个死锁，就需要从这几个条件中去排除这个问题。首先是资源的分组性，就是资源的分散性，大家没有一次性拿到全部资源。第二是资源的不可争抢性，就是我拿了资源，我不能抢别人资源。第三，长时间等待没有释放。第四，互斥。这几个性质其实破坏掉了，整个死锁也就不存在了。

解除死锁的话，第一个，如果我要申请一个一组资源，一次申请一组资源，整个资源拿到了我才去执行，这样就不会跟其他人有争抢，也就不会有死锁。第二，如果资源我长时间申请不到，这时候我就放弃当前执行，资源放给其他人，这个事也能继续做。第三，如果我拿到了资源 1，但是我没拿到资源 2，我有强权去把别人的资源 2 拿过来，这时候这个事也能通过。解决死锁的几个这个几个方向。

点评

优点：

• 理论扎实：准确列出死锁四条件（互斥、占有且等待、不可剥夺、循环等待）
• 举例清晰（A 拿 1 等 2，B 拿 2 等 1）
• 提出三种破坏策略：一次申请全部、超时放弃、强制剥夺

不足：

• 理论 vs 实践严重脱节：全程是操作系统视角，未落到 InnoDB 死锁的具体表现
• 未提 InnoDB 死锁检测：innodb_deadlock_detect=ON（默认），基于 wait-for graph 检测后自动回滚 undo log 少的事务
• 未提关键参数：innodb_lock_wait_timeout（默认 50 秒，超时抛 Lock wait timeout exceeded）
• 未提监控工具：SHOW ENGINE INNODB STATUS 的 LATEST DETECTED DEADLOCK 段、information_schema.innodb_trx、performance_schema.data_lock_waits
• 未提 InnoDB 特有场景：间隙锁死锁、next-key lock 交叉、INSERT ... ON DUPLICATE KEY UPDATE 引发的死锁
• 未提业务侧解决方案：事务顺序固定（按主键升序）、事务粒度小、避免大范围扫描加锁
• 未提乐观锁绕过悲观锁死锁的思路

补充：

• InnoDB 死锁检测开销大：O(N²) 检查 wait-for graph，超长事务多的场景可考虑 innodb_deadlock_detect=OFF + 依赖 innodb_lock_wait_timeout
• 应用层防死锁黄金法则：固定加锁顺序
• 排查链路：SHOW ENGINE INNODB STATUS → 找最近一次死锁 → 看两个事务的 SQL、持有的锁、等待的锁
• InnoDB 默认就是"自动回滚牺牲者事务"，牺牲者拿到 ERROR 1213: Deadlock found when trying to get lock

完整讲解

第一部分：知识重点剖析

核心考点定位：既要有操作系统层死锁的理论理解，更要掌握 InnoDB 死锁的检测、监控与业务侧规避手段。

知识点拆解：

1. 死锁理论（四必要条件）：

• 互斥：一次只能被一个事务持有
• 占有且等待：持有 A 的同时等 B
• 不可剥夺：事务持有的锁不能被动回收，必须主动释放
• 循环等待：A 等 B、B 等 C、C 等 A 形成环
• 破坏任一条件即可防止死锁

1. InnoDB 的死锁机制：

• InnoDB 是自动检测型：默认 innodb_deadlock_detect=ON，事务在等锁时会持续构建 wait-for graph，一旦形成环就立刻识别出死锁
• 牺牲者选择：回滚 undo log 少（改动小）的事务，让它抛出 ERROR 1213，另一事务继续执行
• 死锁检测成本：O(N²) 检查当前所有等锁事务，事务数很多时开销大
• 超时兜底：innodb_lock_wait_timeout（默认 50 秒），超过直接抛 ERROR 1205: Lock wait timeout exceeded，事务回滚

1. InnoDB 常见死锁场景：

• 间隙锁交叉：两个事务在 RR 隔离级别下分别用 INSERT 或 SELECT FOR UPDATE 请求不同的间隙锁，最终循环等待
• 不同顺序更新多行：事务 A 先锁 id=1 再锁 id=2，事务 B 先锁 id=2 再锁 id=1
• INSERT ... ON DUPLICATE KEY UPDATE：并发插入相同主键，一个 INSERT 一个 UPDATE 触发死锁
• 索引缺失导致的锁升级：本该走索引却全表扫描，锁大量行放大冲突面
• 外键约束：父子表同时更新时的加锁顺序
• UPDATE 无 WHERE 条件：锁全表

1. 死锁监控与排查：

• SHOW ENGINE INNODB STATUS：看 LATEST DETECTED DEADLOCK 段，包含两个事务的 SQL、持有的锁、等待的锁
• information_schema.innodb_trx：当前运行中的事务
• information_schema.innodb_locks（5.7）/ performance_schema.data_locks（8.0）：当前持有的锁
• performance_schema.data_lock_waits（8.0）：锁等待链，看谁等谁
• 慢查询日志里 Error 1213 频次监控

1. 业务侧防死锁方案（优先级从高到低）：

• 固定加锁顺序：所有事务按主键升序加锁，如统一先锁 id 小的行
• 缩小事务粒度：事务内越少锁越好，避免长事务
• 减少事务内 SQL 数量：一条 SQL 完成就一条，避免多次 SELECT FOR UPDATE + UPDATE
• 加锁前先用 SELECT 判断：能用 SELECT ... FOR UPDATE NOWAIT（8.0）就别阻塞
• 走乐观锁：用 version 列 CAS 更新，避免悲观锁冲突
• 合理建索引：无索引的 UPDATE/DELETE 会锁大量行
• 控制并发：热点行加应用层分布式锁（Redis、Zookeeper）串行化
• 调大 timeout：innodb_lock_wait_timeout 从 50s 提到 300s，让慢事务有机会完成

1. 参数调整场景：

• 默认 innodb_deadlock_detect=ON：适合事务短、数量少
• 大量长事务：检测开销大，可 innodb_deadlock_detect=OFF + 依赖 timeout
• 高并发写入：可能需 innodb_lock_wait_timeout 减小到 5-10 秒快速失败

第二部分：考察方向与延伸递进

考察方向：

• 深度：能否讲清 InnoDB 的自动死锁检测机制与牺牲者选择逻辑
• 广度：能否覆盖监控工具链、参数调优、业务侧规避
• 应用：能否在真实线上死锁事故中给出一套定位与修复方案

延伸递进面试题：

1. 为什么两个相同 SQL 并发执行会死锁，同一个 SQL 单独跑不会？

• 解答要点：SQL 相同不代表访问顺序相同。RR 隔离下两条 UPDATE 可能锁不同的间隙/行，如果扫描顺序受 B+ 树遍历影响，可能形成交叉等待。

1. innodb_deadlock_detect=OFF 有什么后果？

• 解答要点：不再自动检测，只能依赖 innodb_lock_wait_timeout 让等锁方超时回滚。优点：省 CPU（大事务场景明显）；缺点：恢复慢、等待时间长。

1. 怎么在压测环境主动触发死锁？

• 解答要点：两个会话，会话 1 BEGIN; UPDATE t SET c=c+1 WHERE id=1;（不 commit），会话 2 BEGIN; UPDATE t SET c=c+1 WHERE id=2;，然后会话 1 UPDATE t SET c=c+1 WHERE id=2;，会话 2 UPDATE t SET c=c+1 WHERE id=1;，会话 1 立刻收到 1213 报错。

第三部分：面试者参考回答（口语化）

面试官您好，死锁我先从理论上讲清楚，再落到 InnoDB 的具体表现。

理论上死锁有四个必要条件：互斥、占有且等待、不可剥夺、循环等待。破坏任意一个就能防止死锁。经典例子是两个事务，A 拿了资源 1 等 2，B 拿了资源 2 等 1，就形成循环等待，谁都动不了。

但在 MySQL InnoDB 里，死锁的表现和检测方式跟理论不太一样，我主要讲几个点。

InnoDB 的默认行为是自动检测。innodb_deadlock_detect 默认开启，事务在等锁的时候会持续构建 wait-for graph，一旦发现环，就立刻选出牺牲者——通常是 undo log 少、改动少的那个事务，回滚它并抛 ERROR 1213: Deadlock found，另一事务继续执行。所以开发者看到的错误是 1213，业务代码要做重试。检测本身有 O(N²) 开销，事务特别多的场景可以考虑关闭检测，改用 innodb_lock_wait_timeout（默认 50 秒）来兜底——超时会抛 1205 错误。

常见死锁场景有几个。第一是间隙锁交叉，RR 隔离级别下两个事务用不同的 WHERE 条件触发不同间隙锁，最终循环等待。第二是多行更新顺序不同，A 先锁 id=1 再锁 id=2，B 反过来。第三是 INSERT ... ON DUPLICATE KEY UPDATE，并发插相同主键时一个走 INSERT 一个走 UPDATE 触发死锁。第四是 UPDATE 没写 WHERE 条件锁全表。第五是索引缺失导致锁大量行放大冲突面。

排查线上死锁我会按这个链路走：先跑 SHOW ENGINE INNODB STATUS 看 LATEST DETECTED DEADLOCK 段，里面会显示两个事务的 SQL、各自持有的锁、等待的锁；再看 performance_schema.data_lock_waits 找锁等待链；最后看 innodb_trx 找超长事务。慢查询日志里频繁出现 1213 错误就是死锁高发信号。

预防方案我按优先级列一下。第一是固定加锁顺序，所有事务按主键升序加锁，这是最有效的办法，业务侧只要约定统一顺序就能消掉大部分死锁。第二是缩小事务粒度，一条 SQL 能完成就别拆多条，事务内减少锁数量。第三是避免长事务，长事务持有锁越久，越容易和其他事务撞。第四是加索引，无索引的 UPDATE 会锁大量行。第五是用乐观锁绕过，version 列 CAS 更新，冲突就重试，不用悲观锁串行化。第六是8.0 的 NOWAIT / SKIP LOCKED，SELECT FOR UPDATE NOWAIT 拿不到锁立即返回，避免阻塞等待成环。

参数层面，默认配置基本够用，只是长事务多、检测开销大的场景可以 innodb_deadlock_detect=OFF，靠 innodb_lock_wait_timeout 兜底。反过来热点行死锁频发的场景，把 innodb_lock_wait_timeout 调小让失败快一点，业务侧快速重试。

https://chat.deepseek.com/share/wy9ppt0dw6b7uhgyct

---

面试记录 2026-10-13（第 2 次）

题目：什么是死锁？如何避免和解决

难度：low

标签：db/mysql/transaction, mysql/deadlock, difficulty/low

评分：⭐⭐☆☆☆（2/5）

练习次数：2

我的回答

死锁就是一个彻底解不开的锁，表示这个动作被卡顿停止，没有人工介入是无法解除的。

构成死锁核心有这么几个原因。首先是资源没有一次性申请，不同的线程获取了不同的资源，又相互造成循环等待。

最后我申请资源，你也申请资源，大家申请的，你申请的是我的，我申请的是你的，我不能抢你的，你也不能抢我的，这里边就涉及一个不能抢占其他人资源，也是导致死锁的一个核心原因。

总结一下死锁构成的原因有，没有一次性申请所有资源，相互等待了资源，资源不能强制争抢。这 3 个任意破坏一个都可以解除这个死锁。

点评

优点：

• 覆盖了部分死锁必要条件：占有且等待（没有一次性申请）、循环等待、不可剥夺
• 提到"任意破坏一个都可以解除"，符合破坏条件防死锁的思路

不足：

• 完全脱离数据库语境：全程是操作系统通用理论，未落到 InnoDB 死锁的具体表现（ERROR 1213、wait-for graph、innodb_deadlock_detect、innodb_lock_wait_timeout）
• 理论也讲得不够完整：Coffman 四条件是互斥、占有且等待、不可剥夺、循环等待，本次遗漏了"互斥"，且"任意破坏一个"实际只对"循环等待"和"占有且等待"这两条真正有工程意义——不可剥夺在 InnoDB 里几乎不能破坏
• 没讲 InnoDB 的死锁检测机制：默认 innodb_deadlock_detect=ON 自动检测并回滚 undo log 少的事务，这是"自动解除"的关键
• 没讲监控：SHOW ENGINE INNODB STATUS 的 LATEST DETECTED DEADLOCK 段、performance_schema.data_lock_waits、innodb_trx
• 没讲业务侧解决方案：固定加锁顺序、缩小事务粒度、乐观锁、NOWAIT、加索引防锁放大
• 没讲典型死锁场景：间隙锁交叉、多行更新顺序不同、INSERT ... ON DUPLICATE KEY UPDATE

补充：

• InnoDB 死锁本质：多事务因间隙锁 / 行锁 / Next-Key Lock 交叉形成 wait-for graph 环，检测器（默认开启）主动选一个牺牲者回滚
• 排查三件套：SHOW ENGINE INNODB STATUS 看最近死锁、data_lock_waits 看等待链、innodb_trx 找长事务
• 业务防死锁第一原则：固定加锁顺序（按主键升序）
• 关键参数：innodb_deadlock_detect（检测开关）、innodb_lock_wait_timeout（默认 50 秒）

ℹ️ 完整讲解见上方首次记录（2026-09-17）