原创：小姐姐味道（微信公众号ID：xjjdog），欢迎分享，转载请保留出处。
大家都知道，在存储用户输入的密码时候，会使用一些hash算法对密码进行加工，比如sha-1、bcrypt。这些信息同样不允许在日志输出里出现，必须做脱敏处理。但是对于一个拥有系统权限的攻击者来说，这些防护依然是不够的。攻击者可能会直接从内存中获取明文数据，尤其对于Java来说，由于提供了jmap一类非常方便的工具，可以把整个堆内存的数据dump下来。比如，“我的世界”一类使用Java开发的游戏，会比其他语言的游戏更加容易破解一些，所以我们在JVM中，如果把密码存储为char数组，安全性会稍微高一些。
这是一把双刃剑，在保证安全的前提下，我们也可以借助一些外部的分析工具，帮助我们方便的找到问题根本。
可以有两种方式来获取内存的快照。我们前面提到，通过配置一些参数，可以在发生OOM的时候，被动dump一份堆栈信息，这是一种。另一种，就是通过jmap主动去获取内存的快照。
jmap命令在Java9之后，使用jhsdb命令替代，它们在用法上，区别不大。注意，这些命令本身会占用操作系统的资源，在某些情况下会造成服务响应缓慢，所以不要频繁执行。
jmap?-dump:format=b,file=heap.bin?37340
jhsdb?jmap??--binaryheap?--pid??37340
1、工具介绍
专业的事情要有专业的工具来做，今天给大家介绍的是一款专业的开源分析工具，叫做MAT。
https://www.eclipse.org/mat/
MAT工具是基于eclipse平台开发的，本身是一个Java程序，所以如果你的堆快照比较大的话，就需要一台内存比较大的分析机器，并给MAT本身加大初始内存，这个可以修改安装目录中的MemoryAnalyzer.ini文件。
可以看一下MAT工具的截图，主要功能都体现在工具栏上。其中，默认的启动界面，展示了占用内存最高的一些对象，并有一些常用的快捷方式。通常，发生内存泄漏的对象，会在快照中占用比较大的比重，分析这些比较大的对象，是我们切入问题的第一步。
点击对象，可以浏览对象的引用关系。这是一个非常有用的功能。
- outgoing references 对象的引出。
- incoming references 对象的引入。
- path to GC Roots 这是快速分析的一个常用功能，显示和GC Roots之间的路径。
另外一个比较重要的概念，就是浅堆（Shallow Heap）和深堆（Retained Heap），在MAT上经常看到这两个数值。
浅堆代表了对象本身的内存占用。包括对象自身的内存占用，以及“为了引用”其他对象所占用的内存。
深堆是一个统计结果，会循环计算引用的具体对象所占用的内存。但是深堆和“对象大小”有一点不同，深堆指的是一个对象被垃圾回收后，能够释放的内存大小，这些被释放的对象集合，叫做保留集（Retained Set）。
如上图，A对象浅堆大小1KB，B对象2KB，C对象100KB。A对象同时引用了B对象和C对象，但由于C对象也被D引用，所以A对象的深堆大小为3KB（1KB+2KB）。
A对象大小（1KB+2KB+100KB）> A对象深堆 > A对象浅堆。
2、内存泄漏检测
如果问题特别突出，可以通过Find Leaks菜单快速找出问题。
如图，展示了名称叫做huge-thread的线程，持有了超过96%的对象，数据被一个HashMap所持有。
对于特别明显的内存泄漏，在这里能够帮助我们迅速定位，但通常内存泄漏问题会比较隐蔽，我们需要更加复杂的分析。
3、支配树视图
支配树视图对数据进行了归类，体现了对象之间的依赖关系。如图，我们通常会根据“深堆”进行倒序排序，可以很容易的看到占用内存比较高的几个对象。点击前面的箭头，即可一层层展开支配关系。
图中显示的是其中的1MB数据，从左侧的inspector视图，可以看到这1MB的byte数组具体内容。
从支配树视图同样能够找到我们创建的两个循环依赖。但它们并没有显示这个过程。
支配树视图的概念有一点点复杂，我们只需要了解这个概念即可。
如上图，左边是引用关系，右边是支配树视图。可以看到A、B、C被当作是“虚拟”的根。支配关系是可传递的，因为C支配E，E支配G，所以C也支配G。
另外，到对象C的路径中，可以经过A，也可以经过B，因此对象C的直接支配者也是根对象。同理，对象E是H的支配者。
我们再来看比较特殊的D和F。对象F与对象D相互引用，因为到对象F的所有路径必然经过对象D，因此，对象D是对象F的直接支配者。
可以看到支配树视图并不一定总是能看到对象的真实应用关系，但对我们分析问题的影响并不是很大。
这个视图是非常好用的，甚至可以根据package进行归类，对目标类的查找是非常快捷的。
编译下面这段代码，可以展开视图，实际观测一下支配树，这和我们上面介绍的是一致的。
public?class?DorminatorTreeDemo?{
????static?class?A?{
????????C?c;
????????byte[]?data?=?new?byte[1024?*?1024?*?2];
????}
????static?class?B?{
????????C?c;
????????byte[]?data?=?new?byte[1024?*?1024?*?3];
????}
????static?class?C?{
????????D?d;
????????E?e;
????????byte[]?data?=?new?byte[1024?*?1024?*?5];
????}
????static?class?D?{
????????F?f;
????????byte[]?data?=?new?byte[1024?*?1024?*?7];
????}
????static?class?E?{
????????G?g;
????????byte[]?data?=?new?byte[1024?*?1024?*?11];
????}
????static?class?F?{
????????D?d;
????????H?h;
????????byte[]?data?=?new?byte[1024?*?1024?*?13];
????}
????static?class?G?{
????????H?h;
????????byte[]?data?=?new?byte[1024?*?1024?*?17];
????}
????static?class?H?{
????????byte[]?data?=?new?byte[1024?*?1024?*?19];
????}
????A?makeRef(A?a,?B?b)?{
????????C?c?=?new?C();
????????D?d?=?new?D();
????????E?e?=?new?E();
????????F?f?=?new?F();
????????G?g?=?new?G();
????????H?h?=?new?H();
????????a.c?=?c;
????????b.c?=?c;
????????c.e?=?e;
????????c.d?=?d;
????????d.f?=?f;
????????e.g?=?g;
????????f.d?=?d;
????????f.h?=?h;
????????g.h?=?h;
????????return?a;
????}
????static?A?a?=?new?A();
????static?B?b?=?new?B();
????public?static?void?main(String[]?args)?throws?Exception?{
????????new?DorminatorTreeDemo().makeRef(a,?b);
????????Thread.sleep(Integer.MAX_VALUE);
????}
}
4、线程视图
想要看具体的引用关系，可以通过线程视图。我们在第5小节，就了解到线程其实是可以作为GC Roots的。如图展示了线程内对象的引用关系，以及方法调用关系，相对比jstack获取的栈dump，我们能够更加清晰的看到内存中具体的数据。
如下图，我们找到了huge-thread，依次展开找到holder对象，可以看到循环依赖已经陷入了无限循环的状态。这在查看一些Java对象的时候，经常发生，不要感到奇怪。
5、柱状图视图
我们返回头来再看一下柱状图视图，可以看到除了对象的大小，还有类的实例个数。结合MAT提供的不同显示方式，往往能够直接定位问题。也可以通过正则可以过滤一些信息，我们在这里输入MAT，过滤猜测的、可能出现问题的类。可以看到我们创建的这些自定义对象，不多不少正好一百个。
右键点击类，然后选择incoming，这会列出所有的引用关系。
再次选择某个引用关系，然后选择菜单“Path To GC Roots”，即可显示到GC Roots的全路径。通常在排查内存泄漏的时候，会选择排除虚弱软等引用。
使用这种方式，即可在引用之间进行跳转，方便的找到所需要的信息。
再给大家介绍一个比较高级的功能。
我们对于堆的快照，其实是一个“瞬时态”，有时候仅仅分析这个瞬时状态，并不一定能确定问题，这就需要对两个或者多个快照进行对比，来确定一个增长趋势。
可以将代码中的100改成10或其他数字，再次dump一份快照进行比较。如图，通过分析某类对象的增长，即可辅助问题定位。
6、高级功能-OQL
MAT支持一种类似于SQL的查询语言OQL（Object Query Language），这个查询语言VisualVM工具也支持。
以下是几个例子，大家可以实际实践一下。
查询A4MAT对象。
SELECT?*?FROM??Objects4MAT$A4MAT?
正则查询MAT结尾的对象。
SELECT?*?FROM?".*MAT"?
查询String类的char数组。
SELECT?OBJECTS?s.value?FROM?java.lang.String?s?
SELECT?OBJECTS?mat.b4MAT?FROM??Objects4MAT$A4MAT?mat
根据内存地址查找对象。
select?*?from?0x55a034c8?
使用INSTANCEOF关键字，查找所有子类。
SELECT?*?FROM?INSTANCEOF?java.util.AbstractCollection?
查询长度大于1000的byte数组。
SELECT?*?FROM?byte[]?s?WHERE?s.@length>1000
查询包含java字样的所有字符串。
SELECT?*?FROM?java.lang.String?s?WHERE?toString(s)?LIKE?".*java.*"?
查找所有深堆大小大于1万的对象。
SELECT?*?FROM?INSTANCEOF?java.lang.Object?o?WHERE?o.@retainedHeapSize>10000
如果你忘记这些属性的名称的话，MAT是可以自动补全的。
OQL有比较多的语法和用法，深入可以参考
http://tech.novosoft-us.com/products/oql_book.htm
一般，我们使用上面这些简单的查询语句就够用了。
OQL还有一个好处，就是可以分享。如果你和同事同时在分析一个大堆，你不必告诉他先点哪一步，再点哪一步，共享给他一个OQL语句就可以了。
如下图，MAT贴心的提供了复制OQL的功能，但是用在其他快照上，不会起作用，因为它复制的是如下的内容。
7、End
我们把问题设定为内存泄漏，但其实OOM或者频繁GC不一定就是内存泄漏，它也可能是由于某次或者某批请求频繁创建了大量对象，所以一些严重的、频繁的GC问题也能在这里找到原因。有些情况下，占用内存最多的对象，并不一定是引起内存泄漏问题的元凶，但我们也有一个比较通用的分析过程。
并不是所有的堆都值得分析的。我们分析在做这个耗时的分析之前，需要有个依据。比如，经过初步调优之后，GC的停顿时间还是较长，我们需要找到频繁GC的原因；再比如，我们发现了内存泄漏，需要找到是谁在搞鬼。
首先，我们高度关注快照载入后的初始分析。占用内存高的topN对象，大概率是问题产生者。
如果不能通过大对象发现问题，就需要对快照进行深入分析。使用柱状图和支配树视图，配合引入引出和各种排序，能够对内存的使用进行整体的摸底。由于我们能够看到内存中的具体数据，排查一些异常数据就容易的多。
可以在程序运行的不同时间点，获取多份内存快照，对比之后问题会更加容易发现。我们还是用一个例子来看。有一个应用，使用了Kafka消息队列，开了一般大小的消费缓冲区，Kafka会复用这个缓冲区，按理说不应该有内存问题，但是应用却频繁发生GC。通过对比请求高峰和低峰期间的内存快照，我们发现有工程师把消费数据放入了另外一个 “内存队列”，写了一些画蛇添足的代码，结果在业务高峰期一股脑把数据加载到了内存中。
上面这些问题通过分析业务代码，也不难发现其关联性。问题如果非常隐蔽，就需要使用OQL等语言，对问题一一排查、确认。
可以看到，MAT工具的上手是有一定门槛的，除了其操作模式，还需要对我们前面介绍的理论知识有深入的理解。比如GC Roots，各种引用级别等。
在很多场景，MAT并不仅仅用于内存泄漏的排查。由于我们能够看到内存上的具体数据，在排查一些难度非常高的bug时，MAT也有用武之地。比如，因为某些脏数据，引起了程序的执行异常。这个时候，想要找到它们，不要忘了MAT这个老朋友。
推荐阅读：
1. 玩转Linux
2. 什么味道专辑
3. 蓝牙如梦
4. 杀机！
5. 架构师BUG，非比寻常