亲宝软件园·资讯

展开

JVM 故障处理工具 深入理解可视化JVM 故障处理工具

极客挖掘机 人气:0
想了解深入理解可视化JVM 故障处理工具的相关内容吗,极客挖掘机在本文为您仔细讲解JVM 故障处理工具的相关知识和一些Code实例,欢迎阅读和指正,我们先划重点:JVM,故障处理工具,JVM,故障处理,下面大家一起来学习吧。

本文内容过于硬核,建议有 Java 相关经验人士阅读。

1. 可视化工具

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

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

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 可以做到:

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

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

5. 小结

这 4 款可视化工具看下来,个人感觉还是最后一个 JMC 对使用者来讲最友好, MBean 数据源展示了大量的当前 JVM 的信息,而且全都以图表的形式进行了展现,更加给力还是它的 JFR 功能,可以记录一段时间内所有的操作,并且以图表的形式进行展现,对我们分析问题时候的帮助无疑是巨大的。

当然,喜欢用哪款工具完全是个人喜好,比如 VisualVM 也很强大,可能它本身的功能没那么强,但是它可以安装插件,完全根据需要进行插件的安装,这个玩法非常 DIY ,总的算下来,我还是喜欢使用 VisualVM 更多一些。

参考

深入理解Java虚拟机:JVM高级特性与最佳实践_周志明

加载全部内容

相关教程
猜你喜欢
用户评论