【开发篇】十二、GCeasy报告分析

r囧r小猫 2024-04-23 15:48 57阅读 0赞

文章目录

  • 1、图一：正常情况
  • 2、图二：缓存对象过多
  • 3、图三：内存泄漏
  • 4、图四：频繁持续Full GC
  • 5、图五：元空间不足导致的Full GC

1、图一：正常情况

正常的堆内存如图：

  • 锯齿状
  • 对象创建后内存占用上升，Full GC后下降到和之前接近的位置

在这里插入图片描述

2、图二：缓存对象过多

特点：

  • 锯齿状
  • 对象创建后内存占用上升，Full GC后下降到和之前接近的位置
  • 但每次下降后的位置，其值也较大

这说明程序中保存了大量的缓存对象，GC后无法回收。比如程序中一些缓存用的Map，类似Map —> Redis —> MySQL的递进关系，这种不算内存泄漏，因为它有在发挥作用。这种缓存多了也不尽都是好处，可用MAT找到缓存了哪些对象。

在这里插入图片描述

3、图三：内存泄漏

  • 锯齿状
  • 每次垃圾回收之后下降到的内存位置越来越高

在这里插入图片描述

4、图四：频繁持续Full GC

如此频繁Full GC，给用户的感觉就是系统变卡了、变慢了，这是因为吞吐降低了（大量的时间用在了Full GC上，而不是用在了处理用户请求上）

在这里插入图片描述

大量的对象在内存中创建，同时JVM不停的Full GC在释放内存，可以看到内存有一定的下降（如下图中我黄色圈圈起来的白色三角），但很快就被新创建的对象又占满了

【相关的GcEasy报告】

从对象数据中也可以得到验证：每秒能产生198.76M大小的对象，晋升到老年代的也有65.85M数据，可见对象创建的确实很快

在这里插入图片描述

再看下面引起GC的原因，前两个是：

  • Ergonomics：垃圾回收器会根据自己的需要，比如保持一个较高的吞吐量或者比较短的STW，而触发的GC
  • Allocation Failure：对象在分配到年轻代或者老年代的时候，空间不足了，导致了GC。此原因引起的GC占了45次。

在这里插入图片描述

⇒ 对象产生速度过快，而堆空间较小，导致了频繁的Full GC，进而影响到了客户请求的响应时间

5、图五：元空间不足导致的Full GC

特点：堆内存处于比较低的状态，但却频繁发生Full GC

在这里插入图片描述

【相关的GcEasy报告】

相关报告分析：

在这里插入图片描述

再看GC原因：将近5000次是因为元空间的大小达到了阈值（Metadata GC Threshold）

在这里插入图片描述

但发现这里JVM给元空间分配了1.2G，占用了652M，似乎没有到元空间阈值，这是JVM会动态的去计算元空间的阈值，只要元空间大小超过了这个阈值，就会触发Full GC，而这里的652可能已经多次超过了这个动态阈值

在这里插入图片描述

发表评论

表情：
评论列表 （有 0 条评论，57人围观）

还没有评论，来说两句吧...

相关阅读