如何追踪Hibernate/JDBC数据库连接内存？Spring Boot内存排查优化

云上老周

2026-6-26

问题描述

我正在开发一个Spring Boot项目，需从2个SQL数据库的5张表（4张在一个库，1张在另一个库）中进行大数据检索并手动关联数据。

通常我使用Stream<SomeClass> streamByOrderById()形式的JPA查询；对于需要显式关联的查询，我会使用@Query注解，示例如下：

@Query("""
    SELECT someClass
    FROM SomeClass someClass
    LEFT JOIN FETCH someClass.joinedClass
    ORDER BY someClass.id
    """)

其中关联类标注有@JoinFormula、@OneToOne或@OneToMany注解。

为避免N+M查询问题，我通过有序查询打开表连接，尽可能使用外连接，然后通过代码关联检索到的实体，步骤如下：

我原以为这种数据检索的内存开销极小，因为我是迭代数据库结果并直接推送到OutputStream，未存储数据，理论上同一时间内存中仅存在数据库返回的某一批数据。

但实际启动检索时，应用内存从闲置状态的约200MB飙升至500MB，之后才开始迭代结果（见截图：data retrieval and memory usage at writing to output stream）。

我们尝试排查内存问题根源，但内存采样仅显示大部分内存被字节数组占用（见截图：memory sample showing most memory tied up in byte arrays）。

我曾以为是Hibernate在Level 1缓存中持久化对象导致，但我们在读取数据库数据时已分离对象，且垃圾回收确实会释放这些对象（写入OutputStream时可见GC峰值，见截图：garbage collectiong while writing to OutputStream）。

我希望尽可能降低内存消耗，以便后续能更安全地集成更多表或数据库。但目前仍无法定位字节数组堆积的原因。

请问如何追踪占用内存的对象/类/方法，或降低内存占用？或者我是否误解了问题，对内存消耗过于敏感？

解决方案与排查思路

一、精准追踪内存占用根源

生成并分析堆转储
- 启动应用时添加JVM参数：-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/to/dump.hprof，或在内存飙升时用jmap命令手动生成：jmap -dump:format=b,file=dump.hprof <pid>。
- 用JDK自带的jvisualvm或Eclipse Memory Analyzer打开堆转储，筛选字节数组（byte[]），查看引用链定位创建它们的类和方法，重点关注：
  - JDBC结果集缓冲区；
  - 序列化时的临时字节数组；
  - Hibernate二级缓存（若启用）；
  - OutputStream的缓冲空间。
实时监控内存分配
- 使用async-profiler或jprofiler做内存分配采样，直接查看哪些方法在频繁创建字节数组，以及数组的大小和生命周期。

优化JPA/Hibernate配置
- 禁用二级缓存：在application.properties设置spring.jpa.properties.hibernate.cache.use_second_level_cache=false，避免实体被全局缓存占用内存。
- 调整查询Fetch Size：在@Query中添加fetchSize参数（如@Query(value = "...", fetchSize = 100)），让JDBC每次拉取更小批次的结果，减少结果集缓冲区占用。
- 使用StatelessSession：若不需要会话缓存，改用StatelessSession执行查询，它不会缓存实体，内存开销更低。
优化数据处理流程
- 流式序列化：如果将实体转成JSON/XML写入OutputStream，直接用Jackson的JsonGenerator或JAXB的流式API写输出，避免先把对象转成字节数组/字符串再写入。
- 调整OutputStream缓冲：若使用BufferedOutputStream，手动设置较小的缓冲大小（如new BufferedOutputStream(os, 8192)），避免默认大缓冲占内存。
- 多库查询按需拉取：确保两个数据库的查询都是流式按需获取结果，不要提前加载全量数据到内存。
验证内存消耗合理性
- 计算单批次数据内存占用：假设单条实体+关联数据占1KB，Fetch Size设为1000，单批次仅约1MB，500MB的占用明显超出合理范围，说明存在未释放的内存堆积。
- 分阶段监控内存：在查询启动前、执行中、写入完成后分别记录内存，定位是查询阶段还是处理阶段导致的内存飙升。

JDBC驱动默认缓存：部分驱动（如MySQL）默认会把全量结果集缓存到内存，即使使用Stream查询。需在JDBC URL中添加参数：useCursorFetch=true&defaultFetchSize=100，强制使用游标分批获取。
Hibernate隐式缓存：即使分离实体，普通Session可能仍持有临时对象，处理完单个实体后及时清理会话。
第三方库内存泄漏：检查序列化、日志等第三方库是否在处理数据时创建大量未释放的字节数组。

内容的提问来源于stack exchange，提问作者Alexander Kirk Jørgensen