不能靠“重试”解决，必须用 select for update wait n 显式控制等待边界，确保 where 条件走索引、避免锁升级；因 merge/update 默认无限等待不抛异常，java 重试逻辑失效，仅显式加锁才能触发可捕获的 ora-00054 或 ora-30006 以支撑可控重试。
直接结论：不能靠“重试”解决，必须让锁在业务语义上可预测、可收敛——核心是用 select for update wait n 显式控制等待边界，并确保 where 条件走索引、避免锁升级。
为什么 MERGE 或 UPDATE 会无限阻塞而不报错
Oracle 的 DML（包括 MERGE）默认行为是「无限等待锁释放」，不是超时失败。这意味着 Java 层的 try-catch 捕不到任何异常，重试逻辑完全失效。
-
MERGE INTO ...执行时若目标行已被其他事务加锁，当前会话会静默挂起，直到对方提交或回滚 - JDBC 驱动不会主动中断该等待，除非网络断开或数据库参数
enqueue_resources耗尽 - 你看到的
ORA-00054只会在显式使用NOWAIT或WAIT n时抛出，普通 DML 不触发
SELECT FOR UPDATE WAIT 是唯一可控入口
所有并发更新冲突必须收口到带明确锁语义的查询阶段，否则无法做超时/重试/降级判断。
- 必须用原生 SQL +
PreparedStatement，Hibernate 的setLockMode()在多数版本中不生成FOR UPDATE，不可信 - WHERE 条件字段必须有有效索引，用
EXPLAIN PLAN确认是 INDEX RANGE SCAN，否则可能升级为表锁 - 写法必须是
SELECT ... FOR UPDATE WAIT 3（单位秒），NOWAIT会导致立即失败，不适合生产重试场景 - MyBatis 中需在 XML 写死
FOR UPDATE WAIT 3，且设置fetchSize="1"，防止 JDBC 预取多行扩大锁范围
ORA-30006 和 ORA-00054 的捕获与响应
只有显式加锁才产生可捕获的锁超时信号，这是重试策略的唯一依据。
- 捕获
SQLException后，检查getSQLState()：值为61000表示ORA-30006（WAIT超时），getErrorCode()为54表示ORA-00054（NOWAIT失败） - 对
ORA-30006可做指数退避重试（如 1s → 2s → 4s），但最多 3 轮；超过则降级为异步任务或用户提示“正在排队处理” - 绝对不要在事务里先
SELECT再UPDATE：查到的是旧快照，且没加锁，等于裸奔 - JDBC URL 必须含
oracle.jdbc.readTimeout=0，否则网络抖动可能误杀锁等待
列存表（Columnar Table）要特别警惕 CU 级锁
如果表是列存类型，UPDATE 锁的是整个压缩单元（CU），而非单行——哪怕更新两行不同 ID，只要落在同一 CU 就互斥。
- 用
SELECT ctid FROM table_name WHERE id IN (x,y)查看是否同属一个 CU（ctid格式为(cu_id, offset)） - 列存表不适合高频点更新，频繁
UPDATE会不断生成新 CU，空间膨胀快，锁冲突高 - 确认是列存表后，应优先考虑改用行存表，或批量合并更新减少事务频次
真正难的不是加锁语法，而是把锁的边界和等待时间，变成业务流程里可感知、可决策的一环。很多团队卡在“以为重试能解决问题”，结果只是把阻塞从数据库搬到应用线程池里而已。
