fullGC CMS退化为serialGC cmsGC循环发生

Full GC触发条件

(1)System.gc()方法的调用
该方法不一定执行,但是执行的时候是fullgc。

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

(3)方法区空间不足
在HotSpot虚拟机中又被习惯称为永生代或者永生区,Permanet Generation中存放的为一些class的信息、常量、静态变量等数据,当系统中要加载的类、反射的类和调用的方法较多时,Permanet Generation可能会被占满,在未配置为采用CMS GC的情况下也会执行Full GC。如果经过Full GC仍然回收不了,那么JVM会抛出如下错误信息:java.lang.OutOfMemoryError: PermGen space
为避免Perm Gen占满造成Full GC现象,可采用的方法为增大Perm Gen空间或转为使用CMS GC。

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

(5)Minor GC晋升到老年代的平均大小大于老年代的剩余空间
Hotspot为了避免由于新生代对象晋升到旧生代导致旧生代空间不足的现象,在进行Minor GC时,做了一个判断,如果之前统计所得到的Minor GC晋升到旧生代的平均大小大于旧生代的剩余空间,那么就直接触发Full GC。
例如程序第一次触发Minor GC后,有6MB的对象晋升到旧生代,那么当下一次Minor GC发生时,首先检查老年代的剩余空间是否大于6MB,如果小于6MB,则执行Full GC。
当新生代采用PS GC时,方式稍有不同,PS GC是在Minor GC后也会检查,例如上面的例子中第一次Minor GC后,PS GC会检查此时旧生代的剩余空间是否大于6MB,如小于,则触发对旧生代的回收。

(6)堆中分配很大的对象
所谓大对象,是指需要大量连续内存空间的java对象,例如很长的数组,此种对象会直接进入老年代,而老年代虽然有很大的剩余空间,但是无法找到足够大的连续空间来分配给当前对象,此种情况就会触发JVM进行Full GC。
为了解决这个问题,CMS垃圾收集器提供了一个可配置的参数,即-XX:+UseCMSCompactAtFullCollection开关参数,用于在“享受”完Full GC服务之后额外免费赠送一个碎片整理的过程,内存整理的过程无法并发的,空间碎片问题没有了,但提顿时间不得不变长了,JVM设计者们还提供了另外一个参数 -XX:CMSFullGCsBeforeCompaction,这个参数用于设置在执行多少次不压缩的Full GC后,跟着来一次带压缩的。

7)未指定老年代和新生代大小,堆伸缩时会产生fullgc

8)直接内存的GC

Cms退化为serial gc的情况

1) promotion failed不会导致fullGC中的CMS退化为serialGC
因为promotion fail后,youngGC就被停止了,开始fullGC。
2)发生concurrent mode failure会引起Full GC,这种情况下会使用Serial Old收集器,是单线程的,对GC的影响很大。concurrent mode failure产生的原因是老年代剩余的空间不够,导致了和gc线程并发执行的用户线程创建的大对象(由PretenureSizeThreshold控制新生代直接晋升老年代的对象size阀值)不能进入到老年代,只要stop the world来暂停用户线程,执行GC清理,单线程对全堆以及 metaspace 进行回收,STW 的时间会特别长,对业务系统的可用性影响比较大。可以通过设置CMSInitiatingOccupancyFraction预留合适的CMS执行时剩余的空间。

参考:https://blog.csdn.net/peter7_zhang/article/details/107011297
https://www.cnblogs.com/zuoxiaolong/p/jvm8.html 

cmsGC循环发生的场景与解决

配置了 -XX:CMSScavengeBeforeRemark 
CMS GC只会回收OldGen的对象,那为什么需要这个参数?
由于YoungGen存在引用OldGen对象的情况,因此 CMS-remark 阶段会将 YoungGen 作为 OldGen 的 “GC ROOTS” 进行扫描,防止回收了不该回收的对象。而配置 -XX:+CMSScavengeBeforeRemark 参数,在 CMS GC 的 CMS-remark 阶段开始前先进行一次 Young GC,有利于减少 Young Gen 对 Old Gen 的无效引用,降低 CMS-remark 阶段的时间开销。


 OldGen 对象占用OldGen约80%的空间,CMSgc先youngGC,因为老生代几乎满了,且存在很多磁盘碎片,导致了youngGC的AllocationFailure(日志中Young GC 后 eden、from、to 三个 space 的使用量都不是 0 使用的情况) 

 youngGC的AllocationFailure,即YoungGC后edenfromto三个space的使用量都不是0会导致:
 1)CMS background collector(默认2s一次),同时会导致Ygc
 2)YoungGC 遇到 to space 不为空的情况下,直接 set_incremental_collection_failed() 完就返回了,并没有进行真正的 Young GC。

解决
1)去掉 -XX:CMSScavengeBeforeRemark 参数 或
2)降低 YoungGen 大小,避免因Allocation Failure而触发非正常Young GC

链接:https://www.jianshu.com/p/86fb0c335d1f


CMS发生fullGC原因
https://blog.csdn.net/peter7_zhang/article/details/107011297
 

你可能感兴趣的:(jvm,jvm)