无事务（未标记@Transactional）下使用FOR UPDATE SKIP LOCKED的疑问及方案选择

一、无事务场景下FOR UPDATE SKIP LOCKED的实际运作 #

即使函数未标记@Transactional，ORM框架（如MyBatis、JPA）或JDBC也会为单条SQL语句自动创建隐式事务：语句执行时开启事务，执行完成后立即提交。

这种场景下，FOR UPDATE SKIP LOCKED的行锁仅在查询语句执行周期内生效——查询结束事务提交，锁会立刻释放。后续的校验、更新操作都在锁释放后执行，完全无法保证这一系列操作的原子性，其他线程随时可能修改同一行数据。

至于是否需要统一添加该语句？完全没必要。无事务场景下加了也起不到跨SQL的锁定作用，反而会增加数据库锁开销，只有在显式事务范围内，这个锁才能持续到事务结束，配合后续操作实现并发控制。

二、原子性查询-校验-更新场景的方案选择 #

仅添加@Transactional是不够的——默认事务隔离级别下，普通查询不会加行锁，其他线程依然可以修改目标行。你需要将事务控制与行锁机制结合，具体分两种场景：

1. 不需要等待锁，直接跳过已锁定行 #

如果业务允许跳过被其他事务锁定的行（比如任务分发、批量处理场景），需要：

• 给函数添加@Transactional，确保查询、校验、更新在同一个事务中；
• 查询语句使用FOR UPDATE SKIP LOCKED，锁定选中的未被占用行，且锁会持有到事务提交/回滚。

这样整个流程会原子执行，不会被其他线程打断，同时避免线程阻塞等待锁。

2. 必须等待锁，确保处理目标行 #

如果业务要求必须处理特定行（比如用户余额扣减、订单状态更新），不允许跳过，需要：

• 同样给函数添加@Transactional；
• 查询语句使用普通的FOR UPDATE（不带SKIP LOCKED）。

此时若目标行被其他事务锁定，当前事务会阻塞等待锁释放，拿到锁后再执行后续校验和更新，保证操作原子性。

核心结论 #

@Transactional和FOR UPDATE SKIP LOCKED不是二选一的关系：

• @Transactional是保证多步操作原子性的基础，让锁能持续到整个流程结束；
• FOR UPDATE SKIP LOCKED（或FOR UPDATE）是用来在事务中锁定目标行，防止并发修改。

额外注意：尽量缩小事务范围，减少锁的持有时间，避免影响系统并发性能；同时确保事务传播行为符合预期，防止嵌套事务导致锁提前释放。

内容的提问来源于stack exchange，提问作者agingcabbage32