答案：数据库死锁由多个事务循环等待锁资源引发，可通过统一操作顺序、缩短事务范围、批量排序、捕获异常重试、合理配置连接池及监控日志等手段预防和处理。
数据库死锁是Java后端开发中常见的并发问题，通常发生在多个事务相互等待对方持有的锁资源时。要有效解决这个问题，需要从设计、编码和运维多个层面入手。
理解死锁产生的原因
在关系型数据库中，当两个或多个事务彼此持有对方需要的锁，并且都在等待对方释放锁时，就会形成死锁。数据库系统一般会自动检测到死锁并终止其中一个事务（牺牲者），但频繁的死锁会影响系统稳定性和用户体验。
常见场景包括：
- 事务A更新表X后试图更新表Y，同时事务B先更新表Y再试图更新表X
- 不同顺序访问多张表或同表的不同行
- 长事务持有锁时间过长
避免死锁的设计策略
预防比处理更重要。通过合理设计可以大幅降低死锁概率。
立即学习“Java免费学习笔记（深入）”；
- 统一操作顺序：所有业务逻辑中对多张表或同一张表的多行数据进行更新时，按照固定的顺序执行，比如总是先操作用户表再操作订单表
- 减少事务范围：尽量缩短事务生命周期，避免在事务中执行耗时操作（如远程调用、复杂计算）
- 批量操作排序：对一批记录做更新时，按主键或唯一索引排序后再处理，确保加锁顺序一致
- 使用低隔离级别：在可接受的情况下使用READ COMMITTED而非REPEATABLE READ，减少间隙锁的使用
代码层面的优化建议
在Java应用中，可以通过以下方式提升健壮性。
- 捕获异常并重试：当数据库抛出死锁异常（如MySQL的DeadlockLoserDataAccessException），捕获后适当延迟重试事务
- 使用@Retryable注解：结合Spring Retry，在服务层对特定方法配置自动重试机制
- 控制连接池设置：合理配置HikariCP等连接池的最大连接数和超时时间，防止大量阻塞线程堆积
- 显式加锁控制：必要时使用SELECT ... FOR UPDATE但要谨慎，确保锁定范围最小化
监控与运维支持
线上环境应具备及时发现和分析能力。
- 开启数据库的死锁日志（如MySQL的innodb_print_all_deadlocks）
- 定期分析慢查询日志和错误日志
- 通过Prometheus + Grafana监控死锁发生频率
- 利用EXPLAIN分析SQL执行计划，避免全表扫描导致大面积锁争用
基本上就这些。关键是在开发阶段就有意识地规避风险，而不是等到线上出问题再去查。虽然数据库能自动解决死锁，但频繁回滚会影响性能和一致性，所以重在预防和快速恢复。
