JVM:GC-minor gc / full gc触发条件

minor gc :
当eden区满没有足够内存给新对象分配内存,触发minor gc.
full gc:
1、调用System.gc()时,系统建议JVM执行full gc,但不必然执行。
一般不建议程序中调用System.gc(),可以通过DisableExplicitGC来禁用System.gc(),即忽略System.gc()触发的full gc 操作
2、老年代或者方法区空间不足
3、在monor gc 前,判断老年代最大可用连续空间是否大于新生代所有可用对象大小,如果不大于,则需要判断是否允许担保失败,如果不允许,直接full gc。
如果允许,在判断老年代的最大可用连续空间是否大于历次晋升到老年代对象的平均大小,如果不大于,则直接full gc.
4、由eden区和from survivor区 复制到 to survivor区的对象如果大于to区的可用空间,则直接转存至老年代,此时老年代空间不足,则full gc
5、 survivor区对象年龄达到阈值,转存老年代,老年代空间不足,full gc。
6、survivor区存在某一年龄的对象超过至少一半,则大于等于此年龄的对象,转存老年代,老年代空间不足,则触发full gc.

### 关于JVM Full GC的原因及解决方案 #### 原因分析 JVM中的Full GC是指对整个堆空间(包括年轻代和老年代)进行全面的垃圾回收操作。触发Full GC的主要因素有: - **永久代/元空间溢出**:当永久代或元空间不足以容纳新的类定义时,会触发Full GC尝试清理无用的类数据[^4]。 - **老年代空间不足**:如果应用程序产生的对象过多且存活时间较长,则可能导致老年代的空间耗尽,进而引发Full GC以释放更多可用空间- **CMS收集器失败**:在使用Concurrent Mark-Sweep (CMS) 收集器的情况下,若并发清除阶段未能及时完成,也会导致强制性的Full GC发生。 - **浮动垃圾累积**:即使经过Minor GC之后仍然存在大量短生命周期的对象未被彻底清除,在某些情况下这些残留物可能会促使更频繁地执行Full GC。 ```java // 设置初始和最大元空间大小 -XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=256m ``` 此配置可以有效防止由于元空间过早满载而引起的不必要的Full GC事件。 #### 解决方案建议 针对上述提到的各种可能引起Full GC的情况,可采取以下措施优化性能并降低Full GC的发生率: - **调整内存分配策略**:合理设置新生代与老生代理的比例关系;适当增加堆总容量,特别是对于长期运行的应用程序而言尤为重要。 - **监控与诊断工具应用**:利用诸如`jstat`, `JConsole` 或者其他专业的APM(Application Performance Management)平台持续跟踪系统的GC活动模式及其趋势变化,以便快速定位潜在瓶颈所在之处[^2]。 - **启用详细日志记录功能**:通过指定额外的JVM参数如 `-verbose:gc -Xloggc:<file-path>` 来获取更加详尽的日志信息,有助于后续深入剖析具体问题根源所在。 - **定期重启服务实例**:长时间不间断工作的Java进程容易积累各种类型的缓存项或是静态变量占用宝贵的内存资源,适时安排计划外停机维护能够显著改善整体表现水平。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值