Question

Java开发人员肯定都知道JDK的bin目录中有“java.exe”、“javac.exe”这两个命令行工具，但并非所有程序员都了解过JDK的bin目录之中其他命令行程序的作用。每逢JDK更新版本之时，bin目录下命令行工具的数量和功能总会不知不觉地增加和增强。bin目录的内容如图4-1所示。

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

图　4-1　Sun JDK中的工具目录

说起JDK的工具，比较细心的读者，可能会注意到这些工具的程序体积都异常小巧。假如以前没注意到，现在不妨再看看图4-1中的最后一列“大小”，几乎所有工具的体积基本上都稳定在27KB左右。并非JDK开发团队刻意把它们制作得如此精炼来炫耀编程水平，而是因为这些命令行工具大多数是jdk/lib/tools.jar类库的一层薄包装而已，它们主要的功能代码是在tools类库中实现的。读者把图4-1和图4-2两张图片对比一下就可以看得很清楚。

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

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

图　4-2　tools.jar包的内部状况

需要特别说明的是，本章介绍的工具全部基于Windows平台下的JDK 1.6 Update 21，如果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（包括4.3节介绍的可视化工具），它们都将会无法使用，如果被监控程序运行于JDK 1.6的虚拟机之上，那JMX管理默认是开启的，虚拟机启动时无须再添加任何参数。

4.2.1　jps：虚拟机进程状况工具

JDK的很多小工具的名字都参考了UNIX命令的命名方式，jps（JVM Process Status Tool）是其中的典型。除了名字像UNIX的ps命令之外，它的功能也和ps命令类似：可以列出正在运行的虚拟机进程，并显示虚拟机执行主类（Main Class,main()函数所在的类）名称以及这些进程的本地虚拟机唯一ID（Local Virtual Machine Identifier,LVMID）。虽然功能比较单一，但它是使用频率最高的JDK命令行工具，因为其他的JDK工具大多需要输入它查询到的LVMID来确定要监控的是哪一个虚拟机进程。对于本地虚拟机进程来说，LVMID与操作系统的进程ID（Process Identifier,PID）是一致的，使用Windows的任务管理器或者UNIX的ps命令也可以查询到虚拟机进程的LVMID，但如果同时启动了多个虚拟机进程，无法根据进程名称定位时，那就只能依赖jps命令显示主类的功能才能区分了。

jsp命令格式：

jps[options][hostid]

jps执行样例：

D：\Develop\Java\jdk1.6.0_21\bin>jps-l
2388 D：\Develop\glassfish\bin\..\modules\admin-cli.jar
2764 com.sun.enterprise.glassfish.bootstrap.ASMain
3788 sun.tools.jps.Jps

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

[1]http://download.oracle.com/javase/6/docs/technotes/tools/index.html。

[2]tools.jar中的类库不属于Java的标准API，如果引入这个类库，就意味着用户的程序只能运行于Sun Hotspot（或一些从Sun公司购买了JDK的源码License的虚拟机，如IBM J9、BEA JRockit）上面，或者在部署程序时需要一起部署tools.jar。

4.2.2　jstat：虚拟机统计信息监视工具

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

jstat命令格式为：

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

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

[protocol：][//]lvmid[@hostname[：port]/servername]

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

jstat-gc 2764 250 20

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

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

代码清单4-1　jstat执行样例

D：\Develop\Java\jdk1.6.0_21\bin>jstat-gcutil 2764
S0 S1 E O P YGC YGCT FGC FGCT GCT
0.00 0.00 6.20 41.42 47.20 16 0.105 3 0.472 0.577

查询结果表明：这台服务器的新生代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命令依然是一种常用的监控方式。

[1]需要远程主机提供RMI支持，Sun提供的jstatd工具可以很方便地建立远程RMI服务器。

4.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参数值。

C：\>jinfo-flag CMSInitiatingOccupancyFraction 1444
-XX：CMSInitiatingOccupancyFraction=85

4.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。

代码清单4-2　使用jmap生成dump文件

C：\Users\IcyFenix>jmap-dump：format=b,file=eclipse.bin 3500
Dumping heap to C：\Users\IcyFenix\eclipse.bin……
Heap dump file created

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

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

代码清单4-3　使用jhat分析dump文件

C：\Users\IcyFenix>jhat eclipse.bin
Reading from eclipse.bin……
Dump file created Fri Nov 19 22：07：21 CST 2010
Snapshot read,resolving……
Resolving 1225951 objects……
Chasing references,expect 245 dots……
Eliminating duplicate references……
Snapshot resolved.
Started HTTP server on port 7000
Server is ready.

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

图　4-3　jhat的分析结果

分析结果默认是以包为单位进行分组显示，分析内存泄漏问题主要会使用到其中的“Heap Histogram”（与jmap-histo功能一样）与OQL页签的功能，前者可以找到内存中总容量最大的对象，后者是标准的对象查询语言，使用类似SQL的语法对内存中的对象进行查询统计，读者若对OQL有兴趣的话，可以参考本书附录D的介绍。

[1]用于分析的机器一般也是服务器，由于加载dump快照文件需要比生成dump更大的内存，所以一般在64位JDK、大内存的服务器上进行。

[2]IBM HeapAnalyzer用于分析IBM J9虚拟机生成的映像文件，各个虚拟机产生的映像文件格式并不一致，所以分析工具也不能通用。

4.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。

代码清单4-4　使用jstack查看线程堆栈（部分结果）

C：\Users\IcyFenix>jstack-l 3500
2010-11-19 23：11：26
Full thread dump Java HotSpot（TM）64-Bit Server VM（17.1-b03 mixed mode）：
"[ThreadPool Manager]-Idle Thread"daemon prio=6 tid=0x0000000039dd4000 nid=0xf50 in Object.wait()[0x000000003c96f000]
java.lang.Thread.State：WAITING（on object monitor）
at java.lang.Object.wait（Native Method）
-waiting on＜0x0000000016bdcc60>（a org.eclipse.equinox.internal.util.impl.tpt.threadpool.Executor）
at java.lang.Object.wait（Object.java：485）
at org.eclipse.equinox.internal.util.impl.tpt.threadpool.Executor.run（Executor.java：106）
-locked＜0x0000000016bdcc60>（a org.eclipse.equinox.internal.util.impl.tpt.threadpool.Executor）
Locked ownable synchronizers：
-None

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

代码清单4-5　查看线程状况的JSP页面

＜%@page import="java.util.Map"%>
＜html>
＜head>
＜title>服务器线程信息＜/title>
＜/head>
＜body>
＜pre>
＜%
for（Map.Entry＜Thread,StackTraceElement[]>stackTrace：Thread.
getAllStackTraces().entrySet()）{
Thread thread=（Thread）stackTrace.getKey()；
StackTraceElement[]stack=（StackTraceElement[]）stackTrace.getValue()；
if（thread.equals（Thread.currentThread()））{
continue；
}
out.print（"\n线程："+thread.getName()+"\n"）；
for（StackTraceElement element：stack）{
out.print（"\t"+element+"\n"）；
}
}
%>
＜/pre>
＜/body>
＜/html>

4.2.7　HSDIS：JIT生成代码反汇编

在Java虚拟机规范中，详细描述了虚拟机指令集中每条指令的执行过程、执行前后对操作数栈、局部变量表的影响等细节。这些细节描述与Sun的早期虚拟机（Sun Classic VM）高度吻合，但随着技术的发展，高性能虚拟机真正的细节实现方式已经渐渐与虚拟机规范所描述的内容产生了越来越大的差距，虚拟机规范中的描述逐渐成了虚拟机实现的“概念模型”——即实现只能保证规范描述等效。基于这个原因，我们分析程序的执行语义问题（虚拟机做了什么）时，在字节码层面上分析完全可行，但分析程序的执行行为问题（虚拟机是怎样做的、性能如何）时，在字节码层面上分析就没有什么意义了，需要通过其他方式解决。

分析程序如何执行，通过软件调试工具（GDB、Windbg等）来断点调试是最常见的手段，但是这样的调试方式在Java虚拟机中会遇到很大困难，因为大量执行代码是通过JIT编译器动态生成到CodeBuffer中的，没有很简单的手段来处理这种混合模式的调试（不过相信虚拟机开发团队内部肯定是有内部工具的）。因此，不得不通过一些特别的手段来解决问题，基于这种背景，本节的主角——HSDIS插件就正式登场了。

HSDIS是一个Sun官方推荐的HotSpot虚拟机JIT编译代码的反汇编插件，它包含在HotSpot虚拟机的源码之中，但没有提供编译后的程序。在Project Kenai的网站^[1]也可以下载到单独的源码。它的作用是让HotSpot的-XX：+PrintAssembly指令调用它来把动态生成的本地代码还原为汇编代码输出，同时还生成了大量非常有价值的注释，这样我们就可以通过输出的代码来分析问题。读者可以根据自己的操作系统和CPU类型从Project Kenai的网站上下载编译好的插件，直接放到JDK_HOME/jre/bin/client和JDK_HOME/jre/bin/server目录中即可。如果没有找到所需操作系统（譬如Windows的就没有）的成品，那就得自己使用源码编译一下^[2]。

还需要注意的是，如果读者使用的是Debug或者FastDebug版的HotSpot，那可以直接通过-XX：+PrintAssembly指令使用插件；如果使用的是Product版的HotSpot，那还要额外加入一个-XX：+UnlockDiagnosticVMOptions参数。笔者以代码清单4-6中的简单测试代码为例演示一下这个插件的使用。

代码清单4-6　测试代码

public class Bar{
int a=1；
static int b=2；
public int sum（int c）{
return a+b+c；
}
public static void main（String[]args）{
new Bar().sum（3）；
}
}

编译这段代码，并使用以下命令执行。

java-XX：+PrintAssembly-Xcomp-XX：CompileCommand=dontinline，*Bar.sum-XX：Compi leCommand=compileonly，*Bar.sum test.Bar

其中，参数-Xcomp是让虚拟机以编译模式执行代码，这样代码可以“偷懒”，不需要执行足够次数来预热就能触发JIT编译^[3]。两个-XX：CompileCommand意思是让编译器不要内联sum()并且只编译sum()，-XX：+PrintAssembly就是输出反汇编内容。如果一切顺利的话，那么屏幕上会出现类似下面代码清单4-7所示的内容。

代码清单4-7　测试代码

[Disassembling for mach='i386']
[Entry Point]
[Constants]
#{method}'sum''（I）I'in'test/Bar'
#this：ecx='test/Bar'
#parm0：edx=int
#[sp+0x20]（sp of caller）
……
0x01cac407：cmp 0x4（%ecx），%eax
0x01cac40a：jne 0x01c6b050；{runtime_call}
[Verified Entry Point]
0x01cac410：mov%eax，-0x8000（%esp）
0x01cac417：push%ebp
0x01cac418：sub$0x18，%esp；*aload_0
；-test.Bar：sum@0（line 8）
；block B0[0，10]
0x01cac41b：mov 0x8（%ecx），%eax；*getfield a
；-test.Bar：sum@1（line 8）
0x01cac41e：mov$0x3d2fad8，%esi；{oop（a
'java/lang/Class'='test/Bar'）}
0x01cac423：mov 0x68（%esi），%esi；*getstatic b
；-test.Bar：sum@4（line 8）
0x01cac426：add%esi，%eax
0x01cac428：add%edx，%eax
0x01cac42a：add$0x18，%esp
0x01cac42d：pop%ebp
0x01cac42e：test%eax，0x2b0100；{poll_return}
0x01cac434：ret

上段代码并不多，下面一句句进行说明。

1）mov%eax，-0x8000（%esp）：检查栈溢。

2）push%ebp：保存上一栈帧基址。

3）sub$0x18，%esp：给新帧分配空间。

4）mov 0x8（%ecx），%eax：取实例变量a，这里0x8（%ecx）就是ecx+0x8的意思，前面“[Constants]”节中提示了“this：ecx='test/Bar'”，即ecx寄存器中放的就是this对象的地址。偏移0x8是越过this对象的对象头，之后就是实例变量a的内存位置。这次是访问“Java堆”中的数据。

5）mov$0x3d2fad8，%esi：取test.Bar在方法区的指针。

6）mov 0x68（%esi），%esi：取类变量b，这次是访问“方法区”中的数据。

7）add%esi，%eax和add%edx，%eax：做两次加法，求a+b+c的值，前面的代码把a放在eax中，把b放在esi中，而c在[Constants]中提示了，“parm0：edx=int”，说明c在edx中。

8）add$0x18，%esp：撤销栈帧。

9）pop%ebp：恢复上一栈帧。

10）test%eax，0x2b0100：轮询方法返回处的SafePoint。

11）ret：方法返回。

[1]Project Kenai：http://kenai.com/projects/base-hsdis。

[2]HLLVM圈子中有已编译好的：http://hllvm.group.iteye.com/。

[3]-Xcomp在较新的HotSpot中被移除了，如果读者的虚拟机无法使用这个参数，请加个循环预热代码，触发JIT编译。