Hibernate结合UNNEST使用时因缓存引发内存泄漏问题咨询

我们的Java服务用Hibernate处理SQS过来的大量消息，对Postgres执行增删改操作。运行一段时间后Pod因内存持续增长挂了，排查发现一个ConcurrentHashMap一直在变大，里面堆了大量org.hibernate.type.descriptor.jdbc.ArrayJdbcType实例。

服务没用到简单的org.springframework.data.repository.Repository方法，而是用自定义查询提升效率，示例如下：

@Modifying
@Query(value =
"""
INSERT INTO my_table (id, key, name)
SELECT id, key, name
FROM UNNEST(:ids\\:\\:uuid[], :keys\\:\\:varchar[], :names\\:\\:varchar[])
"""
, nativeQuery = true)
void insertData(UUID[] ids, String[] keys, String[] names);

这类查询还包括更新、删除操作，上面是简化版。已经确认是这些查询导致Hibernate创建大量typeDescriptors，现在有几个问题：

1. 这种内存增长是否正常？
2. 有没有办法阻止？
3. 执行这类查询，在内存、数据库、服务效率上有没有更优方案？
4. 尝试过创建UserType封装(id,key,name)参数，但遇到不少困难，不确定是否可行，这能不能通过复用类型解决问题？
5. 其他相关建议？

——更新——
已在Hibernate论坛发帖，官方确认这是个bug且已修复，目前等6.6.2.Final版本发布。

1. 内存增长是否正常？ #

完全不正常。Hibernate的类型描述符（TypeDescriptor）本应是全局复用的单例，不会随请求不断创建新实例。这种持续增长属于内存泄漏，是Hibernate的bug导致的，和你用数组参数的自定义原生查询直接相关。

2. 如何阻止该情况？ #

• 根治方案：等待Hibernate 6.6.2.Final及以上版本发布，升级后即可修复该bug；
• 临时规避：
  • 定期重启服务，避免内存持续累积至溢出；
  • 临时替换数组参数的用法，比如把大批次拆成多个小批量单条操作（会牺牲部分效率，仅作过渡用）。

3. 内存、数据库及服务效率的更优方案 #

内存层面 #

• 优先等待官方修复版本，从根源解决内存泄漏；
• 合理配置JVM内存参数（如-Xmx）和Pod内存配额，适配业务批量处理的内存需求。

数据库与服务效率层面 #

• 保留UNNEST批量写法：这种批量操作的效率远高于单条循环执行，Postgres对UNNEST的支持成熟，不要轻易放弃；
• 控制批量大小：把大批次拆为合理的小批次（比如每次处理1000条），平衡效率与资源占用，避免单次请求耗尽数据库连接或内存；
• 监控连接池：确保数据库连接池配置合理，避免批量操作占用过多连接导致服务阻塞；
• 临时替换方案：如果Hibernate的问题暂时无法解决，可直接用Spring JDBC Template执行批量操作，绕开Hibernate的类型处理逻辑，避免内存泄漏。

4. UserType是否可行？ #

理论上可以通过自定义UserType封装复合参数，实现类型描述符复用，但实际操作需要处理Hibernate复杂的类型映射逻辑，成本较高。而且当前问题根源是Hibernate的bug，即使实现了UserType，也无法保证完全规避内存泄漏，不如直接等待官方修复版本更高效。

5. 其他相关建议 #

• 开启Hibernate统计日志，监控类型描述符的创建情况，验证后续版本的修复效果；
• 给Pod配置内存告警，提前感知内存增长趋势，避免服务突然中断；
• 批量操作时添加事务控制，保证数据一致性的同时，避免长事务占用过多资源。

内容的提问来源于stack exchange，提问作者Raziza O