JPA持久化上下文同一实体多次获取的变更行为规范问询

以下为问题对应的业务代码片段：

private Thing fetchThing(Long id, Owner owner) {
  return em.createQuery("SELECT t FROM Thing t WHERE t.id = :id AND t.owner = :owner")
           .setParameter("id", id)
           .setParameter("owner", owner)
           .getSingleResult();
}

/* Transactional, CMT */
public void mutateThing() {
  var thing1 = fetchThing(123L, myOwner);
  var thing2 = fetchThing(123L, myOwner);

  thing1.setColor("blue");
}

问题1：两次查询返回的thing1是否必然与thing2为同一个Java实例？ #

结论：JPA官方规范不保证thing1 == thing2必然成立，即不强制要求两个引用指向同一个Java实例。
JPA规范仅对持久化上下文的逻辑一致性做约束：在同一个事务绑定的持久化上下文范围内，相同实体类型、相同主键值的托管实体，逻辑上对应同一条数据库记录，一级缓存会基于「实体类型+主键」做记录级的唯一性追踪。但规范从未要求JPA实现必须返回内存地址完全相同的Java对象，对象引用同一性属于厂商实现层面的优化范畴，不是合规性要求。
Hibernate、EclipseLink等主流JPA实现在常规无自动刷新、无自定义拦截器、无特殊代理策略的场景下，确实会返回同一实例，但业务代码绝对不能依赖这个特性做逻辑判断。在查询触发持久化上下文自动刷新、拦截器修改实体加载逻辑、实现启用对象池复用优化等场景下，两次查询完全可能返回不同的对象实例。

问题2：修改持久化规则与冲突处理逻辑 #

2.1 单实例修改的持久化保证 #

对thing1做出的属性修改一定会被同步持久化到数据库。
只要两个实体实例都处于当前CMT事务绑定的托管状态，JPA实现的脏检查机制就会追踪对应主键实体的所有状态变更，不会因为持有的对象引用不同就丢失修改。事务提交前，持久化上下文会把所有追踪到的实体状态变更统一同步到数据库，不存在仅识别某一个引用修改的情况。

2.2 冲突属性修改的处理规则 #

如果分别对thing1和thing2做出冲突属性修改（比如thing1设置color为blue，thing2设置color为red），JPA规范没有定义统一的强制处理逻辑，行为完全由具体JPA实现决定，目前主流实现的处理方案分为两类：

• 严格校验类实现（如部分版本的EclipseLink、OpenJPA）：在持久化上下文检测到同类型、同主键的多个托管实例时，直接抛出持久化异常，终止事务提交，避免不确定的状态覆盖问题。
• 后加载优先类实现（如主流版本的Hibernate）：每次查询返回同ID实体时，会用新查询到的数据库状态覆盖持久化上下文中存储的旧实体快照，最终脏检查时以最后一次加载的实体实例上的属性值为基准执行更新。如果两个实例都存在修改，后加载实例上的属性值会覆盖先加载实例上的同属性修改，最终持久化后加载实例的最终状态。

开发提示：这类冲突处理逻辑是厂商自定义的，不同版本、不同厂商的实现可能存在差异，业务代码应当主动避免在同一个持久化上下文中重复查询同ID实体后分别修改的写法，始终持有单一实体引用完成操作，不要依赖实现的隐式处理逻辑。

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