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
