平时做技术实践时，很多问题不是概念不会，而是细节没串起来。拿“数据库死锁的成因与代码规避方案”来说，它看着像小点，放到项目里常会牵出环境、配置、兼容性和维护成本。下面按实际采用顺序，把思路、关键写法和容易踩坑的地方讲清楚，便于大家直接对照操作。
一、什么是数据库死锁
实际处理时，死锁是指两个或多个事务在执行过程中，因争夺锁资源而相互等待，导致所有事务都无法继续推进的状态。数据库通常借助等待图检测死锁，一旦发现环路，就会主动回滚其中一个事务（牺牲者），让其余事务继续执行。因此死锁同时不是“数据库坏了”，而是并发访问下的一种必然可能，关键在于我们能否在代码层面降低发生概率。
在这个场景下，死锁的四个必要条件能够轻松概括为：互斥、持有同时等待、不可剥夺、循环等待。数据库无法消除互斥，但应用代码能够借助统一加锁顺序来打破“循环等待”，这是最有效的规避手段。
二、死锁的典型成因
- 加锁顺序不一致：事务 A 先锁记录 1 再锁记录 2，事务 B 先锁记录 2 再锁记录 1，形成环路。
- 间隙锁与范围更新：在可重复读隔离级别下，范围条件更新会加间隙锁，不同事务的插入位置交叉时容易互相阻塞。
- 长事务持有锁过久：事务中夹杂远程调用、文件 IO 等耗时操作，锁持有时间被放大。
- 索引缺失导致锁范围扩大：没有命中索引的更新会扫描同时锁定大量行，显著提高冲突概率。
三、复现一个死锁场景
从实现思路看，下面用两张账户表模拟，两个事务以相反顺序更新账户，这是最经典的死锁模型。
-- 事务 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 升序加锁，让所有事务的加锁路径一致，从根本上消除循环等待。
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，同时确保更新条件命中索引。
@Transactional(timeout = 3)
public void settleOrder(Long orderId) {
// 事务内只做数据库操作
orderMapper.updateStatus(orderId, "PAID");
stockMapper.deductByOrderId(orderId);
// 通知逻辑放到事务提交后执行
}
-- 为更新条件建立索引，避免全表扫描扩大锁范围
ALTER TABLE orders ADD INDEX idx_user_status (user_id, status);
4.3 失败重试与降级
结合项目来看，死锁被数据库回滚后，业务侧应识别该异常同时进行有限次重试，而不是直接抛给用户。
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 与加锁顺序。再结合慢查询日志确认是否存在长事务或缺失索引。建议在应用层对死锁异常做埋点统计，当某条链路死锁频率上升时及时告警。
从实现思路看，总结来说，死锁无法彻底消除，但借助统一加锁顺序、缩短事务、补齐索引和合理重试，能够把发生概率压到很低，同时让系统在偶发死锁时具备自愈能力。
理解这一步时，总的来说，数据库死锁成因与规避方法适合结合实际项目边做边理解。先抓住核心思路，再逐步补上细节和边界处理，最后效果会更稳定，也更容易复用。