前言
在处理一次现场问题时，发现服务还在运行，但是出现假死情况，后通过分析GC日志以及使用MAT分析确定问题是内存溢出OutOfMemery(OOM)；这里只记录MAT分析学习过程,最近工作忙，补记录。
GC日志分析
首先，如果明确了是哪个服务出现了问题，就可以使用
ps -aux | grep 服务名查看PID,如果是jar启动，在jvm中，则使用：jps 进程号；
如果不能明确，可使用top命令查看cup占用率，来分析是哪个服务内存出了问题；
然后在出现问题时，对堆及内存对象进行快照，可以导出快照dump对它进行分析；
jmap -dump:live,format=b,file=wanfile.dump PID，会导dump问题到当前目录下，你可以指定目录导出。
注意
1、不同的 JAVA虚机的线程 DUMP的创建方法和文件格式是不一样的，不同的 JVM版本， dump信息也有差别。
2、你要确保是快照是能照到出现的问题，不能重启或者问题没发生，就进行快照，这样是找不到问题所在的。
jstack，jmap，jhat使用介绍
用于JVM当前时刻的线程快照，又称threaddump文件，它是JVM当前每一条线程正在执行的堆栈信息的集合。生成线程快照的主要目的是为了定位线程出现长时间停顿的原因，如线程死锁、死循环、请求外部时长过长导致线程停顿的原因。
#1.jstack
jstack <PID>
jstack -F <PID> # 有时候线程挂起的时候要加上-F参数才能把信息dump处理
jstack -F -l pid (查出某个进程中运行的所有线程)
生成进程下所有线程的栈日志：jstack <PID> > test.txt
#2.jmap
#提取进程内存信息，用于分析OOM导致原因如下，其中(format=b是通过二进制的意思）
jmap -dump:format=b,file=HeapDump.bin <pid>
#输出堆信息
jmap -heap <PID>
#jhat简单分析内存中对象情况
#读取dump文件，生成报告，并启动WEB服务器，默认端口为7000
jhat -J-mx768m -stack false HeapDump.bin
回归正题，现在我们已经导出了dump，那么我们使用MAT来对该内存进行分析，
我个人喜好用MAT，你也可以使用JDK自带的jvisualvm，或者有钱的话使用商业JProfil
打开mat，并导入dump
shallow heap 表示对象本身占用内存的大小，也就是对象头加成员变量（不是成员变量的值）的总和。
retained heap
如果一个对象被释放掉，那会因为该对象的释放而减少引用进而被释放的所有的对象（包括被递归释放的）所占用的heap大小，即对象被垃圾回收器回收后能被GC从内存中移除的所有对象之和。相对于shallow
heap，Retained heap可以更精确的反映一个对象实际占用的大小（若该对象释放，retained heap都可以被释放）。
定位问题，该定时任务，定时执行时间过快，涉及到merge into循环操作，对象还创建完，就开始了下一次执行，GC都没回收完，导致内存溢出
