一次应用程序JVM发生OOM的排查

上次项目碰到碰到一个问题：应用启动正常，但3-6天后会突然停止。起初怀疑是服务器断电或有定时脚本导致的，经排查/var/log/dmesg（内核日志）、/var/log/secure（登录系统记录）、/var/log/message（系统开机错误）等，基本排除人为或定期脚本原因。于是怀疑是JVM内存泄漏导致分配内存耗尽，从而进程停止。

起初,在启动程序时增加JVM启动参数，配置了  -XX:+HeapDumpOnOutOfMemoryError,但因应用自动停机的周期有点长，有时并未输出日志，并且有输出的日志中heap对象超级多，分析判断困难。

为监视进程的内存情况，计划在启动进程后，导出进程堆中对象数据留档，每天分析两次，比较其中对象是否有持续大量增加的，主要有以下操作：

1.jmap -histo [pid]，观察分析其中可疑的对象（持续增长并占用大量内存）；

2.jmap -dump:live,formate=b,file=xxx.bin [pid] （即应用程序的进程号）,将文件导出，为避免干扰开发服务器运行，将其移到合适的主机上，用jhat xxx.bin运行，然后在浏览器端(http://localhost:7000)观察分析内容,主要点击最下端的统计“show heap histogram”来查看分析：

用第1步分析出的对象名称，从文件中搜索对应的线程等信息；

3. top -P [pid] -H 查该进程包含哪些自线程

jstack [pid]|grep A10 输出该线程的子进程，并通过 printf "%x\n" num 得到子线程的十六进制数，用该十六进制数 到第2步的*.bin文件中搜索对应的进程信息，要是与第1步中分析出对象名称有关联关系，基本可以确认是该线程运行过程中生成了这些巨量对象。

4.分析代码，找到代码写法的问题，基本是与死循环有关（对象生成后从未释放，或后期接口调用卡顿导致生产幅度超出GC的能力，奔溃前发生高频GC，最后内存耗尽）。