来自JRockit的礼物:JMC虚拟机诊断工具

来自JRockit的礼物:JMC虚拟机诊断工具,第1张

来自JRockit的礼物:JMC虚拟机诊断工具 来自JRockit的礼物——JMC

在Oracle收购Sun之前,Oracle的JRockit虚拟机提供了一款叫作JRockitMissionControl的虚拟机诊断工具。在Oracle收购Sun之后,Oracle公司同时拥有了SunHotspot和JRockit两款虚拟机。根据Oracle对于Java的战略,在今后的发展中,会将JRockit的优秀特性移植到Hotspot上。其中,一个重要的改进就是在Sun的JDK中加入了JRockit的支持。在OracleJDK7update40之后,MissionControl这款工具已经绑定在OracleJDK中发布(很不幸,OpenJDK中并没有该工具)。这是一款集性能监控、诊断为一体的多功能工具。

安装完JDK后,可以在%JAVA_HOME%/bin目录下找到这个工具。如图6.114所示为JMC运行后的主界面。

一,得到JFR文件

为了更好地使用JMC对生产环境中的虚拟机进行监控,我们需要首先采集到程序执行时的JFR文件,即JavaFlightRecorder,Java飞行记录仪。它记录了JVM所有事件的历史数据,通过这些数据,程序性能分析人员可以结合以往的历史数据对JVM性能瓶颈进行分析诊断。JMC也正是利用了这个文件,统计出了程序执行时的性能指标。

得到JFR文件的方法主要有3种,第1种是通过Java虚拟机的静态命令行指定的,例如:

其中,UnlockCommercialFeatures表示解锁商业开关,可见这是一个商业功能;Flight-Recorder表示打开飞行记录仪;接着通过StartFlightRecording参数指定了启动飞行记录仪的各项参数,例如系统启动后,延时10s启动记录,飞行记录仪记录时长为10min,保存的文件名为recording.jfr,使用profile级别进行记录;最后通过FlightRecorderOptions选项将飞行记录仪自身的log级别设置为info,帮助开发人员排查飞行记录自身的问题。

这里需要注意的是,JMC自带两种样本采集级别,一个是default,另外一个是profile。两者的区别是:profile提供了比default更多的性能指标及更加频繁的样本采集频率。根据笔者的经验,在绝大部分场景中,使用default方式采集JFR数据对系统整体的性能影响应该不会超过5%,而使用profile则不会超过10%。

第2种得到JFR文件的方法是使用动态命令行。首先,使用如下命令行参数启动Java程序:

此时,飞行记录仪并不会开始记录任何数据。接着,在需要记录的时候,手工执行如下命令:

此时,飞行记录仪开始记录数据。当需要将记录数据导出为文件时,再执行以下命令:

到这里,便将这段时间内的性能统计数据导出来了。

第3种得到JFR的方法,则是在系统退出时自动保存,例如:

上述参数指定了dumponexit选项,也意味着程序在退出后会自动导出JFR文件。

二,Java程序的整体运行情况

当使用JMC打开一个JFR后,便可以看到程序的整体运行信息了。

如图6.115所示,显示了程序在给定时间内的堆、CPU和GC的整体情况,如最大值、平均值等,也有计算机整体CPU情况、JVM应用及JVM内核CPU使用情况。在图6.115中,系统的整体运行健康状况一览无余。

三,CPU分析

使用JMC的CPU分析功能,不仅可以获得热点方法,还可以知道调用的堆栈,十分有利于我们发现程序潜在的性能问题。

如图6.116所示,我们可以非常清楚地看到当前系统中只有HoldCPUMain一个类占用了大量的CPU,并且它是通过产生随机数这种方式消耗CPU的。

四,内存分析

使用JMC还可以进行堆内存分析。如图6.117所示为堆的总体使用情况。

概览信息可以帮助我们总体上了解堆的使用情况及GC *** 作概况,对程序的大体情况有一个初步的了解。而“分配”选项卡则可以进一步帮助开发者定位内存的具体分配情况,如图6.118所示。

在“分配”选项卡中,列出了对象在TLAB中和非TLAB中的堆内存的具体分配情况。在这里可以非常清楚地看到什么对象被分配得最多,以及哪个函数调用产生了这些对象,这对于程序的内存优化是非常重要的。通常来说,那些堆内存被分配得最多的对象,往往是可以进行一些优化的,而堆栈跟踪则又告诉我们“去哪里”优化这些对象。

但需要注意的是,在default级别的JFR中,对象的分配信息并不会被记录抓取,因此如果需要获得这些具体的细节信息,则必须使用profile级别的抓取。

根据图6.118的提示,找到对应代码如下:

可以看到,visitWeb()函数中对StringBuffer进行追加字符串时,产生了大量的内存分配。而这些分配并非必需的,它们是由于初始StringBuffer容量不足,而不断进行扩展时所产生的对象分配(可以通过堆栈跟踪得出)。因此,如果在上述代码第11行预设String-Buffer的初始容量,就可以有效减少被分配的对象,从而提升系统性能。

五,I/O分析

使用JMC也可以跟踪系统的I/O使用情况。在I/O页面上,可以分别看到文件和套接字的读取和写入情况。以套接字为例,可以看到程序所访问的远程主机地址及读取的数据量大小,如图6.119所示。

在套接字概览中,可以看到当前程序从www.baidu.com主机上读取了大约4.48MB数据。更进一步,通过“套接字读取”选项卡,则可以跟踪堆栈调用,更清楚地显示哪些方法调用产生并使用了这个套接字连接和数据,如图6.120所示。

可以看到,当前套接字的数据读取主要是由visitWeb()函数触发的,而visitWeb()函数最终使用SocketInputStream完成网络数据的读取。

小结

本章主要介绍了常用的性能采集工具和故障排查工具。首先详细介绍了基于Linux系统和Windows系统的性能采集工具,使用这些工具有助于开发者定位性能瓶颈;接着介绍了JDK自带的一些性能和故障排查相关的命令,如jps、jstack、jmap和jcmd等,以及免费的可视化工具JConsole、VisualVM和MAT;此外,本章还用了大量篇幅介绍了对象查询语言OQL及功能非常强大的JMC

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/zaji/5612519.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-12-15
下一篇 2022-12-15

发表评论

登录后才能评论

评论列表(0条)

保存