解决 Hibernate 6 中 SELECT 查询的性能瓶颈

本文深入探讨了从 hibernate 5 升级至 hibernate 6 后，select 查询可能面临的性能显著下降问题。该问题主要源于 hibernate 6 在结果集处理中的重复检查机制。文章通过分析其技术根源，并提供了两种实用的临时解决方案：利用流式查询（`getresultstream()`）或通过选择元组来优化数据检索，旨在帮助开发者有效缓解升级后的性能瓶颈，并提及了官方针对此问题的修复进展。

Hibernate 6 SELECT 查询性能下降分析

从 Hibernate 5 升级到 Hibernate 6 后，部分应用程序的 SELECT 查询操作可能会出现显著的性能下降，有时甚至达到十倍以上的延迟。这种现象在处理大量数据（例如数十万条记录）时尤为明显。通过性能分析工具可以发现，Hibernate 6 在执行查询时，大量时间消耗在 org.hibernate.sql.results.spi.ListResultsConsumer.withDuplicationCheck() 方法中。这表明性能瓶颈主要集中在结果集的后处理阶段，特别是 Hibernate 在将数据库结果转换为实体列表时执行的重复性检查逻辑。

这种性能退化是 Hibernate 6 引入的一个已知问题，与编号为 HHH-15133 的 Jira 任务相关。后续的 HHH-15719 和 HHH-15479 等任务也针对此问题进行了跟踪和部分修复，表明 Hibernate 团队正在积极解决这一性能挑战。

以下是一个示例应用程序，它演示了在 Hibernate 5 和 Hibernate 6 环境下，查询 500,000 条 MyEntity 记录时的性能差异：

MyApplication.java

package com.me;

import java.text.MessageFormat;
import java.time.Duration;
import java.time.Instant;
import java.util.Properties;
import java.util.stream.IntStream;

import org.h2.Driver;
import org.hibernate.Session;
import org.hibernate.cfg.Configuration;
import org.hibernate.tool.schema.Action;

public class MyApplication {
    public static void main(final String[] args) {
        Instant start = Instant.now();

        final Properties jpaProperties = new Properties();

        jpaProperties.put("hibernate.connection.url", "jdbc:h2:mem:");
        jpaProperties.put("jakarta.persistence.jdbc.driver", Driver.class.getName());
        jpaProperties.put("jakarta.persistence.schema-generation.database.action", Action.CREATE);

        try (Session session = new Configuration().addAnnotatedClass(MyEntity.class).addProperties(jpaProperties)
                .buildSessionFactory().openSession()) {
            session.beginTransaction();
            IntStream.range(0, 500000).mapToObj(i -> new MyEntity()).forEach(session::persist);
            session.getTransaction().commit(); // 确保事务提交
            printTiming(start, "Setup / Publish");

            start = Instant.now();
            session.createQuery("FROM MyEntity", MyEntity.class).getResultList();
            printTiming(start, "Get");
        }
    }

    private static void printTiming(final Instant startTime, final String label) {
        System.out.println(MessageFormat.format("{0} took {1}", label, Duration.between(startTime, Instant.now())));
    }
}

MyEntity.java

package com.me;

import jakarta.persistence.Entity;
import jakarta.persistence.GeneratedValue;
import jakarta.persistence.GenerationType;
import jakarta.persistence.Id;

@Entity
public class MyEntity {
    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    protected Long id;
}

pom.xml (相关依赖部分)

    
        com.h2database
        h2
        2.1.214
    
    
        jakarta.xml.bind
        jakarta.xml.bind-api
        3.0.1
    
    
    
        org.hibernate.orm
        hibernate-core
        6.1.5.Final
    
    
    

测试结果对比：

• 使用 Hibernate 6.1.5.Final

  Setup / Publish took PT2.6288547S
  Get took PT35.0881315S

• 使用 Hibernate 5.6.14.Final

  Setup / Publish took PT3.486003S
  Get took PT2.3955987S

  从结果可以看出，在 Hibernate 6 中执行 Get 操作（即 SELECT 查询）的时间显著增加，从约 2.4 秒增加到约 35 秒，性能下降了超过 10 倍。

有效缓解性能瓶颈的临时方案

鉴于上述性能问题，在等待官方发布完全修复的版本期间，开发者可以采用以下两种临时方案来缓解性能瓶颈。

LongShot

LongShot 是一款 AI 写作助手，可帮助您生成针对搜索引擎优化的内容博客。

下载

方案一：利用流式查询（getResultStream()）

将查询结果以 Stream 的形式获取，而不是直接获取 List，可以有效规避 ListResultsConsumer.withDuplicationCheck() 方法带来的性能开销。当使用 getResultStream() 时，Hibernate 不会立即将所有结果加载到内存并执行重复性检查，而是允许按需处理数据流。

import java.util.List;
import java.util.stream.Collectors;
import java.util.stream.Stream;

// ... 其他代码 ...

start = Instant.now();
try (Stream stream = session.createQuery("FROM MyEntity", MyEntity.class).getResultStream()) {
    // 如果确实需要 List，可以在此处收集
    List entities = stream.collect(Collectors.toList());
}
printTiming(start, "Get (using Stream)");

注意事项：

• 使用 getResultStream() 返回的 Stream 需要在使用完毕后关闭，推荐使用 try-with-resources 语句来确保资源正确释放。
• 如果最终仍需将所有结果收集到 List 中，虽然 collect(Collectors.toList()) 会在流的末尾执行一次收集操作，但整体性能通常仍优于直接使用 getResultList()。
• 此方法对于需要逐条处理数据或对数据进行进一步流式操作的场景尤其适用。

方案二：选择元组而非直接实体

另一种方法是修改查询，使其返回元组（Object[] 或 Tuple）而不是直接返回实体对象。这会改变 Hibernate 处理结果的方式，有时可以绕过导致性能问题的重复性检查机制。

import java.util.List;

// ... 其他代码 ...

start = Instant.now();
// 查询实体ID和实体本身作为一个元组
List tuples = session.createQuery("select e.id, e FROM MyEntity e", Object[].class).getResultList();
// 如果需要，可以手动将元组转换为实体列表
// List entities = tuples.stream().map(tuple -> (MyEntity) tuple[1]).collect(Collectors.toList());
printTiming(start, "Get (using Tuples)");

注意事项：

• 此方法返回的是 Object[] 类型的列表，其中每个数组元素代表查询结果中的一个字段。例如，tuple[0] 可能是实体 ID，tuple[1] 可能是实体对象本身。
• 你需要手动从 Object[] 中提取所需的数据或实体对象，这会增加一些代码复杂性。
• 这种方法在某些特定场景下可能比流式查询更有效，但通常流式查询更为方便和直观。

官方问题与修复进展

上述性能问题已在 Hibernate 的 Jira 追踪系统中被记录为 HHH-15133。随后的 HHH-15719 和 HHH-15479 等任务也旨在解决相关或衍生的问题。这意味着 Hibernate 官方团队已经意识到并正在努力修复这一核心性能缺陷。开发者应密切关注 Hibernate 的未来版本发布，特别是 6.2.x 或更高版本，这些版本可能包含对 ListResultsConsumer.withDuplicationCheck() 性能问题的永久性修复。

总结与建议

从 Hibernate 5 升级到 Hibernate 6 过程中，SELECT 查询性能下降是一个需要关注的潜在问题，其根源在于 Hibernate 6 结果集处理中的重复检查机制。虽然这是一个已知问题，且官方正在积极修复，但在等待官方补丁发布期间，开发者可以采用以下临时策略：

1. 优先考虑使用 getResultStream()：对于需要处理大量数据的查询，这是最推荐的临时解决方案，因为它能有效避免大部分性能开销，并且在需要时仍能方便地将流转换为列表。
2. 考虑使用元组查询：在特定情况下，如果流式查询效果不佳或不适用，可以尝试查询元组（select e.id, e FROM MyEntity e）来绕过问题。
3. 保持更新：定期检查 Hibernate 的官方发布说明和 Jira 任务，以便在问题得到永久修复后及时升级到最新版本。

在进行升级和性能优化时，务必对关键业务查询进行全面的性能测试，以确保所选方案能够满足应用程序的性能要求。