Java JDBC无死锁自动重试，需手动捕获SQLState“40001”等异常，结合幂等事务、指数退避重试模板或Spring Retry实现。
Java 中 JDBC 本身不提供死锁异常的自动重试机制，需要开发者手动捕获特定异常（如 MySQL 的 Deadlock found when trying to get lock 或 PostgreSQL 的 SQLSTATE 40001），结合重试逻辑实现。核心是识别死锁、隔离事务、控制重试次数与间隔，并确保业务逻辑具备幂等性。
识别数据库死锁异常
不同数据库抛出的死锁异常类型不同，需针对性捕获：
-
MySQL：通常抛出
SQLException，错误信息含"Deadlock found when trying to get lock"，SQLState 为"40001"或"HY000"；建议优先用 SQLState 判断更稳定。 -
PostgreSQL：SQLState 明确为
"40001"（Serialization Failure），死锁属于该类。 -
Oracle：SQLState
"61000"或错误码ORA-00060。 -
SQL Server：错误号
1205表示死锁牺牲者。
推荐统一通过 SQLException.getSQLState() 或 getErrorCode() 判断，避免依赖模糊的 message 字符串匹配。
封装可重试的事务执行模板
使用模板方法封装事务 + 重试逻辑，避免每个 DAO 方法重复写 try-catch 和 sleep。例如：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
立即学习“Java免费学习笔记（深入）”；
（伪代码示意）- 定义函数接口
TransactionalOperation<t></t>表示带返回值的数据库操作； - 在模板中循环执行，每次用
Connection.setAutoCommit(false)开启事务； - 成功则
commit()并返回结果；失败时检查是否为死锁异常； - 若是死锁且未超重试次数，则
rollback()，按退避策略 sleep（如 10ms → 50ms → 100ms），再重试； - 重试耗尽后抛出原始异常或包装为
DeadlockRetryException。
关键注意事项
- 事务必须短小：长事务增加冲突概率，重试意义下降；尽量减少事务内非 DB 操作（如 HTTP 调用、复杂计算）；
- 业务逻辑需幂等：重试可能多次执行同一逻辑（如扣库存），应通过唯一业务键、状态机或乐观锁保证结果一致；
- 避免无限重试：设置上限（如 3–5 次），并采用指数退避（Exponential Backoff），防止雪崩；
-
不要在连接池连接上调用 setAutoCommit(true/false) 后不恢复：建议使用 try-with-resources 或显式 reset，或改用支持事务管理的框架（如 Spring 的
@Transactional+TransactionTemplate配合自定义RetryOperations）。
简化实践：Spring + Spring Retry（推荐）
若项目已用 Spring，更简洁的方式是：
- 用
@Transactional声明事务边界； - 配置
RetryTemplate，设置SimpleRetryPolicy（最大重试次数）和ExponentialBackOffPolicy； - 注册自定义
RetryPolicy，仅对死锁异常（如 SQLState"40001"）触发重试； - 将数据库操作方法用
@Retryable(value = SQLException.class, include = {...})标记，失败时自动重放。
这样既保持代码清晰，又复用成熟重试能力，避免手写易错逻辑。
