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

开发 开发工具
4 款可视化工具看下来,个人感觉还是最后一个 JMC 对使用者来讲最友好, MBean 数据源展示了大量的当前 JVM 的信息,而且全都以图表的形式进行了展现,更加给力还是它的 JFR 功能。

[[345792]]

 1. 可视化工具

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

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

这其中除了大量的命令行工具以外,还为我们提供了更加方便快捷的可视化工具,主要是以下这 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 目录,然后执行:

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

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

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

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

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

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

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

  1. public abstract class A { 
  2.     public void printMe() { 
  3.         System.out.println("I am A class"); 
  4.     } 
  5.     public abstract void sayHello(); 
  6.  
  7. public class B extends A { 
  8.     @Override 
  9.     public void sayHello() { 
  10.         System.out.println("I am B class"); 
  11.     } 
  12.  
  13. public class HSDB_Test { 
  14.     public static void main(String[] args) throws IOException { 
  15.         A obj = new B(); 
  16.         // 无意义,单纯用作卡住主线程,防止线程结束 
  17.         System.in.read(); 
  18.         System.out.println(obj); 
  19.     } 

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

  1. PS C:\Users\inwsy> jps -l 
  2. 1648 com.geekdigging.lesson04.jvmtools.HSDB_Test 
  3. 8704 
  4. 9280 org.jetbrains.jps.cmdline.Launcher 
  5. 14724 jdk.jcmd/sun.tools.jps.Jps 
  6. 3220 org/netbeans/Main 
  7. 15144 
  8. 20572 org.jetbrains.jps.cmdline.Launcher 
  9. 7548 sun.jvm.hotspot.HSDB 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

第一列是方法实际在堆中的内存地址,第二列则是内存指针地址,我们可以将拿到的内存指针地址去 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 就可以直接启动,在启动之后,会自动搜索出当前在本机运行的所有虚拟机进程。

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

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

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

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

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

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

  1. public class MonitoringTest { 
  2.     // 内存占位对象,一个对象大约 64KB 
  3.     static class OOMObject { 
  4.         public byte[] placeholder = new byte[64 * 1024]; 
  5.     } 
  6.  
  7.     public static void fillHeap(int nums) throws InterruptedException { 
  8.         List<OOMObject> list = new ArrayList<>(); 
  9.         for (int i = 0; i < nums; i++) { 
  10.             Thread.sleep(50); 
  11.             list.add(new OOMObject()); 
  12.         } 
  13.         System.gc(); 
  14.     } 
  15.  
  16.     public static void main(String[] args) throws InterruptedException { 
  17.         fillHeap(1000); 
  18.     } 

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

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

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

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

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

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

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

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

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

先修改下代码:

  1. public static void main(String[] args) throws InterruptedException { 
  2.     fillHeap(1000); 
  3.     System.gc(); 
  4.     // GC 后停顿 3s ,方便观察图像 
  5.     Thread.sleep(3000); 
JVM:可视化 JVM 故障处理工具

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

3. VisualVM

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

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

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

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

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

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

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

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

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

[[345794]]

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

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

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

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

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

在启动过程中, 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 收集器的配置:

  1. -XX:+UseG1GC 

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

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

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

然后再看下 GC 面板:

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

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

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

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

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

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

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

4. Java Mission Control

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

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

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

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

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

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

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

  1. -XX:+UnlockCommercialFeatures 
  2. -XX:+FlightRecorder 
JVM:可视化 JVM 故障处理工具

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

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

5. 小结

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

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

 

责任编辑:张燕妮 来源: 今日头条
相关推荐

2010-10-11 11:03:01

MySQL管理工具

2012-01-11 13:04:40

JavaJVM

2021-02-21 08:11:46

PythonDash工具

2020-03-11 14:39:26

数据可视化地图可视化地理信息

2010-05-11 18:35:47

MySQL数据库

2019-10-10 08:46:02

Docker可视化技术浏览器

2017-10-17 14:02:30

jvm调优工具

2020-07-27 09:59:25

Kafka可视化CMAK

2022-05-24 15:03:44

开源工具可视化

2021-02-07 20:23:09

GoogeBlockly可视化编程

2022-03-03 13:02:37

可视化网页低代码编程工具

2018-05-31 08:25:13

误区工具可视化

2010-09-30 15:54:58

系统升级

2021-03-01 07:45:32

kubernetes应用程序工具

2022-08-26 09:15:58

Python可视化plotly

2009-04-21 14:26:41

可视化监控IT管理摩卡

2017-10-14 13:54:26

数据可视化数据信息可视化

2021-07-08 06:47:19

JVM监控工具

2010-09-27 15:39:37

JVM监控工具

2017-04-19 08:32:50

大数据数据可视化编程工具
点赞
收藏

51CTO技术栈公众号