这段时间公司在搞活动，系统的订单量比平时增加了好几倍，活动开始的第一天下午，业务反馈说系统崩溃了，然后开始排查原因，发现服务并没有挂，只是响应速度异常慢。查看了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

一、短信预警
某天下午风和日丽，下午五点钟早早的就发版上线。七点准备下班的时候突然收到短信预警，项目OOM了，wtf ！！！

二、问题排查
1、出现OOM问题了，脑袋里第一反应就是项目中出现内存泄露或者内存溢出了。先登录ELK，根据关键词 “java.lang.OutOfMemoryError” 进行搜索，果然发现有OOM错误日志。

org.springframework.scheduling.quartz.JobMethodInvocationFailedException: Invocation of method 'run' on target class [class com.kingdee.finance.data.credit.ydreport.task.YdReportAppendixInfoTask] failed; nested exception is java.lang.OutOfMemoryError: Java heap space
    at org.springframework.scheduling.quartz.MethodInvokingJobDetailFactoryBean$MethodInvokingJob.executeInternal(MethodInvokingJobDetailFactoryBean.java:266)
    at org.springframework.scheduling.quartz.QuartzJobBean.execute(QuartzJobBean.java:75)
    at org.quartz.core.JobRunShell.run(JobRunShell.java:213)
    at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:557)
Caused by: java.lang.OutOfMemoryError: Java heap space
    at java.util.Arrays.copyOf(Arrays.java:3332)
    at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:137)
    at java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:121)
    at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:622)
    at java.lang.StringBuffer.append(StringBuffer.java:383)
    at java.net.URLEncoder.encode(URLEncoder.java:271)
    at com.longsec.http.HttpConnection.httpPostWithJSON(HttpConnection.java:548)
    at com.kingdee.finance.data.credit.ydreport.service.impl.YdCreditAppendixInfoHandler.sendRequest(YdCreditAppendixInfoHandler.java:151)
    at com.kingdee.finance.data.credit.ydreport.service.impl.YdCreditAppendixInfoHandler.handleAppendixRequest(YdCreditAppendixInfoHandler.java:46)
    at com.kingdee.finance.data.credit.ydreport.service.impl.YdCreditAppendixInfoHandler$$FastClassBySpringCGLIB$$a4a2cc16.invoke(<generated>)
    at org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:204)
    at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(CglibAopProxy.java:736)
    at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:157)
    at org.springframework.transaction.interceptor.TransactionInterceptor$1.proceedWithInvocation(TransactionInterceptor.java:99)
    at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:282)
    at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:96)
    at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
    at org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:671)
    at com.kingdee.finance.data.credit.ydreport.service.impl.YdCreditAppendixInfoHandler$$EnhancerBySpringCGLIB$$e0cc861a.handleAppendixRequest(<generated>)
    at com.kingdee.finance.data.credit.ydreport.task.YdReportAppendixInfoTask.handleAppendixInfoTask(YdReportAppendixInfoTask.java:56)
    at com.kingdee.finance.data.credit.ydreport.task.YdReportAppendixInfoTask.run(YdReportAppendixInfoTask.java:43)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:497)
    at org.springframework.util.MethodInvoker.invoke(MethodInvoker.java:265)
    at org.springframework.scheduling.quartz.MethodInvokingJobDetailFactoryBean$MethodInvokingJob.executeInternal(MethodInvokingJobDetailFactoryBean.java:257)
    ... 3 more

2、根据OOM堆栈错误日志，去扫了一眼代码并未看出什么问题。既然代码没有明显的内存泄露迹象，只能把目光转向堆内存对象分析了。

3、从服务器上导出堆内存溢出的dump文件，用mat 打开分析一波。

可以看到一个StringBuffer占了400M，另一个String对象占了224M，堆内存溢出跟这两个对象脱不了干系。搜索了下代码发现项目中出现问题的地方并没有用到StringBuffer这个类，应该是某个jar里有引用到的。点击String对象，看看value。

4、根据String 对象的值，推测这是一个json格式的参数。用“username”和“businessNumber” 在代码中搜索。

这段代码就是组装请求参数，上面224M的String对象就是由这段代码产生。但出现400M的StringBuffer对象才是导致OOM的元凶，需要继续追查。




整理出代码的调用关系，packRequestJson —> sendRequest —> HttpConnection.httpPostWithJSON —> URLEncoder.encode。很显然StringBuffer对象是由jar包中的URLEncoder.encode 方法中产生，这也跟日志中的堆栈日志正好也能对应上。

三、问题原因
根据上面分析以及查看代码，得知定时任务一次拉取 300条记录批次处理，组装参数得到一个224M 大小的String对象，然后在HTTP请求发送之前经过 URLEncoder.encode 方法 产生了一个400M大小的StringBuffer，直接导致了“java.lang.OutOfMemoryError” 异常。

四、解决方案
400M的大对象是由于一次取出300条记录，参数拼接生成的。可以将批处理记录数调小一点，就可以解决问题，批处理记录数应从数据配置中获取。

四、总结
1、线上异常预警，首先要查看项目日志。根据错误日志，来判断问题出现原因。确定好问题排查方向再选择相应的工具进行分析，多角度的观察，抽丝剥茧，直到找到问题的根源。

2、问题排查要熟悉Java应用排查问题常用工具，比如：jstack、jmap、jps。
查看某个应用的进程id以及启动参数：jps -v | grep “xxx”
dump堆内存：jmap -dump:live,format=b,file=/heapdump.hprof {pid}
导出线程栈：jstack {pid} > /jstack.txt