JPA多对一关联下无@Version父实体的乐观锁异常问题

我正在开发一个包含高吞吐量实体（需缓解竞态条件）和极少变更领域实体的应用，为此给现有系统添加了JPA乐观锁。

实体代码示例 #

@Entity
public class Payment {
    @Id
    protected Long id;
    @Version
    protected Long version;

    protected String lastStatus; //需保护避免并发修改的字段
    @ManyToOne
    protected Channel inputChannel;

    //其他字段
}

@Entity
public class Channel {
    @Id
    protected Long id;
    //极少变更（几乎不变），无@Version属性
}

乐观锁的使用场景是：当远程系统响应与异步超时在多节点/线程同时发生时，确保仅一个事务成功，避免悲观锁的开销。应用采用Controller(Request)-Manager(DTO)-Repository(Entity)架构。

但存在一个通用更新方法，可更新Payment的几乎所有字段，包括关联的Channel（按功能约束，此操作不会有竞态问题）：

业务逻辑代码 #

@Transactional
public class PaymentManager {

    public void update(PaymentDto dto){
        var payment = repository.findById(dto.getId()).orElseThrow();
        //执行所有更新操作，包括修改Channel关联

        if (dto.getInputChannel() != null && dto.getInputChannel().getId() != null) {
            payment.setInputChannel(channelRepository.getReferenceById(dto.getInputChannel().getId()));
        }        

        repository.save(payment);
    }

    @Retryable
    public boolean upgradeStatus(Long paymentId, Status expectedStatus, Status newStatus) {
        var payment = repository.findById(paymentId).orElseThrow();
        if (!expectedStatus.name().equals(payment.getLastStatus())) {
            return false;
        }
        payment.setLastStatus(newStatus.name());
        repository.save(payment);
        return true;
    }
}

public class PaymentRepository extends JpaRepository.... {

    @Lock(LockMode.OPTIMISTIC)
    Optional<Payment> findById(Long id);
}

为简化操作，我给findById方法添加了乐观锁，但现在出现问题：Hibernate似乎会对Channel实体也执行乐观锁检查，触发空指针异常。调试发现，调用findById时，Payment和Channel的EntityVerifyVersionProcess都被添加到预提交动作列表，推测是@Lock注解导致。Channel是近乎不可变的实体，我的应用不会修改其内容，Hibernate未识别这一点。

[更新] 经测试，问题与Channel更新无关，仅Payment中存在Channel关联就会触发异常。

• 此行为是否符合JPA规范？是否子父关联的所有依赖实体都需添加锁？
• 有没有标准方式告知JPA，加载Payment时不对Channel关联执行锁检查？
• 这是否是Hibernate未检测到Channel不可锁仍执行验证的Bug？

1. 是否符合JPA规范？ #

JPA规范里，当使用LockModeType.OPTIMISTIC（或OPTIMISTIC_FORCE_INCREMENT）时，会对当前事务加载的、处于持久化上下文的所有实体执行版本检查——只要是事务中被访问的关联对象，不管有没有被修改。不过规范并没有强制要求关联实体必须有@Version字段，Hibernate的这种处理属于自身实现逻辑，严格来说不算违反规范，但确实超出了常规预期。

2. 如何避免对Channel执行锁检查？ #

有几种标准可行的方式：

• 调整关联加载策略：将@ManyToOne的fetch设为FetchType.LAZY，并确保事务中不会触发Channel的加载（比如仅操作Payment的非关联字段时）。如果必须加载Channel，可使用动态实体图明确指定只加载Payment自身字段，不加载关联的Channel：

  @EntityGraph(attributePaths = {})
  @Lock(LockMode.OPTIMISTIC)
  Optional<Payment> findById(Long id);
  

• 拆分锁策略的查询方法：不要给通用的findById加@Lock，而是单独定义带乐观锁的查询方法，仅在需要的业务场景（比如upgradeStatus）调用：

  // 仅在状态更新时使用的带锁查询
  @Lock(LockMode.OPTIMISTIC)
  Optional<Payment> findByIdForStatusUpdate(Long id);
  

• 给Channel添加空版本字段：如果不想修改查询逻辑，可给Channel添加@Version protected Long version;，因为实体几乎不变，这个字段不会实际被更新，只是用来避免Hibernate的空指针异常，属于妥协但有效的方案。

3. 是否属于Hibernate的Bug？ #

不算严格意义上的Bug，而是Hibernate对JPA乐观锁实现的“过度严谨”。JPA规范仅要求对被修改的实体执行乐观锁验证，但Hibernate的实现会对事务中加载的所有关联实体都做版本检查，不管是否被修改。当关联实体没有@Version字段时就会触发空指针，这是Hibernate的设计选择，而非违反规范，因此官方不会将其标记为Bug。

内容的提问来源于stack exchange，提问作者usr-local-ΕΨΗΕΛΩΝ