select for update 在 spring boot 中不生效的根本原因是事务未持续持有锁：事务提前提交、代理失效、异常未回滚或自动提交开启均导致锁释放；必须确保 @transactional 显式配置、方法被代理调用、关闭自动提交，并将查询与更新置于同一短事务中。
Oracle SELECT FOR UPDATE 为什么在Spring Boot里不生效？
根本原因不是代码写错了，而是事务没真正“撑住”锁——SELECT ... FOR UPDATE 只在当前数据库事务内有效，一旦事务提前提交或自动关闭，锁立刻释放。Spring Boot 默认的 @Transactional 方法如果没显式声明传播行为、没捕获异常导致事务回滚失败，或者方法被代理绕过（比如同类内调用），都会让锁形同虚设。
常见错误现象：
- 两个请求几乎同时执行
SELECT ... FOR UPDATE，都成功返回结果，后续更新时出现超卖或覆盖 - 日志显示 SQL 执行了，但 Oracle
v$locked_object查不到对应行锁 - 本地调试正常，上测试环境就失效（往往因连接池配置或事务超时不同）
实操建议：
- 确保目标方法是 public + 被 Spring 代理调用（避免 this.xxx() 自调用）
- 事务必须显式标注
@Transactional(propagation = Propagation.REQUIRED)，不要依赖默认值 - 方法内不能有未捕获的 RuntimeException 以外的异常，否则事务可能不回滚，锁也不释放
- Oracle 连接 URL 加上
?oracle.jdbc.autoCommit=false（部分驱动版本需显式关自动提交）
怎么写一个带 FOR UPDATE 的 MyBatis 查询？
MyBatis 不会自动加 FOR UPDATE，必须手动拼进 SQL。它不是注解开关，也不是拦截器能统一加的逻辑——锁语义属于业务意图，必须由开发者明确表达。
使用场景：库存扣减、订单状态抢占、账户余额校验等需要“先查后改且中间不可插入”的操作。
示例（XML 写法）：
<select id="selectForUpdate" resulttype="Stock">
SELECT id, stock, version FROM stock
WHERE product_id = #{productId}
FOR UPDATE
</select>
注意点：
- 不要用
FOR UPDATE NOWAIT除非你准备好处理ORA-00054: resource busy异常并做重试 - 如果表有分区或用了全局索引，确认查询能走索引，否则会升级成表级锁
- MyBatis 的
@Select注解里写FOR UPDATE是合法的，但 IDE 可能报语法警告，可忽略
Oracle 行锁 vs. Spring Boot 事务边界不一致怎么办？
Oracle 的 FOR UPDATE 锁住的是查询返回的**具体行**，但 Spring Boot 的事务生命周期决定了这些锁能 hold 多久。如果事务太长（比如中间调用了 HTTP 外部服务），不仅锁占用时间久，还容易触发 Oracle 的死锁检测或客户端超时。
性能与兼容性影响：
- 高并发下大量行锁争用会导致
enq: TX row lock contention等待事件飙升 - Oracle 11g 默认事务超时是无限制的，但连接池（如 HikariCP）的
connection-timeout会切断物理连接，间接中断锁 - 如果应用启用了读已提交（READ COMMITTED）隔离级别（默认），锁只在事务内有效，不会影响其他事务的 SELECT，但 UPDATE 仍会阻塞
实操建议：
- 把
FOR UPDATE查询和后续 UPDATE 放在同一个@Transactional方法里，且尽量精简事务体（别在事务里发 MQ、调第三方 API） - 考虑加
SKIP LOCKED（Oracle 12c+）避免阻塞：例如SELECT ... FOR UPDATE SKIP LOCKED，适合任务队列类场景 - 监控
v$session_wait中类型为enq: TX的会话，快速定位锁瓶颈
为什么 @Transactional + FOR UPDATE 还是超卖？
最常被忽略的一点：Oracle 的 FOR UPDATE 锁的是「查询命中的行」，不是「条件本身」。如果你用 WHERE status = 'pending' 查询再锁，而多个事务刚好查到不同行，它们各自锁住自己的行，彼此不冲突——但这不代表业务逻辑安全。超卖往往发生在「条件查不到数据，却没做兜底控制」的分支里。
容易踩的坑：
- 查询返回空，代码直接抛异常或跳过，没意识到这代表“资源已被抢走”，应明确返回失败而非静默
- WHERE 条件没走索引，导致锁升级为间隙锁（gap lock）甚至全表锁，性能断崖下跌
- 没配合乐观锁（如
version字段）做二次校验，UPDATE 时 where 条件漏掉版本号，覆盖了别人刚更新的结果
推荐组合用法：
- 先
SELECT ... FOR UPDATE拿到当前行（含 version） - 业务判断通过后，用
UPDATE ... SET version = version + 1 WHERE id = ? AND version = ? - 检查
JdbcTemplate.update()或 MyBatisupdate()返回的受影响行数是否为 1，不是则说明已被他人修改
复杂点在于：锁粒度、事务长度、索引设计、异常路径，四者只要一环松动，本地测十次都对，压测一开就崩。别信“我加了事务和 FOR UPDATE 就万事大吉”。
