必须用ex.geterrorcode() == 60精准捕获ora-00060，该值稳定跨驱动且不受日志截断或国际化影响；需递归getcause()获取根sqlexception，配合getsqlstate()=="61000"增强兼容性，严禁依赖getmessage()字符串匹配。
ORA-00060 必须重试，但不能随便重试——只对可恢复的 DML 事务重试，且必须用 ex.getErrorCode() == 60 判断，别碰 getMessage()。
怎么准确捕获 ORA-00060 而不误判
Oracle JDBC 驱动把错误码固化在 SQLException.getErrorCode() 里：ORA-00060 对应值就是 60，稳定、跨驱动、不受日志截断或国际化影响。而 getMessage() 可能被中间件过滤、被 Spring 包装、被 WebLogic 二次封装，甚至因 trace 开启而变长，靠字符串匹配等于埋雷。
常见误判写法：
-
ex.getMessage().contains("ORA-00060")—— 失效风险极高 -
ex.getSQLState().equals("61000")—— 单独用不够稳，SQLState是 SQL 标准码，部分旧驱动或连接池可能不设或设错
正确做法是双重校验：
- 优先判断
ex.getErrorCode() == 60 - 再补一层
ex.getSQLState().equals("61000")（增强兼容性） - 若异常被包装（如 MyBatis 的
PersistenceException或 Hibernate 的DataIntegrityViolationException），需递归调用getCause()直到找到SQLException
重试逻辑必须限定在事务内可恢复操作
死锁只发生在事务未提交前的 DML 阶段（INSERT/UPDATE/DELETE），不是所有数据库操作都能重试。盲目把整个 service 方法包进 while 循环，会把连接超时、主键冲突、空指针等非死锁异常也重试，反而放大故障。
安全重试的前提条件：
- 当前事务尚未提交或回滚（否则
Transaction is not active） - 操作仅含 DML，不含
SELECT FOR UPDATE以外的查询（纯查不会触发死锁） - 每次重试前必须获取新连接，避免复用已标记
rollbackOnly的连接 - 不能跨事务重试——比如一个方法里先查再更，查的部分不能重试，只重试更新块
推荐结构：把核心 DML 拆成独立无注解方法，由上层手动控制事务 + 重试逻辑，避开 @Transactional 代理失效问题。
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
重试策略要防“重试风暴”，不是越多越好
并发越高，重试越容易引发连锁死锁。简单固定间隔重试（如每 50ms 试一次）会让多个线程在同一毫秒争同一行，加剧竞争。
必须采用带退避的策略：
- 首重试休眠
10–100ms（建议从20ms起） - 后续按指数增长：
Thread.sleep((long) Math.pow(2, retryCount) * 10) - 最大重试次数设为
3，超过则抛出原始异常，交由上游降级或告警 - 重试期间记录日志，带上
retryCount和当前线程 ID，便于定位是否形成重试热点
注意：Spring Retry 默认不重试 checked exception，SQLException 是 checked 的，配置时必须显式声明 include = { SQLException.class }。
RAC 环境下死锁排查不能只看单实例视图
在 Oracle RAC 中，ORA-00060 常源于跨实例的 GES（Global Enqueue Service）层资源争用，v$lock 和 v$session 查不到全貌，alert.log 只记结果，不记路径。
真正关键信息藏在：
- GES trace 文件：
lmd0_*.trc或instX_lm_*.trc（路径由SELECT value FROM v$diag_info WHERE name = 'Diag Trace'查得） - 全局视图：
gv$ges_blocking_enqueue，可暴露跨实例的阻塞链和resource_name1（如TX-000A0001-00000F4C） - 结合
dba_objects反查resource_name1后半段，定位真实表名
如果应用频繁在 RAC 下报 ORA-00060，大概率是多节点事务加锁顺序不一致，此时业务层统一排序（如强制 ORDER BY id）比调优 SQL 更有效。
死锁无法彻底消灭，但可以收敛到可预期、可监控、可重试的范围内。最常被忽略的是：重试前没确认事务状态、重试时复用了脏连接、以及在 RAC 场景下还盯着 v$locked_object 查锁——那里面早就空了。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
