记一次IN语句造成的Hibernate QueryPlanCache内存泄漏排查和解决办法-技术圈

如果您使用了Hibernate或Spring data jpa，且SQL中使用了IN语句，且每过一段时间JVM就抛OOM异常，那么这篇文章可能对您有用。

1.问题现象

每过三四天时间，JVM就抛出OOM异常，后台进程挂掉，前端无法访问。

2.问题排查

首先，查找一下后台进程的进程号

    ps -ef | grep "程序名"

然后，使用jmap命令生成内存镜像文件

     jmap -dump:live,format=b,file=heap.hprof 4447

最后，使用 MAT 对内存镜像文件进行分析，分析结果如下图所示：

从Problem Suspect 1 中可以看出一个SessionFactoryImpl类型的实例占用了93.14%的内存。点击Details，可以看到SessionFactoryImpl类中有一个queryPlanCache对象，占用了大量的内存。

百度了一下queryPlanCache内存泄漏，找了一篇和我问题相似的文章《Hibernate sessionFactoryImpl QueryPlanCache 内存过大导致内存泄漏》。文章提到了QueryPlanCache会缓存sql，以便于后边的相同的sql重复编译，如果in后的参数不同，hibernate会把其当成不同的sql进行缓存，从而缓存大量的sql导致heap内存溢出。

2.解决方案

第一种方法是添加配置，现在缓冲的sql数量最大为64（但是我用的spring 1.57.release版本添加该配置没有用）

    spring:
    
  jpa:
    
    properties:
    
      hibernate:
    
        query:
    
          plan_cache_max_size: 64
    
          plan_parameter_metadata_max_size: 32

所以，我对SQL进行了改写，之前我的SQL逻辑是这样的

    # 1.从TOPIC_TOPIC_TYPE表中将帖子类型为1的帖子ID找出来
    
SELECT DISTINCT t.topic_id FROM TOPIC_TOPIC_TYPE t WHERE t.type_id=1
    
# 2.从TOPIC表中按帖子ID进行查询
    
SELECT * FROM TOPIC t WHERE t.id IN ?;

使用子查询进行优化，优化后没有再出现内存泄漏问题。

    SELECT * FROM TOPIC WHERE id IN (
    
SELECT DISTINCT topic_id FROM TOPIC_TOPIC_TYPE WHERE type_id=1
    
);

但是后面使用EXPALIN发现，IN语句走的是全表扫描，性能比较低，所以又用JOIN进行了优化。

    SELECT * FROM TOPIC t1 JOIN TOPIC_TOPIC_TYPE t2 ON t1.id=t2.topic_id AND t2.type_id=1;