线上OOM问题排查

这段时间公司在搞活动，系统的订单量比平时增加了好几倍，活动开始的第一天下午，业务反馈说系统崩溃了，然后开始排查原因，发现服务并没有挂，只是响应速度异常慢。查看了cpu和内存，发现cpu是正常的，内存也是够用的，说明机器的cpu和内存都没有问题。

top #查看cpu和内存的使用情况

 

然后查看这个服务的堆使用情况,发现老年代已经满了，在频繁fullGC，并且每次fullGC回收的内存都很少。于是找运维重启了服务，重启后服务恢复正常了，先解决问题再找原因。通过监控堆栈的使用情况，发现老年代增长速度很快，如下图，但是每次老年代回收极少，考虑可能存在内存泄漏，服务启动一次只能勉强撑1个小时，然后找运维把堆扩大到(3G),然后设置定时重启，每三个小时自动重启服务，让服务基本保持正常，然后继续抓紧排查问题。

jps  #查看Java进程及pid
jstat -gcutil pid 1000   #1000表示时间间隔

 

S0C：第一个幸存区的大小
S1C：第二个幸存区的大小
S0U：第一个幸存区的使用大小
S1U：第二个幸存区的使用大小
EC：伊甸园区的大小
EU：伊甸园区的使用大小
OC：老年代大小
OU：老年代使用大小
MC：方法区大小
MU：方法区使用大小
CCSC:压缩类空间大小
CCSU:压缩类空间使用大小
YGC：年轻代垃圾回收次数
YGCT：年轻代垃圾回收消耗时间
FGC：老年代垃圾回收次数
FGCT：老年代垃圾回收消耗时间
GCT：垃圾回收消耗总时间

开始想办法排查内存泄漏问题，使用jmap查看占用内存最大的对象，结果不太理想，只看到char，string还有hashmap占用了大量内存。最开始走了些弯路，怀疑代码中是不是hashmap有内存泄漏了，结果找了半天没有找到可疑的地方。

jmap -histo 1 | head -20 #查看占用内存最大的前20个对象

 

那只能把堆dump出来在本地分析，毕竟线上服务不能停，考虑怎么安全地把堆dump出来，想到了用jmap或者是arthas。jmap -dump有个问题，这个命令执行，JVM会将整个heap的信息dump写入到一个文件，heap如果比较大的话，就会导致这个过程比较耗时，并且执行的过程中为了保证dump的信息是可靠的，所以会暂停应用。所以jmap被pass了，于是找运维安装了arthas。

arthas下载地址：curl -O https://arthas.aliyun.com/arthas-boot.jar

#启动arthas
java -jar arthas-boot.jar
#提示选择进程，输入编号选择对应的进程

 

dashboard #查看仪表板

headdump #dump堆栈信息，速度很快，900多M的堆几秒钟就dump完了

 

然后把dump文件下载到本地，开始分析dump文件，分析dump文件常用的工具有jdk自带的jvisualvm,eclipse的MAT，我开始是用jvisualvm分析，效果不理想，可以看到Integer,HashMap占用内存很大，但是也说明不了问题，如下图，后来改用MAT分析，发现这个功能很好用，推荐用MAT分析堆栈

 

使用MAT分析如下，发现org.hibernate.internal.SessionFactoryImpl占用了大量内存，进一步展开这个类，发现是queryCacheplan占用了很多内存，最终在queryCacheplan中找到了罪魁祸首,代码里面写了in查询，结果这个in查询的条件有800多，类似这样的sql还有很多，难怪内存会不断增长，sql语句如下：

select distinct xxxEntity1
from xxxEntity1 xxxEntity1
  inner join xxxEntity2 xxxEntity2 with xxxEntity1.deliveryNo = xxxEntity2.order_No
where xxxEntity.type = ?1 and xxxEntity1.caseNo in (?2, ?3, ?4, ?5, ........ ?864, ?865, ?866)

 

然后找到代码中这个sql语句，优化后重新上线，问题解决了，已经跑了很多天一直很正常。

QueryPlanCache 内存泄漏解决方法

产生的原因： hibernate中的QueryPlanCache会缓存sql，以便于后边的相同的sql重复编译。如果in后的参数不同，hibernate会把其当成不同的sql进行缓存，从而缓存大量的sql导致heap内存溢出。

解决方法： 通过设置缓存最大值来进行限制，不设置默认是2G。

spring:
  jpa:
    properties:
      hibernate:
        query:
          plan_cache_max_size: 64
          plan_parameter_metadata_max_size: 32
          plan_cache_max_soft_references: 1024
          plan_cache_max_strong_references: 64