記憶體分配與回收策略
物件的記憶體分配，基本上就是在堆上分配，物件主要分配在新生代的Eden區上。少數也可能會直接分配在老年代中。
Minor GC 和 Full GC
Minor GC 發生在新生代上，因為新生代物件存活時間很短，因此Minor GC會頻繁執行，執行的速度一般也比較快。 Full GC 發生在老年代上，老年代物件存活時間長，因此Full GCh很少執行，執行速度比Minor GC慢10倍以上。
記憶體分配策略
物件有限在Eden區分配
大多數情況下，物件在新生代 Eden 區分配，當 Eden 區空間不夠時，發起 Minor GC。
大物件直接進入老年代
大物件是指需要大量連續記憶體空間的物件（字串、陣列）。
經常出現大物件會提前觸發垃圾收集以獲取足夠的連續空間分配給大物件。
-XX:PretenureSizeThreshold，大於此值的物件直接在老年代分配，避免在 Eden 區和 Survivor 區之間的大量記憶體複製。
長期存活的物件進入老年代
為物件定義年齡計數器，物件在 Eden 出生並經過 Minor GC 依然存活，將移動到 Survivor 中，年齡為1,。此後每經過一次Minor GC，年齡就增加 1 歲，增加到一定年齡則移動到老年代中。
-XX:MaxTenuringThreshold 用來定義年齡的閾值。
動態物件年齡判定
虛擬機器並不是永遠地要求物件的年齡必須達到 MaxTenuringThreshold 才能晉升老年代，如果在 Survivor 中相同年齡所有物件大小的總和大於 Survivor 空間的一半，則年齡大於或等於該年齡的物件可以直接進入老年代，無需等到 MaxTenuringThreshold 中要求的年齡。
空間分配擔保
在發生 Minor GC 之前，虛擬機器先檢查老年代最大可用的連續空間是否大於新生代所有物件總空間，如果條件成立的話，那麼 Minor GC 可以確認是安全的。
如果不成立的話虛擬機器會檢視 HandlePromotionFailure 設定值是否允許擔保失敗，如果允許那麼就會繼續檢查老年代最大可用的連續空間是否大於歷次晉升到老年代物件的平均大小，如果大於，將嘗試著進行一次 Minor GC；如果小於，或者 HandlePromotionFailure 設定不允許冒險，那麼就要進行一次 Full GC。
新生代使用複製收集演算法，使用其中一個Survivor空間作為輪換備份，因此當出現大量物件再Minor GC後仍然存活的情況，就需要老年代進行分配擔保，把Survivor無法容納的物件直接進入老年代。但是老年代進行擔保需要有容納這些物件的剩餘空間，因此取之前的平均值與當前老年代的剩餘空間進行比較。
Full GC觸發條件
對於 Minor GC，其觸發條件非常簡單，當 Eden 空間滿時，就將觸發一次 Minor GC。
Full GC的觸發條件如下： ####呼叫 System.gc() 只是建議虛擬機器執行 Full GC，但是虛擬機器不一定真正去執行。不建議使用這種方式，而是讓虛擬機器管理記憶體。 ####老年代空間不足
老年代空間不足的常見場景為前文所講的大物件直接進入老年代、長期存活的物件進入老年代等。
為了避免以上原因引起的 Full GC，應當儘量不要建立過大的物件以及陣列。除此之外，可以通過 -Xmn 虛擬機器引數調大新生代的大小，讓物件儘量在新生代被回收掉，不進入老年代。還可以通過 -XX:MaxTenuringThreshold 調大物件進入老年代的年齡，讓物件在新生代多存活一段時間。
空間分配擔保失敗
使用複製演算法的 Minor GC 需要老年代的記憶體空間作擔保，如果擔保失敗會執行一次 Full GC。
JDK 1.7 及以前的永久代空間不足
在 JDK 1.7 及以前，HotSpot 虛擬機器中的方法區是用永久代實現的，永久代中存放的為一些 Class 的資訊、常量、靜態變數等資料。
當系統中要載入的類、反射的類和呼叫的方法較多時，永久代可能會被佔滿，在未配置為採用 CMS GC 的情況下也會執行 Full GC。如果經過 Full GC 仍然回收不了，那麼虛擬機器會丟擲 java.lang.OutOfMemoryError。
為避免以上原因引起的 Full GC，可採用的方法為增大永久代空間或轉為使用 CMS GC。
Concurrent Mode Failure
執行 CMS GC 的過程中同時有物件要放入老年代，而此時老年代空間不足（可能是 GC 過程中浮動垃圾過多導致暫時性的空間不足），便會報 Concurrent Mode Failure 錯誤，並觸發 Full GC。