JVMGC日志的分析与解读

255 阅读2分钟

这是我参与11月更文挑战的第11天,活动详情查看:2021最后一次更文挑战

今天,我们来分析GC日志,会分析GC日志呢,有助于我们可以判断JVM的内部运行情况,使我们更好的根据实际运行程序的情况,对JVM做出一些调整,来满足一些实际的性能需求。

本篇文章重点讲解GC日志的分支这块,我们应该看哪块,用哪些GC工具进行分析,能得出什么结论等等,算是对我们前面学习的知识的回顾,话不多说,我们一起来看下吧。

GC日志的解读 image.png

这里面是说:GC的原因是因为内存分配失败了,然后我们使用的GC算法是java8里的GC,那我们得查看一下使用的GC算法是什么,我们使用jps加jinfo进行查询。

使用jps,找到我们系统的进程ID,这里是3296

image.png 我们可以看到,使用的是并行GC。 image.png

然后我们知道并行GC是需要STW的,所以我们可以看到STW的时间是13毫秒,这13毫秒都发生了什么呢?我们可以看到young区的大小 [PSYoungGen: 262144K->43516K(305664K)]压缩了大概219M,整个young区的大小大概是305M,我们整个的这个堆内存设置的是1G:262144K->80620K(1005056K),那整个堆内存压缩之后是80M左右,那我们整个堆内存大概压缩了是182M的内存,这里面好玩的事情就发生了,压缩之前:我们的young区是262,整个堆内存也是262,压缩之后,我们的young区和堆内存的数据不一致了,那我们不🈲会产生疑问:少的数据哪去了?

其实是扛过了GC回收,从年轻代跑到了老年代:一共多少数据呢那就是219-182是37M的数据,我们可以这样想:年轻代数据减的数据比整个堆内存都多,多了多少呢,多了37M,这37M哪去了,跑到了老年代,或者我们可以这样计算:整个堆内存压缩后是80M,我们的年轻代是43M,剩下的37M就到了老年代。

然后多次GC,发生了一FullGC,然后我们看young区,本来有36M的数据,全部清空掉了,然后看Old区,[ParOldGen: 613141K->337990K(699392K)] ,减少了接近一半的数据,然后我们的元数据区就是我们的非堆,几乎没有变,然后整个Full GC是41毫秒,所以减少Full GC有助于提升程序性能。

image.png