JPA单向自引用@ManyToMany关联持久化异常问题咨询

1. 唯一键冲突异常原因 #

异常由Optional.orElse()的非短路求值特性直接导致：

• orElse()方法的入参是普通表达式，无论Optional实例是否为空，入参逻辑都会被立即执行。
• 原Stream实现中，即使testRepository.findByName(name)已经查到了已存在的测试用例，orElse()内的new Test().setName(name)、testRepository.save()逻辑依然会强制执行，尝试插入同名测试用例，触发name字段的唯一约束报错。
• 替换为for循环+三目运算符后，三目运算符是短路求值：仅当findByName返回空时才会执行新建、保存逻辑，因此不会出现重复插入问题。

若要保留Stream写法，只需将orElse替换为orElseGet即可解决该异常：orElseGet接收Supplier函数式接口参数，仅在Optional为空时才执行传入的持久化逻辑，行为和三目运算符完全一致。

2. Set集合仅持久化单条关联记录原因 #

该问题由两个机制叠加导致：

• 第一，Test实体未重写equals()和hashCode()方法，默认使用Object类基于内存地址的相等性判断逻辑，不符合JPA集合持久化的要求。
• 第二，声明为Set类型的@ManyToMany关联，Hibernate底层会使用PersistentSet实现类包装，持久化中间表记录时需要依赖实体的相等性逻辑完成去重、快照对比操作。
  无调试场景下，调用testRepository.save()保存新实体时，Hibernate仅会将实体加入持久化上下文，不会立刻执行SQL插入、生成主键ID（调试时看到ID提前生成，是IDE查看对象属性时隐式触发Hibernate flush导致的，和正常运行行为不一致）。这些未生成ID的新实体被加入HashSet后，后续Hibernate flush阶段生成ID、完成实体持久化的过程中，会出现HashSet存储寻址异常：HashSet根据元素存入时的hashCode计算存储位置，实体状态变化导致hashCode计算结果改变后，后续迭代集合插入中间表记录时只能识别到最后一个存入的元素，其余关联记录全部丢失。
• List类型的关联底层由Hibernate的PersistentList实现，不依赖元素相等性做去重和快照对比，只要元素存在于集合中就会生成对应中间表记录，因此替换为List后关联持久化恢复正常。

修复方案 #

无需强制替换集合类型、也无需放弃Stream写法，只需做两处调整即可完全解决问题：

• 修正Optional误用，将orElse替换为orElseGet，避免非必要的实体持久化操作：

return requiredTestcasesByName.stream()
    .map(name -> testRepository.findByName(name)
        .orElseGet(() -> testRepository.save(new Test().setName(name))))
    .collect(Collectors.toSet());

• 为Test实体重写基于业务主键（即唯一的测试用例名name字段）的equals()和hashCode()方法，不要使用自动生成的持久化主键id作为相等性判断依据（新实体持久化前id为null，会导致HashSet行为异常）。重写后Set类型的关联即可被Hibernate正确处理，不会出现关联记录丢失问题。

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