JPA与Hibernate更新同一关联实体时的竞态条件如何规避？

问题根因 #

该场景属于典型的无锁并发更新丢失问题：两个事务同时读取到同一版本的Parent实体，后提交的事务（定时任务）直接覆盖了先提交事务（REST接口）的变更。由于你配置了OneToMany全级联+孤儿移除规则，定时任务提交的旧版本Parent仍携带已被REST接口删除的旧Child，JPA会认为这些Child是需要保留的关联对象，最终导致新旧Child同时存在。

解决方案 #

方案1：添加乐观锁（最推荐，适合绝大多数场景） #

在Parent实体中新增带@Version注解的版本号字段，JPA会自动在更新时校验版本号：

@Entity
public class Parent {
    // 其他原有字段
    @Version
    private Integer version;
}

• 执行逻辑说明：REST接口提交更新后，数据库中该Parent的版本号会自动+1；定时任务拿着旧版本号提交更新时，会触发OptimisticLockingFailureException，更新直接失败，不会覆盖REST接口的变更。
• 配套处理：给定时任务添加乐观锁异常的重试逻辑，异常触发后重新查询最新版本的Parent，再执行业务逻辑修改后提交即可。

方案2：使用悲观行锁（适合冲突频率较高的场景） #

在查询Parent的方法上添加悲观写锁配置，查询时直接锁定对应数据库行，避免两个事务同时修改同一条Parent记录：

@Lock(LockModeType.PESSIMISTIC_WRITE)
@Query("select p from Parent p where p.id = :id")
Optional<Parent> findByIdForUpdate(@Param("id") Long id);

• 执行逻辑说明：先拿到锁的事务会阻塞另一个事务的查询操作，直到前一个事务提交释放锁，后一个事务查询到的一定是最新版本的Parent，不会出现并发修改问题。
• 注意事项：如果是分布式部署，不要使用JVM本地锁，必须使用数据库行锁或分布式锁才能生效。

方案3：原子化REST接口操作（补充优化方案） #

REST接口的核心逻辑是清空旧Child、新增新Child，可以跳过JPA级联逻辑，直接用数据库层面的原子操作实现：

1. 直接执行delete from child where parent_id = :parentId删除所有旧Child
2. 批量插入新的Child记录
3. 最后更新Parent的其他字段
   这种方式相比先查再改的操作，事务执行时间更短，冲突概率更低。

额外建议 #

• 尽量缩小事务粒度，减少事务从查询到提交的间隔时间，从根源上降低并发冲突的概率。
• 如果定时任务的业务优先级低于REST接口，可以给定时任务的更新操作添加前置校验：提交前再查询一次最新的Parent版本号，如果版本号已经变更，直接放弃本次提交或者重试。

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