先说一个直接的结论：不要指望仅靠 Java 重试机制来解决 Oracle 锁超时问题，这种方法基本无效。核心思路是让锁在业务语义层面变得可预测、可收敛——也就是通过 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，可以采用指数退避重试（例如 1 秒→2 秒→4 秒），但最多进行 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，导致空间膨胀快，锁冲突也居高不下。 - 确认是列存表后，应优先考虑改用行存表，或者将更新操作批量合并，减少事务频次，降低锁争用。
真正困难的不是加锁语法本身，而是如何把锁的边界和等待时间，变成业务流程中可感知、可决策的一环。很多团队卡在“以为重试能解决问题”，结果只是把阻塞从数据库转移到了应用线程池里，治标不治本。
