java事务锁重试核心是“减少冲突+安全重试+业务兜底”，需精准识别死锁（如mysql sqlstate "40001"）和乐观锁失败异常，避免重试主键冲突等不可恢复错误，推荐spring retry+@transactional组合或自定义模板，严格控制重试次数（3～5次）、指数退避及事务短小幂等。
Java 中事务管理配置合理的锁重试机制，核心不是“加更多锁”，而是“减少锁冲突 + 安全重试 + 业务兜底”。重点在于识别死锁/乐观锁失败这类可恢复异常，并在事务边界内可控地重试，同时避免雪崩、重复扣款、状态错乱等问题。
识别并捕获真正的可重试锁异常
不同数据库的锁失败表现不同，不能靠错误消息字符串匹配（易误判），应统一用标准码判断：
- 死锁牺牲者：MySQL（SQLState "40001" 或 "HY000" + message 含 "Deadlock found"）；PostgreSQL（SQLState "40001"）；Oracle（ORA-00060）；SQL Server（错误号 1205）
-
乐观锁失败：MyBatis-Plus 抛
OptimisticLockingFailureException；JPA 抛OptimisticLockException；Hibernate 抛StaleObjectStateException - 不建议重试的异常：主键冲突、字段校验失败、权限拒绝、连接超时、SQL 语法错误——这些不是锁问题，重试无意义
用模板或框架封装事务+重试逻辑
避免每个 DAO 方法手写 try-catch-sleep-commit-rollbask，推荐两种成熟方式：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
-
Spring Retry + @Transactional 组合：在 service 层方法上同时标注
@Transactional@Retryable(value = {SQLException.class, OptimisticLockingFailureException.class}, maxAttempts = 3, backoff = @Backoff(delay = 100, multiplier = 2))
Spring 会在每次重试前自动 rollback 当前事务，并开启新事务执行方法 -
自定义事务重试模板（适合无 Spring 环境）：
封装一个executeInRetryableTransaction方法，接收ConnectionSupplier和TransactionalOperation<t></t>；内部循环中：获取连接 →setAutoCommit(false)→ 执行业务 → 成功则 commit → 失败则按 SQLState 判断是否死锁 → 是则 rollback + 指数退避 sleep → 继续下一轮
关键参数与行为必须约束
重试不是“多试几次就行”，必须设置硬性边界和退避策略：
- 最大重试次数建议 3～5 次：超过说明系统已持续异常，应快速失败告警，而非继续消耗资源
- 退避间隔用指数增长：如第1次等 50ms，第2次 100ms，第3次 200ms —— 避免大量线程同时重试打爆 DB
- 事务必须短小：单个事务内只做必要 DB 操作，禁用 HTTP 调用、文件读写、复杂计算；长事务不仅增加死锁概率，也让重试成本飙升
- 业务逻辑必须幂等：比如库存扣减，要基于唯一业务单号 + 状态机（“待扣减→已扣减”），或用乐观锁 version 字段，防止重试导致重复扣减
补充：分布式场景下的锁重试协同
若事务涉及 Redis 分布式锁（如秒杀），需注意与 DB 事务重试的配合：
- Redisson 的
tryLock(waitTime, leaseTime)本身含阻塞重试，但其 waitTime 应 小于 DB 事务的重试总耗时，否则 DB 已重试多次，Redis 锁还没拿到 - 不建议在同一个操作里既用 Redis 锁又依赖 DB 死锁重试——二者机制不同、粒度不同，容易互相干扰；优先用一种机制兜底，另一种作辅助校验
- WatchDog 自动续期功能要开启（默认 30s），确保业务执行期间锁不意外过期，避免重试时锁已被他人获取
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
