JVM:可视化 JVM 故障处理工具

JVM:可视化 JVM 故障处理工具

 1. 可视化工具

在 JDK 中为我们提供了大量的 JVM 故障处理工具,都在 JDK 的 bin 目录下:

这其中除了大量的命令行工具以外,还为我们提供了更加方便快捷的可视化工具,主要是以下这 4 个:

  • JConsole: 最古老的工具,早在 JDK 5 时期就已经存在的虚拟机监控工具。
  • JHSDB: 名义上在 JDK 9 中才正式提供,但之前已经以 sa-jdi.jar 包里面的 HSDB(可视化工具) 和 CLHSDB(命令行工具) 的形式存在了很长一段时间。
  • VisualVM: 在 JDK 6 Update 7 中首次发布,直到 JRockit Mission Control 与 OracleJDK 的融合工作完成之前,它都曾是 Oracle 主力推动的多合一故障处理工具,现在它已经从 OracleJDK 中分离出来,成为一个独立发展的开源项目。
  • JMC: Java Mission Control ,曾经是大名鼎鼎的来自 BEA 公司的图形化诊断工具,随着 BEA 公司被 Oracle 收购,它便被融合进 OracleJDK 之中。在 JDK 7 Update 40 时开始随 JDK 一起发布,后来 Java SE Advanced 产品线建立, Oracle 明确区分了 Oracle OpenJDK 和 OracleJDK 的差别, JMC 从 JDK 11 开始又被移除出 JDK 。

2. HSDB

HSDB(Hotspot Debugger) 是 JDK 自带的工具,用于查看 JVM 运行时的状态。

使用方式由于在 JDK 9 之前没有正式提供,所以也未在 JDK 的 bin 目录下提供直接可执行文件,需要在命令行执行命令才能启动。

首先在命令行中先 cd 至 C:\Program Files\Java\jdk1.8.0_221\lib 目录,然后执行:

java -cp .\sa-jdi.jar sun.jvm.hotspot.HSDB 

我在执行这句命令的时候报了个错:

Exception in thread "Thread-1" java.lang.UnsatisfiedLinkError: Can't load library: C:\Program Files\Java\jdk-11.0.4\bin\sawindbg.dll 
        at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2620) 
        at java.base/java.lang.Runtime.load0(Runtime.java:767) 
        at java.base/java.lang.System.load(System.java:1831) 
        at sun.jvm.hotspot.debugger.windbg.WindbgDebuggerLocal.<clinit>(WindbgDebuggerLocal.java:661) 
        at sun.jvm.hotspot.HotSpotAgent.setupDebuggerWin32(HotSpotAgent.java:567) 
        at sun.jvm.hotspot.HotSpotAgent.setupDebugger(HotSpotAgent.java:335) 
        at sun.jvm.hotspot.HotSpotAgent.go(HotSpotAgent.java:304) 
        at sun.jvm.hotspot.HotSpotAgent.attach(HotSpotAgent.java:140) 
        at sun.jvm.hotspot.HSDB.attach(HSDB.java:1184) 
        at sun.jvm.hotspot.HSDB.access$1700(HSDB.java:53) 
        at sun.jvm.hotspot.HSDB$25$1.run(HSDB.java:456) 
        at sun.jvm.hotspot.utilities.WorkerThread$MainLoop.run(WorkerThread.java:66) 
        at java.base/java.lang.Thread.run(Thread.java:834) 

含义是有一个 sawindbg.dll 在 jdk 的目录下找不到,因为我本地有多个 jdk ,配置环境变量的是 jdk 11 ,我在 jdk 8 的 jre 的 bin 目录下找到了这个文件,直接 copy 到 jdk 11 的bin 目录下解决此问题。

执行完成后会打开这么个界面:

接下来,我们写一小段测试代码:

public abstract class A { 
    public void printMe() { 
        System.out.println("I am A class"); 
    } 
    public abstract void sayHello(); 
} 
 

public class B extends A { 
    @Override 
    public void sayHello() { 
        System.out.println("I am B class"); 
    } 
} 
 

public class HSDB_Test { 
    public static void main(String[] args) throws IOException { 
        A obj = new B(); 
        // 无意义,单纯用作卡住主线程,防止线程结束 
        System.in.read(); 
        System.out.println(obj); 
    } 
} 

首先在命令行中使用命令 jps -l 查看 Java 进程的 pid :

PS C:\Users\inwsy> jps -l 

1648 com.geekdigging.lesson04.jvmtools.HSDB_Test 

8704 

9280 org.jetbrains.jps.cmdline.Launcher 

14724 jdk.jcmd/sun.tools.jps.Jps 

3220 org/netbeans/Main 

15144 

20572 org.jetbrains.jps.cmdline.Launcher 

7548 sun.jvm.hotspot.HSDB 

可以看到,我们刚写的测试方法的 pid 是 1648 ,在 HSDB 中点击 File > Attach to Hotspot process :

第一个看到的就是当前进程中的线程:

到这里,我们的准备工作就已经结束,接着我们使用 Tools > Class Browser 找到对象 B 的内存地址:

图中红框框起来的是我自己写的三个类,可以看到我这里 B 的内存地址是 0x00000007c0060c18。

接下来,使用 Tools > Inspector 查看这个对象的详细信息:

vtable 是虚表方法,这里我们看到 class B 有 7 个虚表方法,因为所有的对象都继承自 Object ,所以 B 继承了 Object 的 5 个方法,然后还继承了 A 的一个方法,自己重写了一个方法,总共是 7 个方法。

这个我们可以进行一下验证,可以在 Windows > Console 中使用 mem 命令进行查看。

那么我们可以开始计算, vtable 是在 instanceKlass 对象实例的尾部,而 instanceKlass 大小在 64 位系统的大小为 0x1B8 ,因此 vtable 的起始地址等于 instanceKlass 的内存首地址加上 0x1B8 等于 7C0060DD0 。

接下来,我们在 Windows > Console 中使用 mem 命令进行验证:

第一列是方法实际在堆中的内存地址,第二列则是内存指针地址,我们可以将拿到的内存指针地址去 A , B 和 Object 中分别查看,可以看到前 5 行对应的是 Object 的方法,第 6 行对应的是 A 对象中的方法,第 7 行则对应 B 对象中的方法。

3. JConsole

JConsole(Java Monitoring and Management Console) 是一款基于 JMX(Java Manage-ment Extensions) 的可视化监视、管理工具。它的主要功能是通过 JMX 的 MBean(Managed Bean) 对系统进行信息收集和参数动态调整。

JConsole 位于 JDK/bin 这个目录下,直接双击 jconsole.exe 就可以直接启动,在启动之后,会自动搜索出当前在本机运行的所有虚拟机进程。

这里可以看到我本机目前运行了一个 JConsole ,一个 idea ,还有一个启动的 tomcat 的源码。

随便双击一个服务,进入主页面:

可以看到主界面里共包括概述、内存、线程、类、 VM 摘要、 MBean 六个页签。

还是来个小示例,我们来了解下它的监控功能。

public class MonitoringTest { 
    // 内存占位对象,一个对象大约 64KB 
    static class OOMObject { 
        public byte[] placeholder = new byte[64 * 1024]; 
    } 
 
    public static void fillHeap(int nums) throws InterruptedException { 
        List<OOMObject> list = new ArrayList<>(); 
        for (int i = 0; i < nums; i++) { 
            Thread.sleep(50); 
            list.add(new OOMObject()); 
        } 
        System.gc(); 
    } 
 
    public static void main(String[] args) throws InterruptedException { 
        fillHeap(1000); 
    } 
} 

这个案例是使用大约 64KB/50ms 的速度向 Java 堆中填充数据,一共填充 1000 次。

程序执行后可以看到,在整个 Java 堆中,曲线一直是平滑向上的。

切换到内存标签页,查看 Eden 后可以发现,整个 Eden 的图形是一个折线:

再切换到 Gen ,可以看到整个老年代也是折叠向上的:

我们已经在代码里加了 System.gc() ,为什么看起来没生效呢?

因为 System.gc() 是在 fillHeap() 方法中的,在 GC 的时候,还在作用域中,想要正常回收老年代,需要将 System.gc() 这段代码转移到 fillHeap() 外面。

先修改下代码:

public static void main(String[] args) throws InterruptedException { 
    fillHeap(1000); 
    System.gc(); 
    // GC 后停顿 3s ,方便观察图像 
    Thread.sleep(3000); 
} 

可以看到在最后进程结束的时候, Gen 的柱状图已经没有内存占用了,内存回收成功。

3. VisualVM

VisualVM(All-in-One Java Troubleshooting Tool)是功能最强大的运行监视和故障处理程序之一,曾经在很长一段时间内是 Oracle 官方主力发展的虚拟机故障处理工具。

VisualVM 同样在 JDK/bin 这个目录下,双击 jvisualvm.exe 即可运行。在启动之后,直接在左侧会显示当前在本机运行的所有虚拟机进程。

VisualVM 基于 NetBeans 平台开发工具,所以一开始它就具备了通过插件扩展功能的能力,有了插件扩展支持, VisualVM 可以做到:

  • 显示虚拟机进程以及进程的配置、环境信息(jps、jinfo)。
  • 监视应用程序的处理器、垃圾收集、堆、方法区以及线程的信息(jstat、jstack)。
  • dump 以及分析堆转储快照(jmap、jhat)。
  • 方法级的程序运行性能分析,找出被调用最多、运行时间最长的方法。
  • 离线程序快照:收集程序的运行时配置、线程 dump 、内存 dump 等信息建立一个快照,可以将快照发送开发者处进行 Bug 反馈。
  • 其他插件带来的无限可能性。

VisualVM 的插件可以在 工具->插件 中联网后直接安装。

我这里只安装了两个最常用的,一个是 GC 监控的插件,还有一个可以动态插入调试程序的插件。

我这里使用最常用的开发工具 IDEA 启动过程演示一下通过 VisualVM 监控程序 GC 。

首先我们启动 IDEA ,直到 IDEA 可以正常操作,看下 VisualVM 的 GC 监控。

在主信息面板,可以看到 IDEA 所使用 JVM 的版本信息,可以看到具体的 JAVA_HOME 路径,还可以看到具体的 JVM 参数,这里可以看到 IDEA 启动时设置的默认最小堆和最大堆内存的设置分别是 128MB 和 750 MB ,所使用的垃圾回收器则是 CMS 收集器。

然后点击 Visual GC,可以看到:

在启动过程中, Class 加载消耗了 28s 左右,而 Class 编译则消耗了 35s 。并且在这个过程中, Minor GC 被触发了 149 次,消耗只有 713ms ,我们更加关注的 Full GC 更是一次都没有触发,消耗为 0 。

因为 IDEA 默认使用的是 CMS 收集器,如果我们换成 G1 收集器会不会更快一些呢?

首先,找到 IDEA 的配置文件,我的 IDEA 是通过 Toolbox 进行安装的,所以我的 IDEA 的配置文件的路径有点奇怪D:\Program Files\JetBrains\apps\IDEA-U\ch-0\202.7660.26.vmoptions 。

先把这个文件备份到桌面一个,防止改坏了导致 IDEA 不能使用。

删掉现有的垃圾回收器配置 -XX:+UseConcMarkSweepGC ,增加 G1 收集器的配置:

-XX:+UseG1GC 

其余的配置不做修改,直接关闭 IDEA 重启,再看下 GC 情况。

首先先看下主面板,看下我们的 GC 收集器是否已经切换成功:

然后再看下 GC 面板:

Minor GC 竟然被触发了 271 次,而且消耗达到了 853ms ,好吧,看来在客户端还是更适合使用 CMS 做为垃圾回收器。

我们再修改下 -Xmx 这个配置,将配置的大小缩减为现在的一半,再把 GC 换回原有的 CMS ,看下 Full GC 的情况:

可以看到, Full GC 整整发生了 46 次,并且耗时超过了 21s ,而且这是 IDEA 的界面上也开始弹出警告,警告我们内存不足了,需要调整。

吓得我赶紧改回了原有配置,顺便把 -Xmx 的大小加到了 1024 ,尽量减少 Full GC 的情况。

4. Java Mission Control

JMC 同样在 JDK/bin 这个目录下,双击 jmc.exe 即可运行。

打开后在 JVM 浏览器面板中有两个选项,一个是 MBean ,一个是 JFR 飞行记录器。

关于 MBean 这部分数据,与 JConsole 和 VisualVM 上取到的内容是一样的,只是展示形式上有些差别,就不多说了。

双击「飞行记录器」,将会出现「飞行记录器」窗口(如果第一次使用,还会收到解锁商业功能的警告窗)。

注意:在使用前需要在 JVM 中增加如下两个参数,含义是解锁 JFR 功能的锁定。

-XX:+UnlockCommercialFeatures 
-XX:+FlightRecorder 

飞行记录报告里包含以下几类信息:

  • 一般信息:关于虚拟机、操作系统和记录的一般信息。
  • 内存:关于内存管理和垃圾收集的信息。
  • 代码:关于方法、异常错误、编译和类加载的信息。
  • 线程:关于应用程序中线程和锁的信息。
  • I/O:关于文件和套接字输入、输出的信息。
  • 系统:关于正在运行Java虚拟机的系统、进程和环境变量的信息。
  • 事件:关于记录中的事件类型的信息,可以根据线程或堆栈跟踪,按照日志或图形的格式查看。

5. 小结

相关推荐