Spring Data JPA 搭配SQL Server时的死锁问题排查与解决

一、核心解决方案 #

1. 强制统一资源访问顺序 #

死锁的核心是循环等待资源，必须确保所有并发请求操作数据库资源的顺序完全一致。比如处理发票时涉及客户表与发票表，所有请求必须先更新客户关联数据，再操作发票表，绝对不能出现部分请求先操作发票表再更新客户表的情况——这是你之前调整顺序可能没做到位的关键点。

2. 最小化事务范围 #

把事务内的非核心操作（如日志记录、第三方通知、异步任务触发）移到事务提交后执行，缩短事务持有锁的时间，减少锁冲突的窗口。比如发票入库成功后，再异步发送通知，而不是把通知逻辑放在事务里。

3. 优化锁粒度与类型 #

• 避免使用表级锁，确保用行级锁；检查Hibernate的锁模式，非必要时用@Lock(LockModeType.PESSIMISTIC_READ)共享锁替代排他锁，降低锁竞争。
• 如果业务允许，用乐观锁（比如版本号字段version）替代悲观锁，适合并发读多写少的场景，避免长时间持有锁。

4. 死锁重试机制 #

死锁属于临时性异常，可在代码中捕获TransactionDeadlockException这类异常后自动重试。比如用Spring的@Retryable指定重试条件，或自定义重试逻辑（限制重试次数3-5次，间隔100ms左右），避免用户感知到异常。

5. 优化数据库索引 #

检查发票处理相关SQL的执行计划，确保WHERE/UPDATE条件字段有有效索引（如客户ID、发票编号）。无索引会导致数据库扫描全表，锁定更多无关行，大幅提升死锁概率。

6. 拆分长事务 #

如果事务中包含远程调用、文件IO等耗时操作，必须拆分：先完成数据库核心操作提交事务，再异步执行耗时操作；或者把大事务拆分为多个小事务，减少锁持有时间。

二、死锁监控方法 #

1. 数据库层面 #

• SQL Server：用sys.dm_tran_deadlocks视图查询历史死锁记录；开启Extended Events捕获死锁事件（轻量且高效），生成死锁图——死锁图会直观展示死锁涉及的进程、资源、SQL语句，是排查根因的核心依据。
• 定期执行DBCC TRACEON(1222, -1)开启死锁日志，日志会写入SQL Server错误日志，方便后续分析。

2. 应用层面 #

• 在捕获死锁异常的代码处，记录详细日志：包括请求参数、事务内执行的所有SQL、线程ID、时间戳，便于定位触发死锁的业务场景。
• 用APM工具追踪事务执行链路，监控锁等待时长、事务执行时长，定位高频死锁的请求路径。

死锁并非无解，通过针对性的资源访问规范、事务优化和监控，完全可以将死锁概率降低到业务可接受的程度。

内容的提问来源于stack exchange，提问作者Alain Cruz