结构总览
记住下面名词的解释：
Shallow Heap：代表当前对象占用的内存空间；
Retained Heap：代表当前对象被回收后所能释放的内存空间大小。
一些操作：
List objects -> with outgoing references ：列出包含哪些对象；
List objects -> with ingoing references ：列出被哪些对象包含；
第一行的Regex中都可以填写过滤表达式快速筛选自己想分析的类。
1 Detail
这部分统计了当前堆已使用的总大小
Size: 18.8 MB Classes: 8.3k Objects: 325.8k Class Loader: 119 Unreachable Objects Histogram
总大小: 18.8M 类大小8.3kb 对象:325.8k 类加载器:119k
Unreachable Objects 代表根不可达的对象，即可以被回收的对象，如下图所示，可以发现最大的前几位对象是char[]，String，byte[]和TRNameListHitRecord对象，这是由于压测时请求量太大，生成了大量的TRNameListHitRecord对象，在对象异步入库后被释放导致。
2 Biggest Objects by Retained Size
这部分代表目前应用中最大的几个对象的总大小，这部分的数据可以用来分析应用是否可能发生内存泄漏，留在后面Leak Suspects中介绍。
3 Actions
3.1 Histogram
应用中各个类所占用内存大小的直方图，倒序排列
可以看到NameList类一共有10078个，黑名单和白名单各5000个左右，占用了241872/1024/1024=0.23M，Retained heap大小为725624/1024/1024=0.69M，符合预期。
还可以在第一行的regex里填写条件，此时填写应用的包名，就可以过滤到目前应用中所有对象占用的内存大小，如下图，可以发现，没有什么问题，NameList是黑白名单的缓存信息，其他的数量都很少。
3.2 Dominator Tree
应用中各个对象占比，倒序排列，可以展开某条数据查看其内部具体包含哪些变量及变量的内存占比。第一行的Regex表达式同样可以根据自己的需要进行过滤。
可以发现系统中目前最大的对象为SynMap，它是存储黑白名单的对象，2162040/1024/1024=2.06M，符合预期。
3.3 Top Consumers
分析应用中资源消耗最高的对象（Biggest Object）、类（Biggest Top-Level Dominator Classes）、类加载器（Biggest Top-Level Dominator Class Loaders）及包（Biggest Top-Level Dominator Packages）。
除了包之外，上面三个统计都有一个饼图展示结合一个表格展示。比如展开对象的统计信息如下图所示，同Dominator Tree中统计信息相同。
3.4 Duplicate Classes
发现被不同类加载器重复加载的类，如下图所示，发现都是Lambda相关的，无应用中的类，符合预期。
4 Report
4.1 Leak Suspects
帮助分析应用内存泄漏的工具，结合了饼图与问题列表的形式展示分析结果，可以直接点击问题的Details跳转到具体的问题中进行分析。
本应用怀疑有三个地方有内存泄漏，第一个和第三个是类加载器及线程组
点击第二个problem 的detail 进行查看，可以看到问题详情页中包含五个部分：
1.Description（问题描述）
一个名为SynMap被WebAppClassLoader加载的对象共占用了2162040 bytes（占当前已使用内存的10%）。内存累积在 加载器加载的HashMap$Node实例中。
2.Shortest Paths To the Accumulation Point（问题对象到GC根节点的最短路径）
当前分析出来的问题对象HashMap是用来存储黑白名单缓存的对象，可以看到导GC根节点时经过了SynMap，最终被多个Thread使用。所以此处可以排除非应用中的内存泄漏。
3.Accumulated Objects in Dominator Tree（以当前问题对象为根的Dominator支配树）
此处列出了HashMap的支配树，可以发现它是被SynMap引用且包含了一个大小为16384的数组，点击下图红线的节点，从左边的Attributes中可以查看其具体的属性。
4.Accumulated Objects by Class in Dominator Tree（以当前问题对象为根的Dominator支配树按类的维度分类统计）
这里其实是将上面的支配树中的对象按类汇总了一下，查看相关类占用的内存大小。
5.All Accumulated Objects by Class（所有对象按类的维度统计占用内存分析）
这里不同上面的支配树中的类统计，是将所有该对象中使用到的类进行了汇总统计。发现Char[]占用了最大，其次是Date对象，这里我们只观察下大小即可。
4.2 Top Components
展示了大于1%内存的组件
没有发现跟应用相关的类，我们可以点击第一个进行查看具体的分析。
该详情页面有包含可能的内存浪费分析的，如下图显示有重复字符串分析、空集合分析及集合填充率分析等。本应用没有出现过度使用的空集合及大量低填充率的集合，但是发现有重复字符串的问题。
可以看到问题描述为找到了119个char[]实例，其中至少有10个实例具有相同的内容，总大小为2609832bytes。什么意思呢，就是重复出现最少十次的char[]共有119个，点击Detail进行查看具体重复字符串信息。
这里可以看到所有的重复char[]，如果想看具体的重复信息，选择Histogram中具体的字符串的链接查看。比如我们点击第二个字符串的链接查看，发现字符串中存储的都是我们接口的返回值信息。其他的重复字符串统计也基本是由于压测时大量创建对象造成，这里没什么我们应用内部的问题，可以继续分析其他指标。
（本节详细分析TODO）也有对象软弱引用及实现了finalize方法、map集合碰撞率等的分析。关于soft 和 weak 引用我们大致看一下就OK了，没什么问题就可以，详细的统计可以点击Detail查看。
软引用统计：这里有一共2874个软引用对象。共有21310个对象一共971。9kb被软引用保留在内存中。
弱引用统计：一共有8905个弱引用对象。共有90个对象一共4。2kb被弱引用保留在内存中。
Finalizer 统计：共有409个对象实现了finalize方法。
Map碰撞率分析：检测到一个HashMap对象的碰撞率超过了80%。点击Detail可以查看应用中各个集合的碰撞率，我们点开HashMap，如下图缺失发现了一个对象的碰撞率超过80%，这正是上述统计的那个占用了344byte的Map。
我们想看下这个Map里存储的是什么，点击表中<=0.8的蓝色链接。点击List objects -> with outgoing references可以查看当前的HashMap中存储的是什么。如下图所示，HashMap中存储的为一些TcpEndpoint的对象信息。