一、什么是数据库死锁
死锁是指两个或多个事务在执行过程中，因争夺锁资源而相互等待，导致所有事务都无法继续推进的状态。数据库通常通过等待图检测死锁，一旦发现环路，就会主动回滚其中一个事务（牺牲者），让其余事务继续执行。因此死锁并不是“数据库坏了”，而是并发访问下的一种必然可能，关键在于我们能否在代码层面降低发生概率。
死锁的四个必要条件可以简单概括为：互斥、持有并等待、不可剥夺、循环等待。数据库无法消除互斥，但应用代码可以通过统一加锁顺序来打破“循环等待”，这是最有效的规避手段。
二、死锁的典型成因
- 加锁顺序不一致：事务 A 先锁记录 1 再锁记录 2，事务 B 先锁记录 2 再锁记录 1，形成环路。
- 间隙锁与范围更新：在可重复读隔离级别下，范围条件更新会加间隙锁，不同事务的插入位置交叉时容易互相阻塞。
- 长事务持有锁过久：事务中夹杂远程调用、文件 IO 等耗时操作，锁持有时间被放大。
- 索引缺失导致锁范围扩大：没有命中索引的更新会扫描并锁定大量行，显著提高冲突概率。
三、复现一个死锁场景
下面用两张账户表模拟转账，两个事务以相反顺序更新账户，这是最经典的死锁模型。
|
1 2 3 4 5 6 7 8 9 10 11 12 |
-- 事务 A BEGIN; UPDATE account SET balance = balance - 100 WHERE id = 1; -- 此处暂停，等待事务 B 执行 UPDATE account SET balance = balance + 100 WHERE id = 2; COMMIT;
-- 事务 B（与 A 并发执行） BEGIN; UPDATE account SET balance = balance - 100 WHERE id = 2; UPDATE account SET balance = balance + 100 WHERE id = 1; COMMIT; |
执行后数据库会返回类似 Deadlock found when trying to get lock; try restarting transaction 的错误，说明检测到环路并回滚了其中一个事务。
四、代码层面的规避方案
4.1 统一加锁顺序
转账时始终按账户 ID 升序加锁，让所有事务的加锁路径一致，从根本上消除循环等待。
|
1 2 3 4 5 6 7 8 9 |
public void transfer(long fromId, long toId, BigDecimal amount) { long first = Math.min(fromId, toId); long second = Math.max(fromId, toId); // 固定顺序加锁，避免交叉等待 accountMapper.lockById(first); accountMapper.lockById(second); accountMapper.decrease(fromId, amount); accountMapper.increase(toId, amount); } |
4.2 缩短事务并控制锁粒度
把远程调用、消息发送等非数据库操作移出事务边界，事务内只保留必要的 SQL，同时确保更新条件命中索引。
|
1 2 3 4 5 6 7 |
@Transactional(timeout = 3) public void settleOrder(Long orderId) { // 事务内只做数据库操作 orderMapper.updateStatus(orderId, "PAID"); stockMapper.deductByOrderId(orderId); // 通知逻辑放到事务提交后执行 } |
|
1 2 |
-- 为更新条件建立索引，避免全表扫描扩大锁范围 ALTER TABLE orders ADD INDEX idx_user_status (user_id, status); |
4.3 失败重试与降级
死锁被数据库回滚后，业务侧应识别该异常并进行有限次重试，而不是直接抛给用户。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
public void executeWithRetry(Runnable action, int maxRetry) { for (int i = 0; i < maxRetry; i++) { try { action.run(); return; } catch (DeadlockLoserDataAccessException e) { if (i == maxRetry - 1) { throw e; } // 退避后重试，降低再次冲突概率 sleepQuietly(50L * (i + 1)); } } } |
五、排查与监控建议
线上出现死锁时，优先查看数据库的死锁日志（如 MySQL 的 SHOW ENGINE INNODB STATUS），定位具体 SQL 与加锁顺序。再结合慢查询日志确认是否存在长事务或缺失索引。建议在应用层对死锁异常做埋点统计，当某条链路死锁频率上升时及时告警。
总结来说，死锁无法彻底消除，但通过统一加锁顺序、缩短事务、补齐索引和合理重试，可以把发生概率压到很低，并让系统在偶发死锁时具备自愈能力。
