捕获 ORA-00060 死锁必须用 ex.getErrorCode() == 60 主判断，辅以 ex.getSQLState().equals("61000")；重试须限于事务内可恢复 DML，配合指数退避、幂等设计及手动事务控制。
捕获 ORA-00060 死锁异常必须检查 SQLException 的 SQLState 和 ErrorCode
java 里 sqlexception 不是靠 message 字符串匹配来识别死锁的，oracle 驱动返回的 sqlstate 是 "61000"，而 geterrorcode() 是 60。只判断 message 是否包含 "deadlock" 极不可靠——比如日志里有调试语句、数据库开启 trace 后报错信息变长，或者 oracle 版本更新导致提示微调，都会让字符串匹配失效。
- 优先用
ex.getErrorCode() == 60判断，这是最稳定的方式 - 补充校验
ex.getSQLState().equals("61000")，双重保险 - 绝对不要写
ex.getMessage().contains("ORA-00060")，message 可能被国际化或截断
重试逻辑不能直接套在 try-catch 外层写 for 循环
简单用 while + try-catch 包裹整个业务方法，容易把非死锁异常（比如连接超时、主键冲突）也重试，反而放大问题。重试必须限定在明确可恢复的场景内：仅针对死锁，且仅限于当前事务内的 DML 操作（INSERT/UPDATE/DELETE），不能包含 SELECT FOR UPDATE 以外的查询，更不能跨事务重试。
- 重试前确认当前事务未提交或回滚，否则会抛
SQLException: Transaction is not active - 每次重试前要重新获取数据库连接，避免复用已标记为 rollbackOnly 的连接
- 建议用带退避的重试（如指数退避），至少休眠 10–100ms，防止重试风暴加剧锁竞争
if (ex.getErrorCode() == 60) {
Thread.sleep((long) Math.pow(2, retryCount) * 10);
retryCount++;
continue;
}
Spring @Transactional + 自定义重试需绕开事务代理陷阱
如果用 Spring 的 @Transactional 注解，直接在 service 方法上加 @Retryable(value = SQLException.class) 会失败——因为死锁异常发生在事务提交阶段（TransactionSynchronization.afterCompletion），此时代理方法早已返回，AOP 无法捕获。
- 必须把核心 DML 操作拆到独立的、无事务注解的方法中，由调用方手动控制事务和重试
- 或者改用
TransactionTemplate显式管理事务，在 catch 块里主动txTemplate.execute(...) - 注意：Spring Retry 默认不重试 checked exception，
SQLException是 checked 的，需显式配置include = { SQLException.class }
重试次数设为 3 次是经验值，但必须配合业务幂等性设计
死锁本质是并发资源争抢，重试不是万能解药。3 次上限能覆盖绝大多数瞬时竞争，再往上只会拖慢整体吞吐，还可能把系统拖进雪崩边缘。关键在于：重试后的操作必须幂等，否则重复执行会引发数据不一致。
- UPDATE 要带版本号或时间戳条件，例如
UPDATE t SET status='done', ver=ver+1 WHERE id=? AND ver=? - INSERT 要依赖唯一约束（如业务单号+状态组合唯一），而不是靠重试前查一遍再插
- 避免在重试块里生成新 UUID、调用外部 HTTP、发 MQ 消息——这些操作很难回滚或去重
真正难的从来不是捕获 ORA-00060，而是确保每次重试都落在同一笔业务上下文里，且不会因重试引入脏写或漏通知。
立即学习“Java免费学习笔记（深入）”；
