前言

本文将简要介绍Java线程与内存分析工具VisualVM和MAT的使用，进一步的学习可参考官网或工具帮助(例如MAT：Help -> Welcome -> Tutorials)，并在实际工作中融会贯通。

VisualVM

Java VisualVM是JDK1.6后自带的可视化工具，提供图形界面以实时监控应用程序的线程状态、CPU和内存资源消耗情况，并且可以保存快照以便脱机分析程序的性能瓶颈。

安装与配置

JDK1.6之后已自带VisualVM工具(jvisualvm.exe)。若使用非Oracle JDK，可自行登录官网下载VisualVM并安装。

工具下载后，需要在visualvm_143\etc\visualvm.conf里手工配置JDK路径(visualvm_jdkhome)。

VisualVM可监控本地或远程的Java程序。使用远程监控时需要在服务端启动JMX服务。首先，在远程程序的启动参数中增加如下JVM参数：

-Djava.rmi.server.hostname=10.186.189.98(远程服务器IP地址) -Dcom.sun.management.jmxremote.port=8090(JMX远程监听端口) -Dcom.sun.management.jmxremote.ssl=false(禁用SSL) -Dcom.sun.management.jmxremote.authenticate=false(不启用用户认证)

然后重启远程程序。此时，通过netstat -ano | findstr 8090(Windows)或netstat -anlp | grep 8090(Linux)查看端口已处于Listening状态，表明可以进行远程JMX连接。

除单独使用VisualVM工具外，也可在IDEA中集成VisualVM launcher插件。通过File-> Setting-> Plugins -> Browers Repositrories搜索VisualVM Launcher安装并重启IDEA后，会出现菜单和按钮两种启动方式：

点击按钮后会出现选择VisualVM路径，选择VisualVM可执行文件即可。此后，点击启动会打开一个VisualVM窗口。

本地使用

本节结合代码示例介绍VisualVM的界面功能。示例代码如下：

package thread;

public class InfiniteLoop {

public static void main(String[] args) {

Thread t1 = new Thread(new ImplicitLoop(), "ImplicitLoop");

Thread t2 = new Thread(new ExplicitLoop(),"ExplicitLoop");

t1.start();

t2.start();

}

}

class ExplicitLoop extends Thread {

@Override

public void run() {

while (true) {

System.out.println("I work hard!");

}

}

}

class ImplicitLoop extends Thread {

@Override

public void run() {

for (byte i = 0; i < 150; i += 2) { //此处因数值溢出导致死循环

System.out.println("I've worked " + i + " hours!");

if (i >= 120) {

try {

System.out.println("I'll take a short break...");

Thread.sleep(20);

System.out.println("I wake up!");

} catch (InterruptedException e) {

e.printStackTrace();

}

}

}

}

}

启动VisualVM查看本地监控信息，界面如下：

左侧"本地(Local)"下列出包含InfiniteLoop示例在内的本地Java进程，右侧以概述(Overview)、监视(Monitor)、线程(Threads)、抽样器(Sampler)等页签展示出详细信息。

其中，概述页可查看进程的基本信息、JVM启动参数、系统属性(同jinfo -sysprops )等信息。

监视页可查看CPU、内存(堆与元空间)、类和线程的的实时折线图。执行垃圾回收(Perform GC)按钮可以触发系统GC，堆Dump(Heap Dump)按钮可在指定目录生成堆转储(Dump)文件。

注意，本地监控时点击堆Dump(Heap Dump)按钮会自动加载打开生成的dump文件，而远程监控时需要将远程主机上生成的dump文件拷贝至本地再手工加载。此外，VisualVM加载分析内存Dump文件时非常缓慢，建议使用MAT来分析内存Dump。

线程页可详细查看每个线程的运行时间及状态。线程Dump(Thread Dump)按钮可生成线程dump文件(类jstack )。

图中，时间线里展示活动线程的运行、休眠(sleep)、等待(o.wait)、驻留(空闲)和监视(同步阻塞)状态，并可通过缩放按钮更细致地观察线程状态。

Threads inspector插件可展示单个或多个线程的堆栈。图中仅勾选了ImplicitLoop线程，由堆栈可知其阻塞在System.out.println("I've worked " + i + " hours!")行——执行该方法会先加锁！通过Refresh按钮刷新堆栈，会发现ImplicitLoop线程有时会处于休眠状态。

抽样器页以一定的时间间隔对CPU、内存进行采样，可检查出占用CPU时间较多或占用内存空间较大的线程，有助于性能调优。对CPU采样时，该页提供CPU样例(CPU samples)和线程CPU时间(Thread CPU time)两个子页签，前者可用于分析调用链上的方法耗时，后者可用于比较线程CPU耗时。

VisualVM还提供不少有用的插件，例如Visual GC(查看垃圾回收的状态)。可通过工具(Tools) -> 插件(Plugins)下载插件。

远程监控

在VisualVM左侧点击远程(Remote) -> 添加远程主机(Add Remote Host)，填写服务器IP地址。

然后点击远程主机，右键"添加JMX连接(Add JMX Connection)"，填写JMX端口号并勾选"不要求SSL连接(Do not require SSL)"。

在添加的JMX连接上右键"打开(Open)"或直接双击，在界面右侧可看到监控面板。

MAT

MAT(Memory Analyzer Tool)是一个快速、功能丰富的JAVA堆转储文件分析工具，可帮助开发者发现内存泄漏和减少内存消耗。

使用场景

MAT常见的使用场景如下：

OOM(OutOfMemoryError异常)，原因通常有：

对象已死但无法通过垃圾收集器自动回收，内存不断泄露——需找到泄露的代码位置并加以修复

产生大量生命周期太长或持有状态时间过长的对象——除增大堆分配空间外，考虑优化存储结构或代码逻辑

CPU负载冲高、线程死锁等(类似VisualVM)

窥探内存对象的内容，例如：

排障时环境不允许进行Debug调试或添加日志打印

扫描内存中是否存在常驻的明文口令等敏感信息

安装与配置

从官网下载单机版MAT工具，解压后直接运行MAT目录的MemoryAnalyzer.exe即可启动MAT。

若待分析的dump文件过大，可增大安装目录下MemoryAnalyzer.ini文件里的Xmx参数值(默认1G)。注意，Xmx取值不能大于运行环境的的系统内存，否则MAT启动时会报错Failed to create the Java Virtual Machine。

获得堆转储文件

MAT是一个静态堆分析工具，需要预先抓取Java堆转储文件(内存快照)。

可通过以下几种方式生成堆转储文件：

在JVM启动参数里增加-XX:+HeapDumpOnOutOfMemoryError参数，系统发生OOM时会自动在工作目录(user.dir)生成java_pid.hprof转储文件。还可通过JVM参数-XX:HeapDumpPath=显式指定堆转储文件的存放路径。

如果不想等到发生OOM错误时才获得堆转储文件，可添加JVM参数-XX:+HeapDumpOnCtrlBreak，以便在控制台使用Ctrl+Break(Pause)键来按需获取堆转储文件。

若环境上Jmap工具可用，则可通过jmap -dump:live,format=b,file=heap.bin 命令获得转储文件。

其中，pid为进程ID，live选项会在转储前强制触发一次full GC(以减小文件体积)，file可指定产生文件的目录和名称。

类似地，VisualVM、Jconsole等JDK工具也可用来生成堆转储文件。

MAT本身也可获取堆转储文件，即File -> Acquire Heap Dump菜单。

分析堆转储文件

本节亦结合代码示例介绍MAT常见的界面功能。示例代码如下：

package thread;

import java.util.*;

public class JavaHeapDump {

private static List smallArray = new ArrayList<>();

private static List largeArray = new ArrayList<>();

public static String getPassword() {

char[] pw = {'A', 'd', 'm', 'i', 'n', '1', '2', '3'};

return new String(pw);

}

public static void makeHeapOom() {

for (int i = 0; i < 1000; i++) {

smallArray.add(getPassword()); //smallArray.add(getPassword().intern());

byte[] elems = new byte[1024 * 1024];

Arrays.fill(elems, (byte)101);

largeArray.add(elems);

//largeArray.add(new byte[1024 * 1024]);

}

}

public static void main(String[] args) {

makeHeapOom();

}

}

编译代码后以-Xms20m -Xmx20m(限制堆空间以尽快OOM)等JVM参数运行，得到如下输出：

D:\xywang\target\classes>java -Xms20m -Xmx20m -Xmn2m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=E:\dump\heapDump.bin thread.JavaHeapDum

p

java.lang.OutOfMemoryError: Java heap space

Dumping heap to E:\dump\heapDump.bin ...

Heap dump file created [21458899 bytes in 0.805 secs]

Exception in thread "main" java.lang.OutOfMemoryError: Java heap space

at thread.JavaHeapDump.makeHeapOom(JavaHeapDump.java:18)

at thread.JavaHeapDump.main(JavaHeapDump.java:26)

可知，很快就出现内存溢出(java.lang.OutOfMemoryError: Java heap space)，并在E盘下生成heapDump.bin转储文件。

此时启动MAT，选择菜单项File -> Open Heap Dump来加载待分析的堆转储文件。加载完文件后，在弹出的向导页面选择按照内存泄漏模式分析。

Leak Suspect Report是默认生成的可能存在潜在内存泄露的分析报告，在饼图中描述了各种问题占用内存的比例，饼图下方则是关于潜在问题的细节分析。

点击"Details"链接，可看到引起内存溢出可能的最大元凶确实为largeArray！此处，"Shortest Paths To the Accumulation Point"展示由于和哪个GC Root相连导致当前Retained Heap占用相当大的对象无法被回收。

概览页签提供了Heap Dump的概览，包括堆的饼图以及Actions/Reports/Step by Step等快速访问功能区。

其中，Histogram(堆直方图)提供按类分组的对象的内存占用统计列表，默认按照某个类的shallow heap从大到小排序。Dominator Tree(支配树)显示按照Object/Class保留内存大小排序的结果，可用于排查哪些对象导致其他对象无法被垃圾收集器回收。Top Consumers是Dominator Tree数据的图形统计，分别按照Object、Class,ClassLoader,Package等维度做的内存占用统计。Top Components列出占用堆空间较多的组件，并给出可以减少内存消耗的建议。

以最常用的Dominator Tree界面为例：

堆中有两个ArrayList，且其中一个占用了96.57%的内存。以下简要介绍图中主要字段的含义：

Shallow Heap：对象自身所占用的内存大小，不含其引用的对象所占的内存大小。数组对象的Shallow Heap是数组元素大小的总和，非数组对象的Shallow Heap是对象所有成员变量大小的总和。

Retained Heap：当前对象大小 + 当前对象可直接或间接引用到的对象的大小总和，即当前对象被GC后从Heap上总共能释放掉的内存。

incoming references：当前类被哪些类引用，或当前对象被哪些对象引用。

outgoing references：当前类的所有实例，或当前对象所引用的对象。

选中Dominator Tree中占用内存最大的对象，通过with incoming references查看持有其引用的外部对象。

可见，占用大量内容的元凶正是largeArray。对于集合对象，可右键选择Java Collections的子菜单做各种排序和查看。例如，图中选择Extract List Values查看largeArray的内容，结果如下所示：

窥探对象内存值

JavaHeapDump示例代码中有意使用到密码，真实业务中可通过OQL(Object Query Language)排查内存中是否存在此类敏感信息。

OQL是一种基于javascript表达式的语言，它将类当作表、该类的实例对象当作记录行、对象中的成员变量当作表中的字段，可以用类似SQL语句的方式查询Java堆中的对象。OQL语法结构如下：

select

from [ instanceof ]

[ where ]

更多OOL的语法，请在OOL页面上按F1键查看帮助信息。

在MAT工具栏中点击OQL按钮，打开OQL编辑器窗口，输入查询命令后点击红色感叹号按钮进行查询，结果如下：

注意，查询语句中"Admin123"后面的".*"相当于SQL通配符"%"。查询结果中赫然可见"Admin123"这样的明文密码！

通过Merge Shortest Path to GC Roots查看这些密码对象到GC Roots是否可达：

若该对象为unreachable则说明密码不是常驻内存，可见图中的密码均常驻内存。

堆转储文件对比分析

实际业务场景中堆中内存对象可能非常多，定位内存泄露时，通常需要抓取和对比先后两个时刻的堆转储文件。MAT操作步骤如下：

加载第一个堆转储文件，并打开Histogram视图。

打开Window -> Navigation History视图，在histogram右键选择Add to Compare Basket。

加载第二个堆转储文件，也添加到Compare Basket中。

打开Window -> Compare Basket视图，点击Compare the Results(右上角的红色叹号)。

在Compared Tables里分析对比结果。

例如，图中#1是使用String.intern()存储密码后的内存信息，比#0创建的String对象要少(这由OQL结果也可证明)。

通过这种方式可快速定位到操作前后所持有的对象增量，从而进一步定位出导致内存泄露的具体元凶。

总结

本文简要介绍了Java线程与内存分析工具VisualVM和MAT的使用，进一步的学习可参考官网或工具帮助(例如MAT：Help -> Welcome -> Tutorials)，并在实际工作中融会贯通。真是无话可说了……