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日誌回收總結圖
