解决fullgc_CMS发生FullGc分析

fullgc的原因

Full GC触发条件：

(1)System.gc()方法的调用

该方法不一定执行，但是执行的时候是fullgc。

(2)老年代空间不足

老年代空间只有在新生代对象转入及创建为大对象、大数组时才会出现不足的现象，当执行Full GC后空间仍然不足，则抛出如下错误：

java.lang.OutOfMemoryError: Java heap space

为避免以上两种状况引起的Full GC，调优时应尽量做到让对象在Minor GC阶段被回收、让对象在新生代多存活一段时间及不要创建过大的对象及数组。

(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是在

执行CMS GC的过程中同时有对象要放入老年代，而此时老年代空间不足造成的(有时候“空间不足”是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后,跟着来一次带压缩的。

补充2种fullgc情况

1.未指定老年代和新生代大小，堆伸缩时会产生fullgc。

2.直接内存

Cms退化为serial gc的情况

Minor GC后存活的对象晋升到老年代时由于悲观策略的原因，有两种情况会触发Full GC,：

1.之前每次晋升的对象的平均大小 > 老年代剩余空间;

2.Minor GC后存活的对象超过了老年代剩余空间。

这两种情况都是因为老年代会为新生代对象的晋升提供担保，而每次晋升的对象的大小是无法预测的，所以只能基于统计，1个是基于历史平均水平，一个是基于下一次可能要晋升的最大水平。这两种情况都是属于promotion failure。

CMS失败，发生concurrent mode failure会引起Full GC，这种情况下会使用Serial Old收集器，是单线程的，对GC的影响很大。concurrent mode failure产生的原因是老年代剩余的空间不够，导致了和gc线程并发执行的用户线程创建的大对象(由PretenureSizeThreshold控制新生代直接晋升老年代的对象size阀值)不能进入到老年代，只要stop the world来暂停用户线程，执行GC清理。可以通过设置CMSInitiatingOccupancyFraction预留合适的CMS执行时剩余的空间。

新生代直接晋升到老年代的大对象超过了老年代的剩余空间，引发Full GC。

注意于promotion failure的区别，promotion failure指的是Minor GC后发生的担保失败。

Perm区回收

Perm永久代空间不足会触发Full GC，可以让CMS清理永久代的空间。设置CMSClassUnloadingEnabled即可。

System.gc()引起的Full GC，可以设置DisableExplicitGC来禁止调用System.gc引发Full GC 。

使用CMS(ConcMarkSweep)策略时，必须有：-XX:+CMSPermGenSweepingEnabled 和-XX:+CMSClassUnloadingEnabled
来配合同时启用，才可以对PermGen进行GC(实际主要参数为：-XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled)。

调优方案

(1)观察gc情况，结合代码，调整线程数，可以减少fullgc次数，但是计算时间消耗很大。

(2)由于这种频繁的fullgc只是在早上汇总时候产生，并且正常每天一次，所以解决方案是更换gc，将由一台机器进行汇总，其他机器不影响。

jvm的gc相关参数：

-Xmx4096m -Xms4096m

-XX:MetaspaceSize=256m

-XX:MaxMetaspaceSize=512m

-XX:SurvivorRatio=8

-XX:ParallelCMSThreads=8

-XX:+CMSParallelRemarkEnabled 开启降低标记停顿

-XX:+ExplicitGCInvokesConcurrent

-XX:+CMSPermGenSweepingEnabled

-XX:+CMSClassUnloadingEnabled

-XX:+PrintGCCause

-XX:+PrintGCDetails

-XX:+PrintHeapAtGC

-XX:+PrintTenuringDistribution

-XX:+UseConcMarkSweepGC

-XX:+PrintGCTimeStamps

-XX:+PrintGCDateStamps

-XX:CMSFullGCsBeforeCompaction=0

-XX:+UseCMSCompactAtFullCollection

-XX:CMSInitiatingOccupancyFraction=80