网站平台怎么建设,做网站电话销售说辞,自己建网站要学什么,qq推广软件一 Visual VM
1.1 概述
Visual VM是一个功能强大的多合一故障诊断和性能监控的可视化工具。
它集成了多个JDK命令行工具#xff0c;使用Visual VM可用于显示虚拟机进程及进程的配置和环境信息(jps,jinfo)#xff0c;监视应用程序的CPU、GC、堆、方法区及线程的信息(jstat…一 Visual VM
1.1 概述
Visual VM是一个功能强大的多合一故障诊断和性能监控的可视化工具。
它集成了多个JDK命令行工具使用Visual VM可用于显示虚拟机进程及进程的配置和环境信息(jps,jinfo)监视应用程序的CPU、GC、堆、方法区及线程的信息(jstat、jstack)等甚至代替JConsole。
VisualVM: Home
1.在idea中进行安装 2.功能结构说明 1.2 概述 二 VisualGC功能介绍
2.1 visualGC的安装
如果页面缺少visual GC 插件则需要选择【工具 -》 插件】进行安装安装插件 安装成功后重启一下visualvm就可以看到菜单栏上多出一个Visual GC插件 2.2 功能页面介绍
Visual gc 工具分成布局分成三部分可在右上角对应方框里勾选【Space】【Graphs】【Histogram】
可视化GC窗口spacespaceMetaspace元数据、Old老年代、新生代Eden、S0、S1
图形统计窗口GraphsGraphsCompile Time编译时间、Class Loader Time类加载时间、GC Time垃圾收集时间、Eden Space、Survivor 0、Survivor 1、Old Gen、Metaspace
幸存者年龄直方图窗口HistogramHistogramParameters参数设置 2.2.1 可视化GC窗口space
VisualGC窗口是最左的窗口分成三条垂直柱体在JDK1.8版本中分别代表metaSpace元空间、Old老年代、新生代其中新生代又划分成 Eden 区 S0 区 S1区三部分。柱体里颜色部分代表占用的空间空白部分表示剩余空间。监控项目的堆进程时这些代表颜色的地方都是动态变化的。 2.2.2 图形统计窗口Graphs 1.compile Time
功能: 显示将Java字节代码编译为本机代码所花费的时间量。窄脉冲表示持续时间相对较短宽脉冲表示持续时间较长。
编译任务的数量 1101 compiles1101次编译
累计编译时间 27.721s。
2.class loader Time
此面板显示在类加载和卸载活动中花费的时间量。窄脉冲表示持续时间相对较短宽脉冲表示持续时间较长。
加载的类数量1058
卸载的类的数量63
累计的类加载时间278.915s
3. GC Time
此面板显示垃圾收集活动所花费的时间量。窄脉冲表示持续时间相对较短宽脉冲表示持续时间较长。
执行GC垃圾回收总次数42次42collections代表自监视以来执行2次GC其中包括新生代的Minor GC和老年代的Full Gc
累计的GC时间: 140.179ms
若JVM维护hotspot.gc.cause和hotspot.gc.last_cause计数器则gc事件的原因将出现在last Cause中
4.Eden space
此面板显示Eden空间随时间的利用情况。它是年轻代的三个空间之一另外两个分别是S0、S1。空间的当前容量可以根据收集器策略动态更改即通过修改–Xmn参数会改变其大小。
标题栏第一个参数代表最大容量第二个参数代表当前容量后跟当前占用空间。此外还包含了年轻代GC事件数量和GC累计时间。
Eden Space最大可分配空间3.807G
Eden Space当前已分配空间210M
Eden Space当前占用空间162M(当积累的占用空间超过162M就会在Eden Space发生一次Minor GC)
Minor GC次数41次
Minor GC花费时间618.824ms 5.Survivor 0 and Survivor 1 HotSpot JVM把年轻代分为了三部分1个Eden区和2个Survivor区分别叫from和to默认大小比例为Eden:Survivor0:Survivor18:1:1的。
新创建的非大对象会存放在Eden区和一个作为from的Survivor区当发生一次Minor GC时就会将Eden区和作为from的Survivor区内仍存活的对象复制到另一个作为to的Survivor区然后清理掉原来Eden区和作为from的Survivor区内对象。因此S0 和 S1 之间至少有一个肯定是空闲的。
Survivor 1区最大分配容量3.807G
Survivor 1区当前已分配容量20M
Survivor 1区当前占用容量20M
6.old Gen
面板显示老年代随着时间推移的利用情况。
Old Gen 最大分配空间3.807G
Old Gen 已分配空间2.654G
Old Gen 当前占用空间1.964G
Old Gen 发生的GC次数0次
Old Gen 发生的GC花费时间0ms 7.MetaSpace元空间内容
标题栏在括号中显示空间的名称及其最大容量和当前容量后跟空间的当前占用大小
最大元空间1.062G
可用元空间 6.688M
以占用元空间 6.436M https://blog.csdn.net/qq_41158114/article/details/137642072
三 VisualGC实操分析案例
3.1 案例分析
使用visual VM工具的Visual GC插件观察到以下的图表——新生代Eden区已经发生了8168次Minor GC耗时39.754s,另外老年代也发生了24次GC耗时5.124s。可见该JVM参数设置得极不合理导致已经过于频繁发生Minor GC。(除代码问题 截图中可以看到新生代中的Eden区频繁发生Minor GC原因之一是分配的空间过小目前是204.875M导致当前占用空间经常超过204.875M进而发生GC。若要分析是哪些代码频繁创建对象还得进一步通过dump等方式进行分析这里暂时不展开。
这里采用解决思路提升分配给Eden区的大小。
通过Visual VM的监视栏中的堆监控可以观察到蓝色模块高度比较均衡地对应在纵坐标280MB的样子也就是说新创建的对象每次gc未被清除的对象 其占有的大小达到近300MB( 见下图蓝色模块 )而Eden Space 其中一个Survivor才230MB左右见上图Eden区 204.87525.562约等于230M可见每次新创建的对象很容易就超过新生代这就意味着频繁发生Minor GC是必然的从图的横坐标可以看出每30ms内就发生了2到3次的Minor GC 优化实施
为了避免Eden区频繁发生Minor GC根据堆监控图表可以考虑在设置JVM参数时适当提升分配给Eden的空间。
就暂且先设置Eden区为320MB考虑到Eden:Survivor0:Survivor18:1:1比例也就是8:2若要分配Eden320M那么可以根据8/2320/x算出来x80这里的x就是两个Survivor总大小即每个Survivor分配40MB那么年轻代总共需要分配的大小为320M40M*2400M即-Xmn400m。
再来看下老年代目前老年代发生了24次GC最大分配空间是256MB当前最小分配空间是71.48M可见还可以适当进行优化。 根据堆新生代老年代不包括永久代方法区。在新生代已经分配400MB情况下若要让老年代最大与最小分配空间都为256MB那么就需要对JVM堆分配400M256M656M的空间大小即设置-Xms656M、-Xmx656M 元空间暂且可以不考虑进行分配。
最后根据以上得出的参数进行设置然后以设置好的参数进行项目重启根据新一轮图表展示继续进行参数优化循环调试直到新生代和老年代的GC频率都保持一个比较平衡的水准。
3.2 获取堆文件的两种方式
1.设置参数在异常发生时自动生成dump文件。
-XX:HeapDumpOnOutOfMemoryError 表示当JVM发生OOM时自动生成DUMP文件。
-XX:HeapDumpPath存储文件/目录 表示生成DUMP文件的路径
2.手动生成dump分析文件
执行jmap -dump:formatb,file20210321.dump 7132其中7132是对应项目的进程PID。
将获取到的dump文件手动导入到Visual VM工具就可以分析哪些对象占用内存高了往往可以分析出哪些对象造成了内存泄露问。
