JVM故障诊断

栈溢出(StackOverflowError)

由于每次函数调用都会生成对应的栈帧，从而占用一定的栈空间。因此，如果栈空间不足，那么函数调用自然无法继续进行。当请求的栈深度大于最大可用栈深度时，系统就会抛出StackOverflowError栈溢出错误。 Java虚拟机提供了参数-Xss来指定线程的最大栈空间，这个参数也直接决定了函数调用的最大深度。

下面的代码是一个递归调用，由于递归没有出口，这段代码可能会出现栈溢出错误，在抛出错误后，程序打印了最大的调用深度。

public class StackDemo {

    private static int i = 0;

    public static void recursion() {
        i++;
        recursion();
    }

    public static void main(String[] args) {
        try{
            recursion();
        }catch (Throwable e) {
            System.out.println("call deep=>"+i);
            e.printStackTrace();
        }

    }
}

使用参数-Xss128K执行以上代码，部分结果如下：

call deep=>1082
java.lang.StackOverflowError
	at com.demo.StackDemo.recursion(StackDemo.java:8)

可以看到，在进行大约1082次调用后，发生了栈溢出错误，通过增大-Xss的值，可以获得更深的调用层次，尝试使用参数-Xss256K执行上述代码，可能产生如下输出，很明显，调用层次明显增加。

call deep=>2731
java.lang.StackOverflowError
	at com.demo.StackDemo.recursion(StackDemo.java:8)

注意： 函数嵌套调用的层次在很大程度上由栈的大小决定，栈越大，函数可以支持的嵌套调用次数就越多。

局部变量表

内存溢出问题排查

内存溢出（OutOfMemory，简称OOM）是一个令人头痛的问题，它通常出现在某一块内存空间耗尽的时候。在Java程序中，导致内存溢出的原因很多，例如堆溢出、直接内存溢出、永久区溢出等。

堆溢出(OutOfMemoryError)

堆是Java程序中最重要的内存空间，由于大量的对象都被直接分配在堆上，所以它也是最有可能发生溢出的区间。一般来说，绝大部分Java内存溢出都属于这种情况。其原因是大量对象占据了堆空间，而这些对象都持有强引用，无法回收，当对象大小之和大于由Xmx参数指定的堆空间大小时，溢出错误就自然而然地发生了。

例如：下面这段代码就是堆溢出的典型案例，一个ArrayList对象总是持有byte数组的强引用，导致byte数组无法回收。（-Xms5m -Xmx5m）

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

public class SimpleHeapOom {

    public static void main(String[] args) {
        List<byte[]> strongReference = new ArrayList<>();
        for (int i = 0; i < 5; i++) {
            strongReference.add(new byte[1024 * 1024]);
        }
        System.out.println(strongReference.size());
    }
}

运行以上代码，应该会立即抛出错误：

Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
	at com.demo.SimpleHeapOom.main(SimpleHeapOom.java:11)

可以看到，在错误信息中注明了“java heap space”，表示这是一次堆溢出。

为了减少堆溢出错误，一方面可以使用-Xmx参数指定一个更大的堆空间，另一方面，由于堆空间不可能无限增大，通过MAT或者Visual VM等工具，找到大量占用堆空间的对象并在应用程序上做出合理的优化，也是十分必要的。

直接内存溢出

GC调优(命令篇)

运用jvm自带的命令可以方便的在生产监控和打印堆栈的日志信息帮忙我们来定位问题！Sun JDK监控和故障处理命令如下：

jps : 虚拟机进程状况工具

jps ( JVM Process Status Tool ) 的功能:可以列出正在运行的虚拟机进程,并显示虛拟机执行主类(Mam Class,main ( ) 函数所在的类)名称以及这些进程的本地虛拟机唯一ID ( Local Virtual Machine Identifier,LVMID ) 。

jsp命令格式:

jps[options][hostid]

option参数

• -l : 输出主类全名或jar路径
• -q : 只输出LVMID
• -m : 输出JVM启动时传递给main()的参数
• -v : 输出JVM启动时显示指定的JVM参数

其中[option]、[hostid]参数也可以不写。

示例

$ jps -l -m
  28920 org.apache.catalina.startup.Bootstrap start
  11589 org.apache.catalina.startup.Bootstrap start
  25816 sun.tools.jps.Jps -l -m

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

jstat( JVM Statistics Monitoring Tool )是用于监视虚拟机各种运行状态信息的命令行工具。它可以显示本地或者远程虚拟机进程中的类装载、内存、垃圾收集、JIT编译等运行数据是运行期定位虚拟机性能问题的首选工具。

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] : 操作参数
• LVMID : 本地虚拟机进程ID
• [interval] : 连续输出的时间间隔
• [count] : 连续输出的次数

option 参数总览

option 参数详解

-class

监视类装载、卸载数量、总空间以及耗费的时间

$ jstat -class 11589
 Loaded  Bytes  Unloaded  Bytes     Time   
  7035  14506.3     0     0.0       3.67

• Loaded : 加载class的数量
• Bytes : class字节大小
• Unloaded : 未加载class的数量
• Bytes : 未加载class的字节大小
• Time : 加载时间

-compiler

输出JIT编译过的方法数量耗时等

$ jstat -compiler 1262
Compiled Failed Invalid   Time   FailedType FailedMethod
    2573      1       0    47.60          1 org/apache/catalina/loader/WebappClassLoader findResourceInternal  

• Compiled : 编译数量
• Failed : 编译失败数量
• Invalid : 无效数量
• Time : 编译耗时
• FailedType : 失败类型
• FailedMethod : 失败方法的全限定名

-gc

垃圾回收堆的行为统计，常用命令

$ jstat -gc 1262
 S0C    S1C     S0U     S1U   EC       EU        OC         OU        PC       PU         YGC    YGCT    FGC    FGCT     GCT   
26112.0 24064.0 6562.5  0.0   564224.0 76274.5   434176.0   388518.3  524288.0 42724.7    320    6.417   1      0.398    6.815

C即Capacity 总容量，U即Used 已使用的容量

• S0C : survivor0区的总容量
• S1C : survivor1区的总容量
• S0U : survivor0区已使用的容量
• S1U : survivor1区已使用的容量
• EC : Eden区的总容量
• EU : Eden区已使用的容量
• OC : Old区的总容量
• OU : Old区已使用的容量
• PC 当前perm的容量 (KB)
• PU perm的使用 (KB)
• YGC : 新生代垃圾回收次数
• YGCT : 新生代垃圾回收时间
• FGC : 老年代垃圾回收次数
• FGCT : 老年代垃圾回收时间
• GCT : 垃圾回收总消耗时间

$ jstat -gc 1262 2000 20

这个命令意思就是每隔2000ms输出1262的gc情况，一共输出20次

-gccapacity

同-gc，不过还会输出Java堆各区域使用到的最大、最小空间

$ jstat -gccapacity 1262
 NGCMN    NGCMX     NGC    S0C   S1C       EC         OGCMN      OGCMX      OGC        OC       PGCMN    PGCMX     PGC      PC         YGC    FGC 
614400.0 614400.0 614400.0 26112.0 24064.0 564224.0   434176.0   434176.0   434176.0   434176.0 524288.0 1048576.0 524288.0 524288.0    320     1  

• NGCMN : 新生代占用的最小空间
• NGCMX : 新生代占用的最大空间
• OGCMN : 老年代占用的最小空间
• OGCMX : 老年代占用的最大空间
• OGC：当前年老代的容量 (KB)
• OC：当前年老代的空间 (KB)
• PGCMN : perm占用的最小空间
• PGCMX : perm占用的最大空间

-gcutil

同-gc，不过输出的是已使用空间占总空间的百分比

$ jstat -gcutil 28920
  S0     S1     E      O      P     YGC     YGCT    FGC    FGCT     GCT   
 12.45   0.00  33.85   0.00   4.44  4       0.242     0    0.000    0.242

-gccause

垃圾收集统计概述（同-gcutil），附加最近两次垃圾回收事件的原因

$ jstat -gccause 28920
  S0     S1     E      O      P       YGC     YGCT    FGC    FGCT     GCT    LGCC                 GCC                 
 12.45   0.00  33.85   0.00   4.44      4    0.242     0    0.000    0.242   Allocation Failure   No GC  

• LGCC：最近垃圾回收的原因
• GCC：当前垃圾回收的原因

-gcnew

统计新生代的行为

$ jstat -gcnew 28920
 S0C      S1C      S0U        S1U  TT  MTT  DSS      EC        EU         YGC     YGCT  
 419392.0 419392.0 52231.8    0.0  6   6    209696.0 3355520.0 1172246.0  4       0.242

• TT：Tenuring threshold(提升阈值)
• MTT：最大的tenuring threshold
• DSS：survivor区域大小 (KB)

-gcnewcapacity

新生代与其相应的内存空间的统计

$ jstat -gcnewcapacity 28920
  NGCMN      NGCMX       NGC      S0CMX     S0C     S1CMX     S1C       ECMX        EC        YGC   FGC 
 4194304.0  4194304.0  4194304.0 419392.0 419392.0 419392.0 419392.0  3355520.0  3355520.0     4     0

• NGC:当前年轻代的容量 (KB)
• S0CMX:最大的S0空间 (KB)
• S0C:当前S0空间 (KB)
• ECMX:最大eden空间 (KB)
• EC:当前eden空间 (KB)

-gcold

统计旧生代的行为

$ jstat -gcold 28920
   PC       PU        OC           OU       YGC    FGC    FGCT     GCT   
1048576.0  46561.7   6291456.0     0.0      4      0      0.000    0.242

-gcoldcapacity

统计旧生代的大小和空间

$ jstat -gcoldcapacity 28920
   OGCMN       OGCMX        OGC         OC         YGC   FGC    FGCT     GCT   
  6291456.0   6291456.0   6291456.0   6291456.0     4     0    0.000    0.242

-gcpermcapacity

永生代行为统计

$ jstat -gcpermcapacity 28920
    PGCMN      PGCMX       PGC         PC      YGC   FGC    FGCT     GCT   
 1048576.0  2097152.0  1048576.0  1048576.0     4     0    0.000    0.242

-printcompilation

hotspot编译方法统计

$ jstat -printcompilation 28920
    Compiled  Size  Type Method
    1291      78     1    java/util/ArrayList indexOf

• Compiled：被执行的编译任务的数量
• Size：方法字节码的字节数
• Type：编译类型
• Method：编译方法的类名和方法名。类名使用”/” 代替 “.” 作为空间分隔符. 方法名是给出类的方法名. 格式是一致于HotSpot - XX:+PrintComplation 选项

jinfo : Java配置信息工具

jinfo命令格式:

jinfo[option]pid

执行样例:查询CMSInitiatingOccupancyFraction参数值。

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

jmap : Java内存映像工具

jmap ( Memory Map for Java ) 命令用于生成堆转储快照(一般称为heapdump或dump文件 )。如果不使用jmap命令,要想获取Java堆转储快照,还有一些比较“暴力”的手段:譬如-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

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

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

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

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查看线程堆栈(部分结果)

在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>

HSDIS : JIT生成代码反汇编

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

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

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

还需要注意的是,如果读者使用的是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:CompileCommand=compileonly,*Bar.sum test.Bar

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

代码清单4 - 7 测试代码