JVM虚拟机性能监控与故障处理工具(3)

1.概述

  经过前面两章对于虚拟机内存分配与回收技术各方面的介绍，相信读者已经建立了 一个比较完整的理论基础。理论总是作为指导实践的工具，能把这些知识投入到实际工 作中才是我们的最终目的。接下来的两章，我们将从实践的角度去了解虚拟机内存管理 的世界。

  给一个系统定位问题的时候，知识、经验是关键基础，数据是依据，工具是运用 知识处理数据的手段。这里说的数据包括：运行日志、异常堆栈、GC日志、线程快照 (threaddump / javacore文件)、堆转储快照(heapdump / hprof文件)等。经常使用适当 的虚拟机监控和分析的工具可以加快我们分析数据和定位解决问题的速度，但我们在学 习工具前，也应当意识到工具永远都是知识技能的一层包装，没有什么工具是“秘密武 器”，学会了就能包治百病。

2. JDK的命令行工具

  Java开发人员肯定都知道JDK的bin目录中有“java.exe”和“javac.exe”这两个

  命令行工具，但并非所有程序员都了解过JDK的bin目录之中其他命令行程序的作用。 每逢JDK更新版本之时，bin目录下命令行工具的数量和功能总会不知不觉地增加和增 强，bin目录的内容如图4-1所示。

  

图 4-1

  在本章中，笔者将介绍这些工具的其中一部分，主要是用于监视虚拟机和故障处理的工具。这些故障处理工具被Sun公司作为“礼物”附赠给JDK的使用者，在软件的使用说明中把它们声明为“没有技术支持并且是实验性质的”(unsupported and experimental) ®的产品，但事实上这些工具都非常稳定而且功能强大，能在处理应用程序性能问题、定位故障时发挥很大的作用。

  说起JDK的工具，读者如果比较细心的话，可能会注意到这些工具的程序体积都异常的小。假如以前没注意到，现在不妨再看看图4-1中的最后一列“大小”，各个工具的 体积基本上都稳定在27KB左右。并非JDK开发团队刻意把它们制作得如此精炼来炫耀。

  假如读者使用的是Linux版本的JDK,还会发现这些工具中很多甚至就是由Shell 脚本直接写成的，可以用vim直接打开它们。

  JDK开发团队选择采用Java代码来实现这些监控工具是有特别用意的:当应用程序部署到生产环境后，无论是直接接触物理服务器还是远程Telnet到服务器上都可能会受到限制。借助tools.jar类库里面的接口，我们可以直接在应用程序中实现功能强大的监控分析功能。

  

  需要特别说明的是，本章介绍的工具全部基于Windows平台下的JDK 1.6 ,如果JDK版本、操作系统不同，工具所支持的功能可能会有较大差别。大部分工具在JDK 1.5中就已经提供，但为了避免运行环境带来的差异和兼容性问题，建议使用JDK 1.6来验证本章介绍的内容，因为JDK 1.6的工具可以正常兼容运行于 JDK 1.5的虚拟机之上的程序，反之则不一定。表4-1中列举了 JDK主要命令行监控 工具的用途。

  注意 如果读者在工作中需要监控运行于JDK 1.5的虚拟机之上的程序，在程序启动时 请添加参数"-Dcom.sun.management.jmxremote"开启JMX管理功能，否则由于部分工具都是基于JMX的(包括下一节的可视化工具)，因此它们都将会无法使用，如果被监控程序运行于JDK 1.6的虚拟机之上，那JMX管理默认是开启的，虚拟机启动时无须再添加任何参数。

  

  2.1 jps :虚拟机进程状况工具

  JDK的很多小工具的名字都参考了 Unix命令的命名方式，jps (JVM Process Status Tool)是其中的典型。除了名字像Unix的ps命令之外，它的功能也和ps命令类似：可 以列出正在运行的虚拟机进程，并显示虚拟机执行主类(Main Class, main。函数所在 的类)的名称，以及这些进程的本地虚拟机的唯一 ID (LVMID, Local Virtual Machine Identifier)。虽然功能比较单一,但它是使用频率最高的JDK命令行工具，因为其他的 JDK工具大多须要输入它査询到的LVMID来确定要监控的是哪一个虚拟机进程。对于 本地虚拟机进程来说，LVMID与操作系统的进程ID (PID, Process Identifier)是一致的，

  使用Windows的任务管理器或Unix的ps命令也可以査询到虚拟机进程的LVMID,但 如果同时启动了多个虚拟机进程，无法根据进程名称定位时，那就只能依赖jps命令显示主类的功能才能区分了。

  jps [ options ] [ hostid ]

  

  jps可以通过RMI协议査询开启了 RMI服务的远程虚拟机进程状态，hostid为RMI 注册表中注册的主机名。jps的其他常用选项见表4-2。

  

  2.2 jstat:虚拟机统计信息监视工具

  jstat (JVM Statistics Monitoring Tool)是用于监视虚拟机各种运行状态信息的命令行工具。它可以显示本地或远程'虚拟机进程中的类装载、内存、垃圾收集、JIT编译等 运行数据,在没有GUI图形界面，只提供了纯文本控制台环境的服务器上，它将是运行期定位虚拟机性能问题的首选工具。

  jstat命令格式为：

  jstat [ option vmid [interval[s|ms] [count]]]

  对于命令格式中的VMID与LVMID需要特别说明一下：如果是本地虚拟机进程， VMID与LVMID是一致的，如果是远程虚拟机进程，那VMID的格式应当是：

  [protocol:）[//]Ivmid[@hostname[:port]/servername]

  参数interval和count代表査询间隔和次数，如果省略这两个参数，说明只査询一 次。假设需要每250毫秒査询一次进程2764垃圾收集的状况，一共査询20次，那命令应当是：

  jstat -gc 2764 250 20

  选项option代表着用户希望査询的虚拟机信息，主要分为3类：类装载、垃圾收集和运行期编译状况，具体选项及作用请参考表4-3中的描述。

  

  jstat监视选项众多，由于版面原因无法逐一演示，这里仅举一例监视一台刚刚启动 的GlassFish v3服务器的内存状况的例子来演示如何査看监视结果。监视参数与输出结 果如代码清单4-1所示。

  

  査询结果表明：这台服务器的新生代Eden区（E,表示Eden）使用了 6.2%的空间，两个Survivor区（S0、S1,表示Survivor0. Survivor1）里面都是空的，老年代（O, 表示Old）和永久代（P,表示Permanent）则分别使用了 41.42%和47.20%的空间。程序运行以来共发生Minor GC （YGC,表示Young GC） 16次，总耗时0.105秒，发生 Full GC （FGC,表示 Full GC） 3 次，Full GC 总耗时（FGCT,表示 Full GC Time）为 0.472秒，所有GC总耗时（GCT,表示GC Time）为0.577秒。

  使用jstat工具在纯文本状态下监视虚拟机状态的变化，确实不如后面将会提到的 VisualVM等可视化的监视工具直接以图表展现的那样直观。但许多服务器管理员都习惯了在文本控制台中工作，直接在控制台中使用jstat命令依然是一种常用的监控 方式。

  2.3 jinfo : Java配置信息工具

  jinfo （Configuration Info for Java）的作用是实时地査看和调整虚拟机的各项参数。 使用jps命令的-V参数可以査看虚拟机启动时显式指定的参数列表，但如果想知道未被 显式指定的参数的系统默认值，除了去找资料外，就只能使用jinfo的-flag选项进行査 询了（如果只限于JDK 1.6或以上版本的话，使用java -XX:+PrintFlagsFinal査看参数 默认值也是一个很好的选择），jinfo还可以使用-sysprops选项把虚拟机进程的System. getProperties（）的内容打印出来。这个命令在JDK 1.5时期已经随着Linux版的JDK发 布，当时只提供了信息査询的功能，JDK 1.6之后，jinfo在Windows和Linux平台都有 提供，并且加入了运行期修改参数的能力，可以使用-flag [+|-]name或-flag name=value 修改一部分运行期可写的虚拟机参数值。JDK 1.6中，jinfo对于Windows平台的功能仍 然有较大的限制，只提供了最基本的-flag选项。

  jinfo命令格式：

  jinfo [ option ] pid

  执行样例：査询 CMSInitiatingOccupancyFraction 参数值。

  

  2.4 jmap : Java内存映像工具

  jmap （Memory Map for Java）命令用于生成堆转储快照（一般称为heapdump或 dump文件）。如果不使用jmap命令，要想获取Java堆转储快照还有一些比较“暴力”

  的手段：譬如在第2章中用过的-XX:+HeapDumpOnOutOfMemoryError参数，可以让虚拟机在OOM异常出现之后自动生成dump文件，通过-XX:+HeapDumpOnCtrlBreak参 数则可以使用[Ctrl]+[Break]键让虚拟机生成dump文件，又或者在Linux系统下通过 Kill -3命令发送进程退出信号“恐吓” 一下虚拟机，也能拿到dump文件。

  jmap的作用并不仅仅是为了获取dump文件，它还可以査询finalize执行队列，Java 堆和永久代的详细信息，如空间使用率、当前用的是哪种收集器等。

  和jinfo命令一样，jmap有不少功能在Windows平台下都是受限的，除了生成 dump文件的-dump选项和用于査看每个类的实例、空间占用统计的-histo选项所有操 作系统都提供之外，其余选项都只能在Linux / Solaris下使用。

  jmap命令格式：

  jmap [ option ] vmid

  option选项的合法值与具体含义如表4-4所示。

  

  代码清单4-2是使用jmap生成一个正在运行的Eclipse的dump快照文件的例子, 例子中的3500是通过jps命令査询到的LVMID.

  

  2.5 jhat：虚拟机堆转储快照分析工具

  Sun JDK 提供 jhat (JVM Heap Analysis Tool)命令与 jmap 搭配使用，来分析 jmap 生成的堆转储快照。jhat内置了一个微型的HTTP/HTML服务器，生成dump文件的分析结果后，可以在浏览器中査看。不过实事求是地说，在实际工作中，除非笔者手上真 的没有别的工具可用，否则一般都不会去直接使用jhat命令来分析dump文件，主要原 因有二：一是一般不会在部署应用程序的服务器上直接分析dump文件，即使可以这样 做，也会尽量将dump文件拷贝到其他机器'上进行分析，因为分析工作是一个耗时而 且消耗硬件资源的过程，既然都要在其他机器上进行，就没必要受到命令行工具的限制 To另外一个原因是jhat的分析功能相对来说比较简陋，后文将会介绍到的VisualVM, 以及专业用于分析 dump 文件的 Eclipse Memory Analyzer, IBM HeapAnalyzer®等工具， 都能实现比jhat更强大更专业的分析功能。代码清单4-3演示了使用jhat分析上一节采 用jmap生成的Eclipse IDE的内存快照文件。

  

  屏幕显示Server is ready.的提示后,用户在浏览器中键入http://localhost:7000/ 就可以看到分析结果，如图4-3所示。

  分析结果默认以包为单位进行分组显示，分析内存泄漏问题主要会使用到其中的 “Heap Histogram”(与jmap-histo功能一样)与OQL页签的功能，前者可以找到内存中总容量最大的对象，后者是标准的对象査询语言，使用类似SQL的语法对内存中的对象 进行査询统计。

  

  2.6 jstack : Java堆栈跟踪工具

  jstack (Stack Trace for Java)命令用于生成虚拟机当前时刻的线程快照(一般称为 threaddump或javacore文件)。线程快照就是当前虚拟机内每一条线程正在执行的方法 堆栈的集合,生成线程快照的主要目的是定位线程出现长时间停顿的原因,如线程间死锁、死循环、请求外部资源导致的长时间等待等都是导致线程长时间停顿的常见原因。 线程出现停顿的时候通过jstack来査看各个线程的调用堆栈，就可以知道没有响应的线程到底在后台做些什么事情，或者等待着什么资源。

  jstack命令格式：

  jstack [option ] vmid

  option选项的合法值与具体含义如表4-5所示。

  

 

  代码清单4-4是使用jstack査看Eclipse线程堆栈的例子，例子中的3500是通过jps 命令査询到的LVMID

  

  在 JDK 1.5 中，java.lang.Thread 类新增了一个 getAllStackTraces()方法用于获取虚拟机中所有线程的StackTraceElement对象。使用这个方法可以通过简单的几行代码就完成jstack的大部分功能，在实际项目中不妨调用这个方法做个管理员页面，可以随时使用浏览器来査看线程堆栈，如代码清单4-5所示，这是笔者的一个小经验。

  

3. JDK的可视化工具

  JDK中除了提供大量的命令行工具外，还有两个功能强大的可视化工具：JConsole 和VisualVM,这两个工具是JDK的正式成员，没有被贴上"unsupported and experimental”的标签。

  其中JConsole是在JDK 1.5时期就已经提供的虚拟机监控工具，而VisualVM在 JDK 1.6 Update7中才首次发布，现在已经成为Sun (Oracle)主力推动的多合一故障处理工具。并且已经从JDK中分离出来成为可以独立发展的开源项目。

  为了避免本节的讲解成为对软件说明文档的简单翻译，笔者准备了一些代码样例， 都是笔者特意编写的反面教材。后面将会使用两款工具去监控和分析这几段代码存在的 问题，算是本节简单的实战分析。可以把在可视化工具上观察到的数据和现象与前面两章中讲解的理论知识互相印证。

  3.1 JConsole : Java监视与管理控制台

  JConsole (Java Monitoring and Management Console)是一款基于 JMX 的可视化监视和管理的工具。它管理部分的功能是针对JMX MBean进行管理，由于MBean可以使用代码、中间件服务器的管理控制台或者所有符合JMX规范的软件进行访问，所以本 节中将会着重介绍JConsole监视部分的功能。

  （1）启动 JConsole

  通过JDK/bin目录下的“jconsole.exe”启动JConsole后，将自动搜索出本机运行的 所有虚拟机进程，不需要用户自己再使用jps来査询了，如图4-4所示。双击选择其中 一个进程即可开始监控，也可以使用下面的“远程进程”功能来连接远程服务器，对远 程虚拟机进行监控。

  

图 4-4

  从图4-4中可以看到笔者的机器现在运行了一共三个本地虚拟机进程。双击任意一个进入JConsole主界面，可以看到主界面里共包括“概述”、'‘内存”、"线程”、 “类”、-VM摘要”和“MBean”六个页签，如图4-5所示。

  

图4-5 JConsole主界面

  “概述”页签显示的是整个虚拟机主要运行数据的概览，其中包括“堆内存使用情 况”、'‘线程”、"类”、“CPU使用情况”四项信息的曲线图，这些曲线图是后面“内存”、“线程”、"类”页签的信息汇总，具体内容将在后面介绍。

  （2）内存监控

  "内存”页签相当于可视化的jstat命令，用于监视受收集器管理的虚拟机内存 （Java堆和永久代）的变化趋势。我们通过运行代码清单4-6中的代码来体验一下它的 监视功能。运行时设置的虚拟机参数为：-Xms100m -Xmx100  m -XX:+UseSerialGC,这 段代码的作用是以64KB/50毫秒的速度往Java堆中填充数据，一共填充1000次，使用 JConsole的“内存”页签进行监视，观察曲线和柱状指示图的变化。

package com.intehel.demo.domain;

import java.util.ArrayList;
import java.util.List;

public class FinalizeEscapeGC {
    static class OOMObject{
        public byte[] placeholder = new byte[64*1024];
    }

    @SuppressWarnings("unused")
    public static void fillHeap(int nun) throws InterruptedException {
        List<OOMObject> list = new ArrayList<OOMObject>();
        for (int i = 0; i < nun; i++){
            Thread.sleep(1000);
            list.add(new OOMObject());
        }
        System.gc();
    }

    public static void main(String[] args) throws Throwable {
        fillHeap(1000);
    }
}

  程序运行后，在“内存”页签中可以看到内存池Eden区的运行趋势呈现折线状， 如图4-6所示。而监视范围扩大至整个堆后，会发现曲线是一条向上增长的平滑曲线。 并且从柱状图可以看到，在1000次循环执行结束，运行了 System.gc()后，虽然整个新生代Eden和Survivor区都基本被清空了，但是代表老年代的柱状图仍然保持峰值状态， 说明被填充进堆中的数据在System.gc()方法执行之后仍然存活着。分析就到此为止，提两个小问题思考一下。

• 虚拟机启动参数只限制了 Java堆为100MB,没有指定-Xmn参数，能否从监控图中估计出新生代有多大？
• 为何执行了 System.gc()之后，图4-6中代表老年代的柱状图仍然显示为峰值状 态，代码需要如何调整才能让System.gc()回收掉填充到堆中的对象？

  

图 4-6

  问题1的答案：图4-6显示Eden空间为27328KB,因为没有设置-XX:SurvivorRadio 参数，所以Eden与Survivor空间比例为默认值8： 1,因此整个新生代空间大约为 27,328KB X 125%=34,160KB。

  问题2的答案：System.gc()之后，空间未能回收是因为List<OOMObject> list对象仍然存活着,fiUHeap()方法仍然没有退出，因此list对象在执行System.gc()时仍然处于作用域之内。如果把System.gc()移动到fillHeap()方法外，调用就可以回收掉全部 内存。

  （3）线程监控

  如果上面的“内存”页签相当于可视化的jstat命令的话，“线程”页签的功能则相当于可视化的jstack命令，遇到线程停顿的时候可以使用这个页签进行监控分析。前面 讲解jstack命令的时候提到过线程长时间停顿的主要原因有：等待外部资源（数据库连 接、网络资源、设备资源等）、死循环、锁等待（活锁和死锁）。通过代码清单4-7分别 演示一下这几种情况。

package com.intehel.demo.domain;

import java.io.BufferedReader;
import java.io.InputStreamReader;

public class FinalizeEscapeGC {

    public static void createBusyThread() {
        Thread thread = new Thread(new Runnable() {
            @Override
            public void run() {
                while (true);
            }

        },"testBusyThread");
        thread.start();
    }
    public static void createLockThread(final Object lock) {
        Thread thread = new Thread(new Runnable() {
            @Override
            public void run() {
                synchronized (lock) {
                    try {
                        lock.wait();
                    }catch (InterruptedException e){
                        e.printStackTrace();
                    }
                }
            }

        },"testLockThread");
        thread.start();
    }

    public static void main(String[] args) throws Throwable {
        BufferedReader bufferedReader = new BufferedReader(new InputStreamReader(System.in));
        bufferedReader.readLine();
        createBusyThread();
        bufferedReader.readLine();
        Object object = new Object();
        createLockThread(object);
    }
}

  程序运行后，首先在“线程”页签中选择main线程，如图4-7所示。堆栈追踪显示 BufferedReader在readBytes方法中等待System.in的键盘输入，这时候线程为Runnable 状态，Runnable状态的进程会被分配运行时间，但readBytes方法检査到流没有更新时 会立刻归还执行令牌，这种等待只消耗很小的CPU资源。

  

  接着监控testBusyThread线程，如图4-8所示，testBusyThread线程一直在执行空循 环，从堆栈追踪中可以看到一直停留在FinalizeEscapeGC.java代码的12行，12行为while (true)„这时候线程为Runnable状态，而目.没有归还线程执行令牌的动作，会在空循环上用尽全部执行时间直到线程切换，这种等待会消耗较多的CPU资源。

  图4-9显示testLockThread线程在等待着lock对象的notify或notifyAll方法的出 现，线程这时候处在WAITING状态，在被唤醒前不会被分配执行时间。

  testLockThread线程正处于正常的活锁等待状态，只要lock对象的notify()或 notifyAlR)方法被调用，这个线程便能激活以继续执行。代码清单4-8演示了一个无法 再被激活的死锁等待。

  

图 4-8

  

图 4-9

  代码清单4-8死锁代码样例

package com.intehel.demo.domain;

import java.io.BufferedReader;
import java.io.InputStreamReader;

public class FinalizeEscapeGC implements Runnable {
    int a,b;
    public FinalizeEscapeGC(int a,int b){
        this.a = a;
        this.b = b;
    }
    @Override
    public void run() {
        synchronized (Integer.valueOf(a)){
            synchronized (Integer.valueOf(b)){
                System.out.println(a+b);
            }
        }
    }

    public static void main(String[] args) throws Throwable {
        for (int i = 0; i < 100; i++) {
            new Thread(new FinalizeEscapeGC(1,2)).start();
            new Thread(new FinalizeEscapeGC(2,1)).start();
        }
    }
}

  这段代码开了 200个线程分别去计算1+2及2+1的值，其实for循环是可省略的， 两个线程也可能会导致死锁，不过那样概率太小，需要尝试运行很多次才能看到效果。 如果运气不是特别差的话，带for循环的版本最多运行2~3次就会遇到线程死锁，程序无法结束。造成死锁的原因是Integer.valueOf()方法基于减少对象创建次数和节省内 存的考虑，［-128,127］之间的数字会被缓存。当valueOf()方法在这个范围之内传入参 数，将直接返回缓存中的对象。也就是说代码中调用了 200次Integer.valueOf()方法一 共就只返回了两个不同的对象。假如在某个线程的两个synchronized块之间发生了一次线程切换，就会出现线程A等着被线程B持有的Integer.valueOf(1),线程B又等着被线 程A持有的Integer.valueOf(2),结果大家都跑不下去的情景。

  出现线程死锁之后，点击JConsole线程面板的“检测到死锁”的按钮，将出现一个 新的"死锁”页签，如图4-10所示。

  

图 4-10

  图中很清晰地显示线程Thread-127在等待一个被线程Thread-158持有Integer对象， 而点击线程Thread-58则显示它也在等待一个Integer对象，被线程Thread-127持有，这样两个线程就互相卡住，都不存在等到锁释放的希望了。

  3.2  VisualVM :多合一故障处理工具

  VisualVM （All-in-One Java Troubleshooting Tool）是到目前为止，随 JDK 发布的功能最强大的运行监视和故障处理程序，并且可以预见在未来一段时间内都是官方主力发展的虚拟机故障处理工具。官方在VisualVM的软件说明中写上了 “All-in-One”的描述 字样，预示着它除了运行监视、故障处理外，还提供了很多其他方面的功能。如性能分析（Profiling）, VisualVM的性能分析功能甚至比起JProfiler、YourKit等专业且收费的 Profiling 工具都不会逊色多少，而且VisualVM的还有一个很大优点：不需要被监视的 程序基于特殊Agent运行，因此它对应用程序的实际性能的影响很小，使得它可以直接 应用在生产环境中。这个优点是JProfiler、YourKit等工具无法与之媲美的。

  （1）VisualVM兼容范围与插件安装

  VisualVM基于NetBeans平台开发，因此它一开始就具备了插件扩展功能的特性， 通过插件扩展支持，VisualVM可以做到：

• 显示虚拟机进程及进程的配置和环境信息（jps、jinfo）。
• 监视应用程序的CPU、GC、堆、方法区及线程的信息（jstat、jstack）。
• dump及分析堆转储快照（jmap、jhat）。
• 方法级的程序运行性能分析，找出被调用最多、运行时间最长的方法。
• 离线程序快照：收集程序的运行时配置、线程dump、内存dump等信息建立一个 快照，可以将快照发送开发者处进行Bug反馈。
• 其他plugins的无限的可能性……

  VisualVM在JDK 1.6 update 7中才首次出现，但并不意味着它只能监控运行于JDK 1.6上的程序，它具备很强的向下兼容能力，甚至能向下兼容至近10年前发布的JDK 1.4.2平台气这对无数已经处于实施、维护状态的项目很有意义。当然，并非所有的功 能都能完美地向下兼容，主要特性的兼容性如表4-6所示。

  

  首次启动VisualVM后，读者先不必着急找应用程序进行监测，因为现在VisualVM 还没有加载任何插件，虽然基本的监视、线程面板的功能主程序都以默认插件的形式提供了，但是不给VisualVM装任何扩展插件，就相当于放弃了它最精华的功能，和没有安装任何应用软件操作系统差不多。

  插件可以手工安装，在网站'上下载*.nbm包后，点击“工具”一“插件”一“已下载”菜单，然后在弹出的对话框中指定nbm包路径便可进行安装，插件安装后存放 在JDK HOME/lib/visualvm/visualvm中。不过手工安装并不常用，使用VisualVM的 自动安装功能已经可以找到所需的大多数插件，在有网络连接的环境下，点击“工具-插件-菜单“，弹出如图4-11所示的插件页签，在页签的“可用插件”中列举了当前版本VisualVM可以使用的插件，选中插件后在右边窗口将显示这个插件的基本信 息，如开发者、版本、功能描述等。

  大家可以根据自己的工作需要和兴趣选择合适的插件，然后点击安装按钮，弹出如 图4-12所示的下载进度窗口，跟着提示操作稍后即可安装完成。

  安装完插件后，选择一个需要监视的程序就进入程序的主界面了，如图4-13所示。 根据读者选择安装插件数量的不同，看到的页签可能和笔者截图中的会有差异。

  VisualVM中“概述”、"监视”、"线程”、"MBeans”的功能与前面介绍的JConsole 差别不大，读者根据上一节的内容类比使用即可，下面挑选几个特色功能和插件进行 介绍。

  （2）生成和浏览堆转储快照

  在VisualVM中生成dump文件有两种方式，可以执行下列任一操作：

• 在“应用程序”窗口中右键单击应用程序节点，然后选择“堆Dump”。
• 在“应用程序”窗口中双击应用程序节点以打开应用程序标签，然后在“监视” 标签中单击“堆Dump”。

  生成了 dump文件之后，应用程序页签将在该堆的应用程序下增加一个以 [heapdump]开头的子节点，并且在主页签中打开该转储快照，如图4-14所示。如果需 要把dump文件保存或发送出去，要在heapdump节点上右键选择“另存为”菜单，否 则当VisualVM关闭时，生成的dump文件会被当做临时文件被删除掉。要打开一个 已经存在的dump文件，通过文件菜单中的“装入”功能，选择硬盘上的dump文件 即可。

  

图 4-14

  从堆页签中的“摘要”面板可以看到应用程序dump时的运行时参数、System. getProperties()的内容、线程堆栈等信息，“类”面板则是以类为统计口径统计类的实例 数量和容量信息，"实例”面板不能直接使用，因为不能确定用户想査看哪个类的实例， 所以需要通过“类”面板进入，在“类”中选择一个关心的类后双击鼠标，即可在“实 例”中看见此类中500个实例的具体属性信息。“OQL控制台”面板里面就是运行OQL 査询语句的，同jhat里面介绍的OQL功能一样。

  （3）分析程序性能

  在Profiler页签中，VisualVM提供了程序运行期间方法级的CPU执行时间分析及 内存分析，进行Profiling分析肯定会对程序运行性能有比较大的影响，所以一般不在生 产环境中使用这项功能。

要开始分析，先选择“CPU”和“内存”按钮中的一个，然后切换到应用程序中对程序进行操作，VisualVM会记录到这段时间中应用程序执行过的方法。如果是CPU分 析，将会统计每个方法的执行次数、执行耗时；如果是内存分析则会统计每个方法关联 的对象数及这些对象所占的空间。分析结束后，点击“停止”按钮结束监控过程，如图 4-15所示。

  

图 4-15

  注意 在JDK 1.5之后，在Client模式下的虚拟机加入并且自动开启了类共享——这是 一个在多虚拟机进程中共享rt.jar中的类数据以提高加载速度和节省内存的优化，而根 据相关Bug报告的反映，VisualVM的Profiler功能可能会因为类共享而导致被监视的应 用程序崩潰，所以读者进行Profiling前，最好在被监视的程序中使用-Xshare:off参数来 关闭类共享优化。

  图4-15中是对Eclipse IDE 一段操作的录制和分析结果，读者分析自己的应用程序时, 可以根据实际业务的复杂程度与方法的时间和调用次数做比较，找到最有优化价值的方法。

  （4）BTrace动态日志跟踪

  BTrace®是一个很“有趣”的VisualVM插件，本身也是可以独立运行的程序。它的作用是在不停止目标程序运行的前提下，通过HotSpot虚拟机的HotSwap技术®动态加入 原本并不存在的调试代码。这项功能对实际生产中的程序很有意义：经常遇到程序出现问 题，但排査错误的一些必要信息，譬如方法参数、返回值等，在开发时并没有打印到日志 之中，以至于不得不停掉服务，通过调试增量来加入日志代码以解决问题。当遇到生产环 境服务无法随便停止时，缺一两句日志导致排错进行不下去是一件非常郁闷的事情。

  在VisualVM中安装了 BTrace插件后，应用程序面板右键点击要调试的程序，会出 现“Trace Application”菜单，点击将进入BTrace面板。这个面板里面看起来就像一个 简单的Java程序开发环境，里面还有一小段Java代码，如图4-16所示。

图 4-16

  准备了一段很简单的Java代码来演示BTrace的功能：产生两个1000以内的随机整数，输出这2个数字相加的结果，如代码清单4-9所示。

  代码清单4-9 BTrace跟踪演示

package com.intehel.demo.domain;

import java.io.BufferedReader;
import java.io.InputStreamReader;

public class FinalizeEscapeGC {
    public int add(int a, int b){
        return a+b;
    }

    public static void main(String[] args) throws Throwable {
        FinalizeEscapeGC finalizeEscapeGC = new FinalizeEscapeGC();
        BufferedReader reader = new BufferedReader(new InputStreamReader(System.in));
        for (int i = 0; i < 10; i++) {
            reader.readLine();
            int a = (int) Math.round(Math.random()*1000);
            int b = (int) Math.round(Math.random()*1000);
            System.out.println(finalizeEscapeGC.add(a, b));
        }
    }
}

  程序运行后，在VisualVM中打开该程序的监视，在BTrace页签填充TracingScript 的内容，输入调试代码如代码清单4.10所示。

  代码清单4・10 BTrace调试代码

/* BTrace Script Template */
import com.sun.btrace.annotations.*;
import static com.sun.btrace.BTraceUtils.*;
@BTrace
public class TracingScript {
	/* put your code here */
    @OnMethod(
        clazz = "com.intehel.demo.domain.FinalizeEscapeGC",
        method="add",
        location=@Location(Kind.RETURN)
    )
    public static void func(@Self com.intehel.demo.domain.FinalizeEscapeGC instance,int a,int b,@Return int result){
        println("调用堆栈：");
        jstack();
        println(strcat("方法参数A:",str(a)));
        println(strcat("方法参数B:",str(b)));
        println(strcat("方法结果:",str(result)));
    }
}

  点击“Start”按钮后稍等片刻，编译完成后，可见Output面板中出现“BTrace code successfuly deployed”的字样。程序运行的时候在Output面板将会输出如图4-17所示的 调试信息。

  

图 4-17

  BTrace的用法还有许多，打印调用堆栈、参数、返回值只是最基本的应用，在它的网站上有使用BTrace进行性能监视、定位连接泄漏、内存泄漏、解决多线程竞争问题等的使用例子，有兴趣的可以去网上了解相关信息。

小结

  本章介绍了随JDK发布的6个命令行工具与2个可视化的故障处理工具，灵活使用 这些工具，可以给处理问题带来很大的便利。

  除了 JDK自带的工具之外，常用的故障处理工具还有很多，如果读者使用的是非Sun系列的JDK,非HotSpot的虚拟机，就需要使用对应的工具进行分析，如：

• IBM 的 Support Assistant'、Heap Analyzer®, Javacore Analyzer®, Garbage Collector Analyzer®适用于 IBM J9 VM„
• HP 的 HPjmeter®、HPjtune 适用于 HP-UX, SAP、HotSpot VM.
• Eclipse 的 Memory Analyzer Tool® (MAT)适用于 HP-UX、SAP、HotSpot VM, 安装IBM DTFjo插件后可支持IBM J9 VM。
• BEA 的 JRockit Mission Control ®,适用于 JRockit VM_O