本文档记录工作中发生的一次OOM异常分析

最近线上环境频繁出现OOM异常，导致应用服务器宕机，之前有观察过最近的程序更新，猜测定位到最近的一个接口上，之前发现问题都是打印堆栈信息排查，但是这次发现堆栈信息并不能有效定位到问题点，因此在本次出现OOM的时候直接做dump日志进行问题定位。

首先采用打印堆栈信息

1、通过top命令查找出对应对PID 进程 

2、通过top -Hp pid 查找对应进程的线程  

 3、将第二步的线程PID转换为 16 进制

printf '%x\n' PID  

printf '%x\n'  26011

4、保存线程栈信息

jstack 13731 > thread_stack.log 13731 为第一步的PID

这里有时候可以找到对应的关键信息，但是有时候就会出现如下情况，根本无法定位

"GC task thread#0 (ParallelGC)" os_prio=0 tid=0x00007fbae801e800 nid=0x66a2 runnable 

"GC task thread#1 (ParallelGC)" os_prio=0 tid=0x00007fbae8020800 nid=0x66a3 runnable 

"GC task thread#2 (ParallelGC)" os_prio=0 tid=0x00007fbae8022000 nid=0x66a4 runnable 

"GC task thread#3 (ParallelGC)" os_prio=0 tid=0x00007fbae8024000 nid=0x66a5 runnable 

"GC task thread#4 (ParallelGC)" os_prio=0 tid=0x00007fbae8026000 nid=0x66a6 runnable 

"GC task thread#5 (ParallelGC)" os_prio=0 tid=0x00007fbae8027800 nid=0x66a7 runnable 

"GC task thread#6 (ParallelGC)" os_prio=0 tid=0x00007fbae8029800 nid=0x66a8 runnable 

"GC task thread#7 (ParallelGC)" os_prio=0 tid=0x00007fbae802b800 nid=0x66a9 runnable 

 综上情况，无法定位到问题点，则需要进一步分析

查看GC情况

1、jstat -gcutil <进程ID> 2000 10 会发现新生代和老生代都是100%，而且FULL GC频率很高

2、转dump文件

jmap -dump:live,format=b,file=dump.hprof 28920(进程号)

3、打开MemoryAnalyzer，选择Leak Suspects

 查看detail详情

在Thread Stack定位到具体哪一行代码问题，以及导致问题的原因，本次原因是一个查询条件失效，导致查出的数据在30W，导致内存溢出。