关注我们,设为星标,每天7:30不见不散,每日java干货分享你的电商系统正在进行大促。突然，支付服务疯狂报错：java.sql.SQLTransactionRollbackException: Deadlock found when trying to get lock; try restarting transaction
你的反应：
你知道发生了死锁，但你不知道是哪两个业务逻辑撞车了。
你颤颤巍巍地在数据库里敲下了那行命令：
SHOW ENGINE INNODB STATUS\G;屏幕上吐出了一大坨像乱码一样的日志。别慌，我们只看LATEST DETECTED DEADLOCK这一节。
1. 核心原理：死锁日志的“三段式”结构
死锁日志记录的是案发那一刻的快照。它通常由三部分组成：
1.事务 (1) (TRANSACTION 1):“受害者”或者“凶手”之一。它手里拿着什么锁，正在等什么锁。
2.事务 (2) (TRANSACTION 2):另一个“凶手”。它手里拿着什么锁，正在等什么锁。
3.判决结果 (WE ROLL BACK TRANSACTION):MySQL 的裁判（死锁检测器）决定杀掉哪个事务来打破僵局。
2. 实战解码：经典“AB-BA”死锁
这是最容易读懂的死锁类型。
日志片段还原：
------------------------ LATEST DETECTED DEADLOCK ------------------------ *** (1) TRANSACTION: TRANSACTION 12345, ACTIVE 5 sec starting index read mysql tables in use 1, locked 1 LOCK WAIT 3 lock struct(s), heap size 1136, 2 row lock(s) MySQL thread id 100, OS thread handle ..., query id ... # 注意：这里显示的是事务 1 正在尝试执行的 SQL UPDATE accounts SET balance = balance - 100 WHERE id = 1 *** (1) WAITING FOR THIS LOCK TO BE GRANTED: # 事务 1 正在等 ID=1 的 X 锁（排他锁） RECORD LOCKS space id 54 page no 4 n bits 72 index PRIMARY ... trx id 12345 lock_mode X locks rec but not gap waiting Record lock, heap no 2 PHYSICAL RECORD: n_fields 3; compact format; info bits 0 0: len 4; hex 80000001; asc ;; -- 这里 hex 1 代表 ID=1 *** (2) TRANSACTION: TRANSACTION 12346, ACTIVE 3 sec starting index read ... # 事务 2 正在尝试执行的 SQL UPDATE accounts SET balance = balance + 100 WHERE id = 2 *** (2) HOLDS THE LOCK(S): # 事务 2 手里已经拿到了 ID=1 的 X 锁！ RECORD LOCKS space id 54 page no 4 n bits 72 index PRIMARY ... trx id 12346 lock_mode X locks rec but not gap Record lock, heap no 2 PHYSICAL RECORD: n_fields 3; compact format; info bits 0 0: len 4; hex 80000001; asc ;; -- 又是 ID=1 *** (2) WAITING FOR THIS LOCK TO BE GRANTED: # 事务 2 正在等 ID=2 的 X 锁 ... hex 80000002 ... *** WE ROLL BACK TRANSACTION (1)侦探分析：
1.看
HOLDS THE LOCK(S):事务 2 持有 ID=1 的锁。2.看
WAITING FOR THIS LOCK:事务 1 想要 ID=1 的锁（被阻塞）。事务 2 想要 ID=2 的锁。3.推导逻辑：
•事务 1:已经锁住了 ID=2 (虽然日志没显式写它持有，但因为它在等 ID=1，且形成了死锁，说明它手里必有筹码)，现在想锁 ID=1。
•事务 2:已经锁住了 ID=1，现在想锁 ID=2。
4.结论：典型的资源顺序冲突。
• 线程 A：
Lock(2) -> Lock(1)• 线程 B：
Lock(1) -> Lock(2)
实战场景：两个用户互相转账。
3. 进阶解码：看不懂的“间隙锁” (Gap Lock)
很多时候，你发现日志里只有INSERT语句，并没有 Update，为什么也会死锁？
这时候要关注关键词：lock_mode X locks gap before rec或insert intention。
日志片段还原：
*** (1) TRANSACTION: INSERT INTO users (id, name) VALUES (10, 'Alice') *** (1) WAITING FOR THIS LOCK TO BE GRANTED: RECORD LOCKS ... index PRIMARY ... # 注意关键词：insert intention (插入意向锁) lock_mode X locks gap before rec insert intention waiting *** (2) TRANSACTION: INSERT INTO users (id, name) VALUES (10, 'Bob') *** (2) HOLDS THE LOCK(S): # 注意关键词：locks gap before rec (间隙锁) RECORD LOCKS ... index PRIMARY ... lock_mode X locks gap before rec侦探分析：
1.场景：这是一个
INSERT导致的死锁，通常发生在唯一索引冲突或范围删除后。2.解读：
•事务 2持有一个Gap Lock（间隙锁）。这通常是因为它之前执行了一个
DELETE FROM users WHERE id > 5或者SELECT ... FOR UPDATE，锁住了一片范围。•事务 1想要在这个范围内
INSERTid=10。插入操作需要获取Insert Intention Lock（插入意向锁）。•规则：插入意向锁会被间隙锁排斥。
3.隐形杀手：如果事务 2 自己也想在这个间隙里插入数据，或者两个事务同时对同一个不存在的记录加锁（
SELECT * FROM t WHERE id = 10 FOR UPDATE），就会形成死锁。
实战场景：
•并发初始化数据：两个线程同时检测到数据不存在，同时执行插入（
INSERT IGNORE或INSERT ... ON DUPLICATE KEY）。•消息队列消费：多个消费者同时处理幂等逻辑。
4. 关键术语对照表 (Rosetta Stone)
读日志时，只要看懂这几个词，能解决 90% 的问题：
术语 | 含义 | 人话解释 |
lock_mode X | 排他锁 (Exclusive) | “我要改这条数据，谁也别动” |
lock_mode S | 共享锁 (Shared) | “我要读这条数据，你们别改，但可以读” |
locks rec but not gap | 记录锁 (Record Lock) | “我只锁这一行，不锁前后的缝隙” |
locks gap before rec | 间隙锁 (Gap Lock) | “我锁的是这行前面的空隙，禁止插入” |
insert intention | 插入意向锁 | “我想插队，那个拿着间隙锁的大哥让让路？” |
Next-Key Lock | 临键锁 | 记录锁 + 间隙锁（默认级别下的锁） |
5. 总结与行动指南
当你拿到死锁日志后，按照以下步骤行动：
1.找 SQL：在日志里找到
TRANSACTION 1和TRANSACTION 2分别在执行什么 SQL。2.找索引：看
index PRIMARY还是index idx_name，确定是锁主键还是锁二级索引（二级索引死锁非常常见）。3.看模式：
• 如果是AB-BA（互斥锁）：调整代码里的加锁顺序，保证所有线程都按
ID升序加锁。• 如果是Gap / Insert Intention（间隙锁）：优化索引，尽量让 Update/Delete 命中唯一索引（退化为行锁），减少锁的范围。
最后一句忠告：SHOW ENGINE INNODB STATUS只保留最后一次死锁的信息。如果死锁频发，建议开启全局参数innodb_print_all_deadlocks = ON，让每一次死锁都记录到 MySQL 的错误日志（error.log）里，方便事后复盘。
推荐阅读 点击标题可跳转
50个Java代码示例：全面掌握Lambda表达式与Stream API
16 个 Java 代码“痛点”大改造：“一般写法” VS “高级写法”终极对决，看完代码质量飙升！
为什么高级 Java 开发工程师喜爱用策略模式
精选Java代码片段：覆盖10个常见编程场景的更优写法提升Java代码可靠性：5个异常处理最佳实践
为什么大佬的代码中几乎看不到 if-else，因为他们都用这个...
还在 Service 里疯狂注入其他 Service？你早就该用 Spring 的事件机制了
看完本文有收获？请转发分享给更多人
关注「java干货」加星标，提升java技能
❤️给个「推荐 」，是最大的支持❤️.cls-1{fill:#001e36;}.cls-2{fill:#31a8ff;}
.cls-1{fill:#001e36;}.cls-2{fill:#31a8ff;}
