visualvm工具 Visual GC分析例子（二）

最新推荐文章于 2024-05-14 20:34:38 发布

跑快点，懦夫！

最新推荐文章于 2024-05-14 20:34:38 发布

阅读量1.1k

点赞数 20

文章标签： jvm

本文链接：https://blog.csdn.net/qq_41158114/article/details/137642072

版权

visualvm控制台

visualvm控制台有概述、监视、抽样器等菜单，同时，可以装入插件扩展功能——

1、概述

可以看到jvm参数、系统属性、jdk版本与安装路径等信息；

设置的jvm参数，这里新生代分配了最小堆空间是256m，最大堆空间是256m，新生代128m，元空间是128m，堆=新生代+老年代，不包括永久代（方法区），这就意味着，这配置当中的老年代=128m。

-Xms256M -Xmx256M -Xmn128M -XX:PermSize=128M -XX:MaxPermSize=256M

这些都是指定JVM参数运行对应的jar进程，除此之外，还有其他参数可做设置

2、监视

监控模块可以实时看到进程所在的堆、元空间、类及线程的报表数据监控，其中，堆和元空间的报表对调优可以起到很有用的帮助。在这里插入图片描述

Visual GC

除了visualvm自带的功能外，我们需要装入一个实时监控GC的插件visualgc，这个插件很方便对JVM做监控与调优。

插件装载方式，右击工具栏，选择插件——
在这里插入图片描述
安装成功后，重启一下visualvm，就可以看到菜单栏上多出一个Visual GC插件——

Visual gc 工具分成布局分成三部分，可在右上角对应方框里勾选【Space】【Graphs】【Histogram】，它们各自的作用——

可视化GC窗口（space）

图形统计窗口（Graphs）

幸存者年龄直方图窗口（Histogram）

下面分别介绍各自窗口与其显示的数字表示——

1、可视化GC窗口（space）

VisualGC窗口是最左的窗口，分成三条垂直柱体，在JDK1.8版本中，分别代表metaSpace元空间、Old老年代、新生代，其中新生代又划分成 Eden 区， S0 区， S1区三部分。柱体里颜色部分代表占用的空间，空白部分表示剩余空间。监控项目的堆进程时，这些代表颜色的地方都是动态变化的。
在这里插入图片描述

2、图形统计窗口（Graphs）

图形窗口显示各种统计值随时间的变化。

一、Compile Time

显示将Java字节代码编译为本机代码所花费的时间量。窄脉冲表示持续时间相对较短，宽脉冲表示持续时间较长。

编译任务的数量5508；

累计编译时间27.721s。在这里插入图片描述

二、Class Loader Time

此面板显示在类加载和卸载活动中花费的时间量。窄脉冲表示持续时间相对较短，宽脉冲表示持续时间较长。

加载的类数量：11337；

卸载的类的数量：0

累计的类加载时间：15.589s 在这里插入图片描述

三、GC Time

此面板显示垃圾收集活动所花费的时间量。窄脉冲表示持续时间相对较短，宽脉冲表示持续时间较长。

执行GC垃圾回收总次数：9次（9 collections代表自监视以来执行9次GC，其中，包括新生代的Minor GC和老年代的Full Gc）

累计的GC时间:888.929ms；

若JVM维护hotspot.gc.cause和hotspot.gc.last_cause计数器，则gc事件的原因将出现在last Cause中；
在这里插入图片描述

四、Eden Space

此面板显示Eden空间随时间的利用情况。它是年轻代的三个空间之一，另外两个分别是S0、S1。空间的当前容量可以根据收集器策略动态更改，即通过修改–Xmn参数，会改变其大小。

标题栏第一个参数代表最大容量，第二个参数代表当前容量，后跟当前占用空间。此外，还包含了年轻代GC事件数量和GC累计时间。

Eden Space最大可分配空间：102.500M；

Eden Space当前已分配空间：102.500M；

Eden Space当前占用空间：54.523M(当积累的占用空间超过102.500M，就会在Eden Space发生一次Minor GC)

Minor GC次数：6次

Minor GC花费时间：286.621ms
在这里插入图片描述

五、Survivor 0 and Survivor 1

HotSpot JVM把年轻代分为了三部分：1个Eden区和2个Survivor区（分别叫from和to），默认大小比例为Eden:Survivor0:Survivor1=8:1:1的。　新创建的非大对象，会存放在Eden区和一个作为from的Survivor区，当发生一次Minor GC时，就会将Eden区和作为from的Survivor区内仍存活的对象，复制到另一个作为to的Survivor区，然后清理掉原来Eden区和作为from的Survivor区内对象。因此，S0 和 S1 之间至少有一个肯定是空闲的。

Survivor 0区最大分配容量：12.750M；

Survivor 0区当前已分配容量：12.750M；

Survivor 0区当前占用容量：0M；
在这里插入图片描述

五、Old Gen

面板显示老年代随着时间推移的利用情况。

Old Gen 最大分配空间128M；

Old Gen 已分配空间128M；

Old Gen 当前占用空间38.06M；

Old Gen 发生的GC次数：3次；

Old Gen 发生的GC花费时间：602.309ms；
在这里插入图片描述

六、（MetaSpace）Perm Gen

标题栏在括号中显示空间的名称及其最大容量和当前容量，后跟空间的当前占用大小在这里插入图片描述

例子

visual VM工具的相关功能使用主要就那么多，下面就简单介绍一下入门调优的案例，小白都能看懂的。

假如某天你观察到使用visual VM工具的Visual GC插件观察到以下的图表——新生代Eden区已经发生了8168次Minor GC，耗时39.754s,另外老年代也发生了24次GC，耗时5.124s。可见，该JVM参数设置得极不合理，导致已经过于频繁发生Minor GC。
在这里插入图片描述
那么，我们该如何调优进行设置呢？

JVM调优无外乎就是对相关参数进行设置，这里，我们先做一些最简单的参数，好让小白也能理解，那么，就暂时先对-Xms、-Xmx、-Xmn参数设置。

截图中，可以看到新生代中的Eden区频繁发生Minor GC，原因之一是分配的空间过小，目前是204.875M，导致当前占用空间经常超过204.875M，进而发生GC。若要分析是哪些代码频繁创建对象，还得进一步通过dump等方式进行分析，这里暂时不展开。

解决该Eden区其中一个思路是，提升分配给Eden区的大小。

那么，多大才比较合适呢？

这时，Visual VM的监视栏中的堆监控就派上用场了。可以观察到蓝色模块高度比较均衡地对应在纵坐标280MB的样子，也就是说，新创建的对象+每次gc未被清除的对象其占有的大小达到近300MB，而Eden Space + 其中一个Survivor才230MB左右，可见，每次新创建的对象很容易就超过新生代，这就意味着，频繁发生Minor GC是必然的，从图的横坐标可以看出，每30ms内，就发生了2到3次的Minor GC。
在这里插入图片描述
为了避免Eden区频繁发生Minor GC，根据堆监控图表，可以考虑在设置JVM参数时，适当提升分配给Eden的空间，至少超过现在的240MB以上，可以考虑先设置到300MB的样子，看下效果，当然，这是在项目比较平稳运行的情况下来看的，实际生产当中，还需要考虑到高峰时期。

就暂且先设置Eden区为320MB，考虑到Eden:Survivor0:Survivor1=8:1:1比例，也就是8:2，若要分配Eden=320M，那么，可以根据8/2=320/x算出来，x=80，这里的x就是两个Survivor总大小，即每个Survivor分配40MB，那么，年轻代总共需要分配的大小为（320M+40M*2）=400M，即-Xmn400m

再来看下老年代，目前老年代发生了24次GC，最大分配空间是256MB，当前最小分配空间是71.48M，可见，还可以适当进行优化。
在这里插入图片描述
一般而言，最大分配空间与最小分配空间最好保持一致,这样避免每次空间不够时都需自动提升当前分配大小。