Full GC触发总结

本文详细解析了触发FullGC的四种主要情形:旧生代空间不足、PermGen空间满、CMSGC时的promotionfailed和concurrentmodefailure,以及MinorGC晋升到旧生代的平均大小超过旧生代剩余空间。探讨了如何优化这些场景,避免不必要的FullGC,提高系统性能。

除直接调用System.gc外,触发Full GC执行的情况有如下四种:
1. 旧生代空间不足
       旧生代空间只有在新生代对象转入及创建为大对象、大数组时才会出现不足的现象,当执行Full GC后空间仍然不足,则抛出如下错误:java.lang.OutOfMemoryError: Java heap space
  为避免以上两种状况引起的FullGC,调优时应尽量做到让对象在Minor GC阶段被回收、让对象在新生代多存活一段时间及不要创建过大的对象及数组。


2. Permanet Generation空间满
        PermanetGeneration中存放的为一些class的信息等,当系统中要加载的类、反射的类和调用的方法较多时,Permanet Generation可能会被占满,在未配置为采用CMS GC的情况下会执行Full GC。如果经过Full GC仍然回收不了,那么JVM会抛出如下错误信息:
java.lang.OutOfMemoryError: PermGen space
为避免Perm Gen占满造成Full GC现象,可采用的方法为增大Perm Gen空间或转为使用CMS GC。


3. CMS GC时出现promotion failed和concurrent mode failure
       对于采用CMS进行旧生代GC的程序而言,尤其要注意GC日志中是否有promotion failed和concurrent mode failure两种状况,当这两种状况出现时可能会触发Full GC。
promotionfailed是在进行Minor GC时,survivor space放不下、对象只能放入旧生代,而此时旧生代也放不下造成的;concurrent mode failure是在执行CMS GC的过程中同时有对象要放入旧生代,而此时旧生代空间不足造成的。
应对措施为:增大survivorspace、旧生代空间或调低触发并发GC的比率,但在JDK 5.0+、6.0+的版本中有可能会由于JDK的bug29导致CMS在remark完毕后很久才触发sweeping动作。对于这种状况,可通过设置-XX:CMSMaxAbortablePrecleanTime=5(单位为ms)来避免。


4. 统计得到的Minor GC晋升到旧生代的平均大小大于旧生代的剩余空间
          这是一个较为复杂的触发情况,Hotspot为了避免由于新生代对象晋升到旧生代导致旧生代空间不足的现象,在进行Minor GC时,做了一个判断,如果之前统计所得到的Minor GC晋升到旧生代的平均大小大于旧生代的剩余空间,那么就直接触发Full GC。
       例如程序第一次触发MinorGC后,有6MB的对象晋升到旧生代,那么当下一次Minor GC发生时,首先检查旧生代的剩余空间是否大于6MB,如果小于6MB,则执行Full GC。
当新生代采用PSGC时,方式稍有不同,PS GC是在Minor GC后也会检查,例如上面的例子中第一次Minor GC后,PS GC会检查此时旧生代的剩余空间是否大于6MB,如小于,则触发对旧生代的回收。
       除了以上4种状况外,对于使用RMI来进行RPC或管理的Sun JDK应用而言,默认情况下会一小时执行一次Full GC。可通过在启动时通过- java-Dsun.rmi.dgc.client.gcInterval=3600000来设置Full GC执行的间隔时间或通过-XX:+ DisableExplicitGC来禁止RMI调用System.gc

 

 

新生代 GC(Minor GC):从年轻代空间(包括 Eden 和 Survivor 区域)回收内存被称为 Minor GC,因为 Java 对象大多都具备朝生夕灭的特性,所以 Minor GC 非常频繁,一般回收速度也比较快。

老年代 GC(Major GC / Full GC):指发生在老年代的 GC,出现了 Major GC,经常会伴随至少一次的 Minor GC(但非绝对的,ParallelScavenge 收集器的收集策略里就有直接进行 Major GC 的策略选择过程) 。MajorGC 的速度一般会比 Minor GC 慢 10倍以上。

Minor GC触发机制:
当年轻代满时就会触发Minor GC,这里的年轻代满指的是Eden代满,Survivor满不会引发GC。
Full GC触发机制:
(1)调用System.gc时,系统建议执行Full GC,但是不必然执行
(2)老年代空间不足
(3)方法区空间不足
(4)通过Minor GC后进入老年代的平均大小大于老年代的可用内存
(5)由Eden区、survivor space1(From Space)区向survivor space2(To Space)区复制时,对象大小大于To Space可用内存,则把该对象转存到老年代,且老年代的可用内存小于该对象大小

当永久代满时也会引发Full GC,会导致Class、Method元信息的卸载。

Major GC 是清理永久代。
Full GC 是清理整个堆空间—包括年轻代和永久代。

 

### Java Full GC 触发原因 Full GC的发生通常意味着整个堆内存被清理,这不仅涉及年轻代也包括老年代以及永久代(或元空间)。触发Full GC的原因多种多样: - **JVM参数配置不当**:如果初始堆大小和最大堆大小之间差异过大,可能导致频繁的垃圾收集操作。此外,当新生代与老生代的比例不合适时也会引发不必要的Full GC[^2]。 - **Metaspace溢出**:随着应用程序加载更多的类定义到JVM中,如果没有足够的Metaspace存储这些数据,则会触发Full GC尝试释放一些不再使用的类信息以腾出空间。 - **显式调用`System.gc()`**:尽管这只是向JVM发出的一个建议,但在某些实现下确实能够引起完整的垃圾回收过程。尤其是在远程方法调用(RMI)环境中,默认情况下可能会周期性地执行这样的请求,进而提高了发生Full GC的可能性[^3]。 - **对象分配速率过高**:例如存在一个Bean实例内部维护着一个列表类型的成员变量,并且该集合不断增长而未得到有效控制,最终可能因为占用过多的老年区内存而导致Full GC事件频发[^4]。 ### 解决方案 针对上述提到的各种情况,可以采取如下措施减少甚至消除不必要的Full GC现象: #### 调整JVM启动参数 合理规划Heap Size及其各部分比例对于优化性能至关重要。可以通过调整-Xms、-Xmx等选项设定合适的最小值和最大值;同时利用NewRatio参数调节Eden区与其他区域之间的平衡关系,确保有足够的空间容纳临时创建的对象而不至于过早晋升至老年区。 ```bash java -Xms512m -Xmx2g -XX:NewRatio=2 MyApplication ``` #### 避免无谓的`System.gc()` 除非绝对必要,否则应尽量避免程序里直接调用`System.gc()`函数。可通过设置命令行标志位`-XX:+DisableExplicitGC`来阻止外部因素干扰正常的垃圾回收流程。 ```bash java -XX:+DisableExplicitGC MyApplication ``` #### 控制大对象生命周期 对于那些容易膨胀的数据结构如数组、容器类等,应当注意其容量管理和及时清除已失效条目,防止它们长期驻留在内存之中成为负担。另外考虑采用弱引用(WeakReference)等方式处理缓存型资源,允许GC适时回收这部分内容。 ```java import java.lang.ref.WeakReference; ... Map<Key, WeakReference<Value>> cache = new HashMap<>(); cache.put(key, new WeakReference<>(value)); // 使用时再获取实际引用 Value actualValue = cache.get(key).get(); if (actualValue != null){ // 处理逻辑 } ```
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值