线上服务器oom排查总结

1.oom情况

出现java.lang.OutOfMemoryError: GC overhead limit exceeded  一般是（某个循环里可能性最大）在不停的分配对象，但是分配的太多，把堆撑爆了。

出现java.lang.OutOfMemoryError: Java heap space一般是分配了巨型对象
下面就是出现GC overhead limit exceeded 的实际情况，当时是12000左右的对象，每个对象转json后输出的大小为180KB,结果导致cup特别高，然后服务假死，出现oom，其中CUP指标达到了1000左右

遇到这种情况需要首先看cup、load是否高，然后打印出最好导出线程的快照信息

1.看cup高的命令：top -Hp  进程id,然后将线程PID转化为16进制， printf "%x\n" PID ,之所以转为为16进制是因为堆栈里，线程id是用16进制表示的

2.导出线程快照信息：jstack  进程号

3.看gc回收情况：jstat -gcutil 进程号 间隔时间

4.看上下文切换频率：vmstat -t  间隔时间（秒）

5.用于生成堆转储快照（一般称为heapdump或dump文件）：jmap -dump:live,format=b,file=heap.bin <pid> 生成这个文件也可以在tomcot上进行配置，在oom时自动生成hprof或者dump文件：-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/export/log/risk-manager-magpie.hprof

现公司目前使用的Sauron监控平台，大体截图如下：

6.GC日志回收总结图