触发Full GC执行的状况

 除直接调用System.gc外，触发Full GC执行的状况有以下四种。

1. 旧生代空间不足

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

java.lang.OutOfMemoryError: Java heap space 

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

2. Permanent Generation空间满

Permanent Generation中存放的为一些class的信息等，当系统中要加载的类、反射的类和调用的方法较多时，Permanent 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。

promotion failed是在进行Minor GC时，survivor space放不下、对象只能放入旧生代，而此时旧生代也放不下形成的；concurrent mode failure是在执行CMS GC的过程当中同时有对象要放入旧生代，而此时旧生代空间不足形成的。

应对措施为：增大survivor space、旧生代空间或调低触发并发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。

例如程序第一次触发Minor GC后，有6MB的对象晋升到旧生代，那么当下一次Minor GC发生时，首先检查旧生代的剩余空间是否大于6MB，若是小于6MB，则执行Full GC。

当新生代采用PS GC时，方式稍有不一样，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。

 

 

*对象分配规则

1.对象优先分配在Eden区，若是Eden区没有足够的空间时，虚拟机执行一次Minor GC。

2.大对象直接进入老年代（大对象是指须要大量连续内存空间的对象）。这样作的目的是避免在Eden区和两个Survivor区之间发生大量的内存拷贝（新生代采用复制算法收集内存）。

3.长期存活的对象进入老年代。虚拟机为每一个对象定义了一个年龄计数器，若是对象通过了1次Minor GC那么对象会进入Survivor区，以后每通过一次Minor GC那么对象的年龄加1，直到达到阀值对象进入老年区。

4.动态判断对象的年龄。若是Survivor区中相同年龄的全部对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象能够直接进入老年代。

5.空间分配担保。每次进行Minor GC时，JVM会计算Survivor区移至老年区的对象的平均大小，若是这个值大于老年区的剩余值大小则进行一次Full GC，若是小于检查HandlePromotionFailure设置，若是true则只进行Monitor GC,若是false则进行Full GC。