除直接调用System.gc外,触发Full GC执行的状况有以下四种。java
1. 旧生代空间不足es6
旧生代空间只有在新生代对象转入及建立为大对象、大数组时才会出现不足的现象,当执行Full GC后空间仍然不足,则抛出以下错误:数组
java.lang.OutOfMemoryError: Java heap space
为避免以上两种情况引发的Full GC,调优时应尽可能作到让对象在Minor GC阶段被回收、让对象在新生代多存活一段时间及不要建立过大的对象及数组。并发
2. Permanet Generation空间满app
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。this
3. CMS GC时出现promotion failed和concurrent mode failurees5
对于采用CMS进行旧生代GC的程序而言,尤为要注意GC日志中是否有promotion failed和concurrent mode failure两种情况,当这两种情况出现时可能会触发Full GC。spa
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。
Full GC示例
如下经过几个例子来演示Full GC在旧生代占满和CMS GC失败时的触发,以及不一样Full GC时的日志信息。
1. 旧生代空间不足触发的Full GC
代码以下:
public class TestFullGC{ public static void main(String[] args) throws Exception{ List<MemoryObject> objects=new ArrayList<MemoryObject>(6); for(int i=0;i<10;i++){ objects.add(new MemoryObject(1024*1024)); } // 让上面的对象尽量地转入旧生代中 System.gc(); System.gc(); Thread.sleep(2000); objects.clear(); for(int i=0;i<10;i++){ objects.add(new MemoryObject(1024*1024)); if(i%3==0){ objects.remove(0); } } Thread.sleep(5000); } } class MemoryObject{ private byte[] bytes; public MemoryObject(int objectSize){ this.bytes=new byte[objectSize]; } }
以-Xms20M -Xmx20M -Xmn10M -verbose:gc -XX:+PrintGCDetails执行以上代码,可看到在输出的日志中出现了Full GC的信息:
[Full GC [PSYoungGen: 7248K->0K(8960K)] [PSOldGen: 9330K->4210K(10240K)] 16578K-> 4210K(19200K) [PSPermGen: 1692K->1692K(16384K)], 0.0085500 secs] [Times: user=0.01 sys=0.00, real=0.01 secs]
上面日志的含义为执行了一次Full GC,新生代的方式为并行回收GC方式,回收前内存使用了7 248KB,回收后为0KB,可以使用的内存为8 960KB;旧生代的方式为并行GC方式,回收前内存使用了9 330KB,回收后为4 210KB,可以使用的内存为10 240KB;回收前JVM堆使用的内存为16 578KB,回收后为4 210KB,可以使用的内存为19 200KB;PSPermGen回收前为1 692KB,回收后仍然为1 692KB,可以使用的内存为16 384KB;回收Perm Gen消耗的时间为7ms,整个Full GC耗费的时间为10ms,经过System.gc调用的Full GC在日志上会显示为Full GC(System)。
因为执行以上代码的机器为server级机器,所以其默认采用的为-XX:+UseParallelGC,改成采用-XX:+UseSerialGC,Full GC的信息以下:
[Full GC [Tenured: 9216K->4210K(10240K), 0.0066570 secs] 16584K->4210K(19456K), [Perm : 1692K->1692K(16384K)], 0.0067070 secs] [Times: user=0.00 sys=0.00, real=0.01 secs]
上面日志的含义为执行了一次Full GC,旧生代的回收方式采用的为串行方式,回收前为9 216KB,回收后为4 210KB,旧生代可用的内存为10 240KB,回收耗时6ms,其余信息则和ParallelGC时基本相同。
2. CMS GC失败触发的Full GC
按照CMS GC concurrent mode failure失败的缘由,编写了以下代码:
public class TestCMSGC{ public static void main(String[] args) throws Exception{ List<MemoryObject> objects=new ArrayList<MemoryObject>(6); for(int i=0;i<9;i++){ objects.add(new MemoryObject(1024*1024)); } Thread.sleep(2000); objects.remove(0); objects.remove(0); objects.remove(0); for(int i=0;i<20;i++){ objects.add(new MemoryObject(1024*1024)); if(i%2==0){ objects.remove(0); } } Thread.sleep(5000); } }
以-Xms20M -Xmx20M -Xmn10M -verbose:gc -XX:+PrintGCDetails -XX:+UseConcMarkSweepGC参数执行,在输出信息中可看到相似信息:
[Full GC [CMS[CMS-concurrent-mark: 0.004/0.006 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] (concurrent mode failure): 9331K->9331K(10240K), 0.0183120 secs] 16499K->15475K(19456K), [CMS Perm : 1692K->1692K(16384K)], 0.0184020 secs] [Times: user=0.02 sys=0.00, real=0.02 secs]
因为是并发操做的,因此日志有重叠。
3. 统计获得的Minor GC晋升到旧生代的平均大小大于旧生代的剩余空间
测试代码以下:
public static void main(String[] args) throws Exception{ byte[] bytes=new byte[1024*1024*2]; byte[] bytes2=new byte[1024*1024*2]; byte[] bytes3=new byte[1024*1024*2]; System.out.println("ready to happen one minor gc,if parallel scavenge gc,then should one full gc"); byte[] bytes4=new byte[1024*1024*2]; Thread.sleep(3000); System.out.println("minor gc end"); byte[] bytes5=new byte[1024*1024*2]; byte[] bytes6=new byte[1024*1024*2]; System.out.println("minor gc again , and should direct full gc"); byte[] bytes7=new byte[1024*1024*2]; Thread.sleep(3000); }
以java -Xms20M -Xmx20M -Xmn10M -verbose:gc -XX:+PrintGCDetails-XX:+UseParallelGC执行以上代码,可看到在输出ready to happen one minor gc,if parallel scanvege gc,then should one full gc后,系统输出了一次minor gc和一次full gc的信息。当输出minor gc again,and should direct full gc时,系统执行了一次full gc,而观看这两次full gc的日志信息,会看到此时旧生代、perm均没有满:
[Full GC [PSYoungGen: 176K->0K(8960K)] [PSOldGen: 6144K->6258K(10240K)] 6320K->6258K(19200K) [PSPermGen: 1685K->1685K(16384K)], 0.0065500 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] [Full GC [PSYoungGen: 6224K->4096K(8960K)] [PSOldGen: 6258K->8306K(10240K)] 12482K->12402K(19200K) [PSPermGen: 1692K->1692K(16384K)], 0.0222810 secs] [Times: user=0.01 sys=0.01, real=0.02 secs]
结合代码以及以前介绍的触发机制,可看到在输出ready to happen one minor gc后,系统分配了一个2MB的对象,此时eden space空间不足,触发minor gc,minor gc后有6MB的对象进入了旧生代,此时旧生代剩余空间为4MB,因而执行full gc。
在输出minor gc again后,eden space空间再次不足,因而再度触发minor gc,此时minor gc发现以前统计出来的晋升到旧生代对象的平均值为6MB,并和旧生代的剩余空间进行比较,发现旧生代空间更小,因而直接执行full gc。
当将执行参数切换为java -Xms20M -Xmx20M -Xmn10M -verbose:gc -XX:+PrintGCDetails-XX:+UseSerialGC后,可看到系统前后执行了一次minor gc和一次full gc。