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后,跟着來一次帶壓縮的。