不能依赖JDBC自动重试死锁，需应用层实现幂等、事务隔离、指数退避的重试逻辑，并统一识别各数据库死锁异常。
在 JDBC 中处理数据库死锁时，**不能依赖 JDBC 自动重试**，因为死锁是数据库层面的并发控制机制触发的异常（如 MySQL 的 Deadlock found when trying to get lock，PostgreSQL 的 40P01 serialization_failure），JDBC 只负责抛出 SQLException。真正的重试逻辑必须由应用层主动实现，且需注意幂等性、事务边界和退避策略。
识别死锁异常
不同数据库抛出的 SQLState 或错误码不同，需针对性捕获：
-
MySQL：SQLState 通常为
40001或45000，更可靠的是检查异常消息是否包含"Deadlock found" -
PostgreSQL：SQLState =
40P01 -
Oracle：SQLState =
61000（ORA-00060）或错误码60 -
SQL Server：错误号
1205
建议封装统一判断方法，避免硬编码字符串匹配：
示例（简化）：boolean isDeadlock(SQLException e) {
String sqlState = e.getSQLState();
int errorCode = e.getErrorCode();
return "40P01".equals(sqlState) || // PG
"40001".equals(sqlState) || // Standard serialization failure
errorCode == 1205 || // SQL Server
errorCode == 60 || // Oracle
e.getMessage().toLowerCase().contains("deadlock");
}设计可重试的事务操作
重试必须包裹在**独立、可重复执行的业务单元**中，且该单元应具备幂等性（例如：基于唯一约束插入、乐观锁更新、状态机推进）。不要在已有事务中嵌套重试——Spring 的 @Transactional 默认不支持重试嵌套。
立即学习“Java免费学习笔记（深入）”；
- 将核心写操作（如扣减库存、更新订单状态）抽成无状态方法，入参明确，不依赖外部 mutable 对象
- 每次重试都开启新事务（显式
Connection.setAutoCommit(false)或通过 Spring 的TransactionTemplate） - 避免在重试逻辑中持有非事务资源（如文件句柄、HTTP 连接），防止泄漏
实现带退避的重试循环
简单 while 循环 + 固定 sleep 容易打爆数据库；推荐指数退避（Exponential Backoff）+ 随机抖动（Jitter）：
- 初始延迟 10ms，每次失败后翻倍（10 → 20 → 40 → 80…）
- 上限设为 500ms，避免长等待影响响应
- 每次延迟加入 ±20% 随机偏移，缓解重试洪峰
- 最大重试次数建议 3–5 次（超过大概率是设计问题，非临时冲突）
int maxRetries = 3;
long baseDelayMs = 10;
for (int i = 0; i <= maxRetries; i++) {
try (Connection conn = dataSource.getConnection()) {
conn.setAutoCommit(false);
// 执行业务 SQL...
conn.commit();
return result; // 成功退出
} catch (SQLException e) {
if (i == maxRetries || !isDeadlock(e)) {
throw e; // 不重试或非死锁，直接抛出
}
long delay = baseDelayMs * (1L << i); // 指数增长
delay += (long) (delay * 0.2 * (Math.random() - 0.5)); // ±10% 抖动
Thread.sleep(Math.max(1, Math.min(delay, 500)));
}
}结合 Spring 的最佳实践
若使用 Spring，优先用 @Retryable（Spring Retry）配合 @Transactional，但注意两点：
-
@Retryable必须标注在 public 方法上，且调用需走代理（不能 self-invocation） - 事务需由被重试方法自身开启（即方法内不假定已有事务），推荐用
TransactionTemplate显式控制 - 配置
include = {DeadlockLoserDataAccessException.class}（JdbcTemplate 抛此类型）或自定义异常分类器
对 JPA 用户，Hibernate 可能将死锁包装为 PessimisticLockException 或 OptimisticLockException，需按实际异常链向上查找根本原因。
