在生产环境中执行的应用程序当出现响应时间慢以及过于频繁的GC，那么此时就需要收集JVM运行的数据来分析是什么原因导致了应用程序响应时间慢，也许在这个过程中出现了大量的文件I/O加载导致都有可能导致程序出现内存泄露等情况。特别是在企业级的生产环境中，在出现问题的时候很难使用主流的可视化工具来查看JVM运行过程中的数据，此时可以使用jstat命令工具来收集JVM运行过程中的数据，下面详细地阐述jstat命令行工具的案例应用与实战。
jstat全称为JVM Statistics Monitoring Tool，它主要用于收集JVM在执行过程中运行的各种数据，如垃圾收集，GC次数以及YGC、YGCT等数据。jstat是一个命令行的工具，下面汇总了jstat命令行使用过程中常用到的选项，具体如下所示。
jstat案例实战
在案例代码中编写了不断的加载对象，持续的进行最终会导致程序出现内存泄露，涉及到的案例代码如下。
启动应用程序，逐步地演示下上面阐述到的各个命令行选项工具的应用。首先来看“-class”中需要输出的信息，每隔1秒打印一次并且加上时间戳,打印10次，每5行输出表头信息，执行命令以及输出的结果信息如下：
备注：如上可以看到类装载、卸载数量、装载耗时都是呈上升的趋势。
下面再演示下可能出现内存泄露的情况下新生代指标的变化趋势，执行命令以及输出结果信息如下：
备注：如上输出信息中，可以看到新生代空间EU从1738.5一直上升到6665.8，YGC的次数最多是77，YGCT耗时时间从0.121s一直上升到0.149s。
如下演示可能出现内存泄露的情况下老年代指标变化的趋势过程，执行的命令以及输出的结果信息如下：
备注：在如上可以看到OU的变化趋势是上升到21711.1最后是下降的趋势，而YGC、FGC的次数一直是上升的趋势，FGCT、GCT的耗时也是上升的趋势，其中GCT的总耗时最大是8.669s。
判断是否内存泄露
在jstat命令行工具中可以根据如下的思路来判断是否可能出现了内存泄露，具体思路如下：
根据如上的思路，下面调用应用程序的不同接口，关注所有的GC指标，执行的命令以及输出的值信息如下
备注：在如上中依据每5行输出一次表头信息，而OU的值分别是：19491.3、20336.9、20549.8、21528.9、21558.3、21578.2，可以看到OU的值呈上升的趋势，根据之前的判断思路程序很有可能出现内存泄露，程序端运行错误确实显示了内存泄露的错误信息，具体为：java.lang.OutOfMemoryError: Java heap space。在上面的数据中也可以看到YGC、FGC都在上升，特别是FGC从2一直上升到了309，变化趋势很大，对应的FGCT它的耗时也是从0.108一直到最后的15.962，而YGC、YGCT有变化趋势但是不是那么很明显。FGCT耗时拉高了整体的GCT的耗时，总耗时最后是16.198，等于FGCT占用了总耗时的98.54%。因此在工作中当程序很有可能内存泄露的时候重点关注OU的值，以及对应的FGC次数、FGCT耗时情况。
版权声明：
本文来源网络，所有图片文章版权属于原作者，如有侵权，联系删除。
本文网址：https://www.mushiming.com/mjsbk/3393.html