1:System.gc();
2:老年代满了 没啥好说的从年轻代去往老年代的
3:JDK7或JDK6中永久区满了 得看是否还会有分配,如果没有就不会进行FGC,不过CMS GC下会看到不停地CMS GC
DUMP内存可以看到大概的情况,不仅仅是heap(这是阿里JVM团队的同学跟我讲的 应该靠谱)
4:统计得到的Minor GC晋升到旧生代的平均大小大于旧生代的剩余空间
5:堆中分配很大的对象
所谓大对象,是指需要大量连续内存空间的java对象,例如很长的数组,此种对象会直接进入老年代,而老年代虽然有很大的剩余空间,但是无法找到足够大的连续空间来分配给当前对象,此种情况就会触发JVM进行Full GC。
为了解决这个问题,CMS垃圾收集器提供了一个可配置的参数,即-XX:+UseCMSCompactAtFullCollection开关参数,用于在“享受”完Full GC服务之后额外免费赠送一个碎片整理的过程,内存整理的过程无法并发的,空间碎片问题没有了,但提顿时间不得不变长了,JVM设计者们还提供了另外一个参数 -XX:CMSFullGCsBeforeCompaction,这个参数用于设置在执行多少次不压缩的Full GC后,跟着来一次带压缩的。