Spring Data JPA 批量 UPDATE 后为什么读到旧值

JPQL 批量 UPDATE 返回了受影响行数，按新名字查询也能找到记录，拿到的实体却仍显示旧名字。如果更新前已经在同一持久化上下文中加载过这个实体，应先检查上下文里的对象有没有同步。

批量 JPQL 更新直接作用于数据库，不会逐个修改已经加载的 Java 实体。再次查询到同一身份的记录时，持久化上下文仍可能交回已有对象。以下适用于 Spring Boot 3.x、Spring Data JPA 3.x 的普通 JPA 事务；先确认更新和读取确实共用持久化上下文，不把所有旧值问题都归为缓存。

flush 把待写入送到数据库，不会刷新对象

下面的局部示例中，Student 有主键 id、字符串属性 firstName 和对应 getter，方法在同一个事务中执行：

Student before = repository.findById(id).orElseThrow();
repository.rename(id, "John");
Student after = repository.findById(id).orElseThrow();

如果 rename() 是 JPQL 批量更新，before 与 after 可能仍是同一个受管理实例。仅给 @Modifying 加 flushAutomatically = true，不会让它的 firstName 自动变成数据库新值。

flush 的作用是把上下文中尚未同步的修改写入数据库。它既不是提交事务，也不是重新加载实体。诊断时要分开核对更新命中数、生成的 SQL、当前实体状态和事务结束后的数据库状态。

批量操作之后需要重新读取，可以先 flush 再 clear

如果这次批量更新之后允许清空当前上下文，Repository 可以这样声明：

import org.springframework.data.jpa.repository.JpaRepository;
import org.springframework.data.jpa.repository.Modifying;
import org.springframework.data.jpa.repository.Query;
import org.springframework.data.repository.query.Param;

public interface StudentRepository
        extends JpaRepository<Student, Long> {
    @Modifying(flushAutomatically = true, clearAutomatically = true)
    @Query("update Student s set s.firstName = :name where s.id = :id")
    int rename(@Param("id") Long id, @Param("name") String name);
}

两个属性默认都为 false。这里先 flush，再执行批量更新，之后 clear。clear 会让该持久化上下文中的所有受管理实体变成脱管对象，不只是本次更新的 Student。

在注入了 Repository 的 Service 中，由外部经过 Spring Bean 调用下面的事务方法。它假定业务只允许按已确认的单个主键更新：

import org.springframework.transaction.annotation.Transactional;

@Transactional
public String renameAndRead(Long id, String name) {
    int changed = repository.rename(id, name);
    if (changed != 1) {
        throw new IllegalStateException("Expected one student");
    }
    Student fresh = repository.findById(id).orElseThrow();
    return fresh.getFirstName();
}

@Modifying 不会自动建立事务。这里由 Service 提供事务，Repository 的更新参与它；不要把这段方法放进普通对象再直接调用。多租户项目还须保留实际的租户和权限条件，示例的单主键查询不能替代这些约束。

清空后要使用重新读取的 fresh。原来的 before 引用不会被原地刷新，继续调用 before.getFirstName() 仍可能看到旧值。clear 之后对旧对象改字段，也不会像受管理实体那样自动在提交时写回。

清空整个上下文前，确认未保存的更改怎么处理

只设置 clearAutomatically = true 可能丢掉尚未 flush 的实体更改。配合 flushAutomatically = true 可以在批量查询前同步这些更改，但这也会把上下文中其他待写入的工作一起送到数据库，可能触发约束检查；它不是“只处理当前那一行”的开关。

如果业务只修改一个已经加载的实体，直接通过它的 setter 修改，再由正常脏检查同步，往往更适合原来的对象生命周期。确需批量更新、又必须保留某个受管理引用时，可以按事务设计使用 EntityManager.refresh(entity) 从数据库重载该对象，但 refresh 会覆盖它尚未同步的字段更改；不要在不清楚这些更改用途时调用。

批量更新还不能直接当成逐个实体更新的替代品。需要实体回调、版本字段或并发冲突检查的业务，应单独核对这些语义是否被保留。

验收既看新值，也看旧引用和其他待写入对象

在隔离数据中覆盖“先加载再批量更新”和“直接批量更新再读”两条路径，检查更新范围与重新读取的字段。同时准备一个有待写入更改的其他实体，确认 flush 和 clear 的影响符合业务预期；验证结束后，再从新的事务或连接读取最终数据。

不要为了让测试看到新值就关闭测试回滚。测试事务是否提交，与当前上下文是否持有旧对象是两件事。若清空后在新事务中仍读到旧值，应继续检查更新实际命中情况、事务提交、读取数据库及其他缓存层。保留原查询和上下文处理代码；回退注解不会撤销已经提交的批量修改。