前言
Histogram 直方图，展示堆中所有的额对象
Dominator Tree 占据主要空间的树，列出堆中最大的对象以及他们为什么活着，是谁让它们活着的，它们应该被回收，因为它们是垃圾，所以一直存活导致堆的空间不够，产生OOM
Leak Suspects 内存泄漏的嫌疑人或者是嫌疑对象，包含了一些可能导致内存泄漏的对象，和整个系统的概览
Top Components 列出了使用堆空间大于1%的组件
一般来说只要打开Histogram，Leak Suspects来分析即可
会先打开Leak Suspects来看看是哪个对象导致了内存泄漏
Histogram中Shallow Heap 对象它自己占用的空间，Retained Heap 把这些对象释放之后，可以释放的空间，因为对象是会依赖其他对象的，所以释放之后，有可能有些对象也一起释放了
Metaspace元数据区/PermGen永久区，当碰到这两种溢出的时候，就去找Class对象 类对象
这个空间溢出的时候，一般就是Clas对象没有被正确释放，尤其是ClassLoader
一般看占用内存会看Retained Heap，真正占用的
Heap space堆，溢出的时候，就找占用空间最大的对象
最后Path to GC Roots，顺藤摸瓜地去看代码
在Histogram列表中的List Objects->with outgoing references，点击这一项就列出这个 类 的这些对象指向别人的所有的这个类的对象
List Objects->with incomming references，列出了所有指向这个 类 的对象的 所有对象
Show Object by class，把对象按照类分类
Merge Shortest Paths to GCRoots，这是一个重要的额选项，我们一般用这个选项来分析内存泄漏的可能的原因，这个选项的功能是把对象到GC Roots的路径合并起来，因为有可能很多对象
到GC Roots的路径都是相同的
MetaSpace OOM
Class，也即是元数据区问题，当然元空间也是堆的一部分
一般使用JProfiler去找，进去之后直接按照ClassLoader来分组，找到重复的ClassLoader，然后，GC Roots To Path
如果使用Mat去找，一般直接去找leak Suspects，找到Class嫌疑人，打开Details。还有一些就是去Histogram找，查询Class，还可以使用里面的合并路径
注意:Class一般是被持有了，ClassLoader不消失，那么Class就不消失，所以可以通过Group By ClassLoader开始找，然后找到对象Use Selected Object，
一直找然后Show Path to GC roots，去掉最后一个勾，也就看到是被谁持有了
Heap Space OOM
对象溢出，也就是堆内存问题
一般使用Mat去找，去leak Suspects找到对象最大的嫌疑对象，点击Detail找，或者去Histogram找，只要找List Objects->with outcomming references，看哪个对象把这个对象持有了，然后根据代码
分析到GC Roots 对象即可
注意:一般是某个对象持有的对象太大太多，所以一般是找到最大的对象，看他持有什么最大的，再结合代码分析
