一次Full GC分析

最新推荐文章于 2025-03-22 23:05:45 发布

百合静流-秋之回忆

最新推荐文章于 2025-03-22 23:05:45 发布

阅读量949

点赞数 1

分类专栏： jvm 文章标签： jvm full gc fullgc 日志分析

本文链接：https://blog.youkuaiyun.com/iverson2010112228/article/details/83012905

版权

本文通过分析一次Full GC事件，探讨了Java 8中由于Metaspace空间不足导致的Full GC问题。在Java 8中，永久代被Metaspace取代，但旧的JVM参数未更新，导致了问题的发生。通过调整MetaspaceSize和MaxMetaspaceSize参数，可以有效避免此类问题，防止频繁的Full GC。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

背景

最近开始看gc日志，感觉颇有了解。但苦于手上没有例子来练手，结果昨天下午，受到joy-merchant-service的告警，表示有full gc，虽然这个不是我负责的服务，但是好不容易逮到怎么能不管，于是晚上饭后开始查看问题。

在这里插入图片描述

解决步骤

问题表现

我发现该服务线上共四台机器，每台机器在发布的时候都会发生full gc，但是
仅限于发布的时候，而且次数不多1-3次。

历史记录

想起以前阿菜改过一次joy-merchant的full-gc的问题，然后找到大象的记录：

在这里插入图片描述

第一次假想

看到上面之前的问题后，我第一个想法是，会不会还是同样的问题，jvm参数被改了。
然后一顿操作：

whereis tomcat
tomcat: /usr/local/tomcat
cat /usr/local/tomcat/bin/catalina.sh

找到启动参数配置如下：

在这里插入图片描述
然后其他几台机器的配置都是一样的。然后我知道我们这边机器都是java8的。
这个时候如果是老司机，就已经能发现问题了。
但是我还在看参数有什么不对，继续研究。

通过配置发现，线上机器老年代用的CMS垃圾回收器
然后需要了解一下配置参数的意义：

参数	意义
-XX:SurvivorRatio=8	两个Survivor和eden的比，8表示eden：survivor1:survivor2=8:1:1
-XX:MaxTenuringThreshold=9	年龄阈值
-XX:+UseConcMarkSweepGC	设置老年代为CMS收集器
-XX:+UseCMSInitiatingOccupancyOnly	使用手动定义初始化定义开始CMS收集；不进行自动平衡
-XX:+CMSScavengeBeforeRemark	开启在CMS重新标记阶段之前的清除尝试
-XX:+ScavengeBeforeFullGC	Full GC前调用YGC
-XX:+UseCMSCompactAtFullCollection

最低0.47元/天解锁文章