一、垃圾收集演算法

1. 標記-清除演算法
     首先標記出所有需要回收的對象，然後統一回收所有被標記的對象。該演算法的效率不高，而且存在記憶體碎片的問題。

2. 複製演算法
     將記憶體按容量劃分為大小相等的兩塊，每次只使用其中一塊進行記憶體分配，當這塊記憶體用完了，就將還存活的對象全部複製到另一塊記憶體，然後把使用過的記憶體空間一次清理掉。該演算法能解決標記清除演算法的效率問題。但是因為需要將記憶體分一半，代價更高。

3. 標記-整理演算法
     標記出所有需要回收的對象，讓存活的對象向一端移動，然後直接清理掉端邊界以外的記憶體。該演算法能解決標記清除演算法的記憶體碎片問題，以及複製演算法在對象存活率高時，進行多次複製的效率變低的問題。

4. 分代收集演算法
     新生代中，每次垃圾收集時都有大批對象死去，只有少量存活，此時就得使用複製演算法，這樣只要付出少量存活對象的複製成本就可以完成收集；
     老年代中，對象成活率高、沒有額外空間對他進行分配擔保，就得使用標記清理或標記整理演算法；
     分代收集演算法將堆空間劃分為年輕代yang與老年代old，年輕代又被分為Eden區和Survivor區，Survivor區又被分為From區與To區。 預設按8:1劃分Eden區和Survivor區。Eden區是連續的記憶體空間，因此在Eden區分配記憶體極快。HotSpot虛擬機使用指針碰撞和TLAB來加快Eden區的記憶體分配，並保障線程安全。
   

分代收集演算法的執行流程

1. 新建的對象優先分配在Eden區；
2. 當Eden區滿了，就會觸發Minor GC，Eden中的存活對象被移動到Survivor0，Eden被清空；
3. 等Eden區再滿了，再次觸發Minor GC，Eden和Survivor0中的存活對象又會被覆制到Survivor1，S0和Eden被清空，然後下一輪S0與S1交換角色，如此迴圈往複。
4. 當兩個Survivor區切換了幾次（HotSpot虛擬機預設15次）之後，仍然存活的對象，將被覆制到老年代。

Minor GC：發生在新生代的GC，因為Java對象都具備朝生夕滅的特性，所以Minor GC非常頻繁，一般回收速度也比較快。
Major GC/Full GC：發生在老年代年的GC，出現Full GC經常伴隨至少一次的Minor GC（非絕對，如Parallel Scavenge）。Full GC的速度一般會比Minor GC慢10倍以上，所以要合理設置年輕代與老年代的大小，儘量減少Full GC的操作。

Minor GC的觸發條件：

• 當Eden區滿時觸發。

Full GC的觸發條件：

• 調用System.gc時，系統會建議執行Full GC，但是不一定執行。
• 老年代空間不足時觸發。
• 方法區（永久代/元空間）空間不足時觸發。
• 通過Minor GC後進入老年代的平均大小大於老年代的可用連續記憶體時觸發。
• 由Eden區、From Space區向To Space區複製時，對象大小大於To Space可用記憶體，則把該對象轉存到老年代，且老年代的可用連續記憶體小於該對象大小時觸發。

二、記憶體分配和回收策略

• 對象優先在Eden區分配
    當Eden區沒有足夠的記憶體空間進行分配時，虛擬機將發起
  一次Minor GC。

• 大對象直接進入老年代
    大量連續記憶體的Java對象，比如很長的字元串以及數組，會被直接分配到老年代，因此寫程式時應該儘量避免。

• 長期存活的對象將進入老年代
    當兩個Survivor區切換了幾次（HotSpot虛擬機預設15次）之後，仍然存活的對象，將被覆制到老年代。

• 動態對象年齡判定
    如果S0空間中相同年齡所有對象大小的總和大於S0空間的一半，年齡大於或等於該年齡的對象就可以直接進入老年代，無須達到閾值。

• 空間分配擔保
    在發生Minor GC之前，虛擬機會先檢查老年代最大可用的連續空間是否大於新生代所有對象總空間，如果這個條件成立，那麼Minor GC 可以確保是安全的。如果不成立，則虛擬機會查看HandlePromotionFailure設置值是否允許擔保失敗。如果允許，那麼會繼續檢查老年代最大可用的連續空間是否大於歷次晉升到老年代對象的平均大小，如果大於，將嘗試著進行一次Minor GC，儘管這次Minor GC是有風險的；如果小於，或者HandlePromotionFailure設置不允許冒險，那這時也要改為進行一次Full GC。

三、垃圾收集器

1. Serial：單線程的收集器。==複製演算法==
2. ParNew：Serial 收集器的多線程版本。==複製演算法==
3. Parallel Scavenge：類似ParNew的收集器，其他收集器關註於儘可能縮短 Stop The World 的時間， 而Parallel 收集器更關註系統的吞吐量，支持自適應調節策略。==複製演算法==
4. Serial Old：Serial 收集器的老年代版本。==標記整理演算法==
5. Parallel Old：Parallel Scavenge 收集器的老年代版本。==標記整理演算法==
6. CMS：Concurrent Mark Sweep 收集器是一種以獲取最短回收停頓時間為目標的收集器。==標記清除演算法==

 CMS 的運作過程

• 初始標記(Initial Mark)：標記出老年代裡面存活的對象，這些對象或者是從GC roots直接指向的，或者是被年輕代存活對象指向的。會導致 STW，速度最快。

• 併發標記(Concurrent Mark)：從上個階段找到的所有根節點開始遍歷整個老年代，標記存活的對象。速度慢，但是是和程式併發執行的。

• 重新標記(Final Remark)：由於之前的併發標記是併發過程，可能無法趕上應用程式的修改速度。所以需要重新標記來完成標記整個老生代存活對象的標記。會導致 STW，速度快。
• 併發清除(Concurrent Sweep)：併發清除死亡的對象。速度慢，但是是和程式併發執行的。

 CMS 的整體流程

 CMS 的缺點

• 對CPU資源非常敏感。CMS預設回收線程數是(CPU數量+3)/4。
• 無法處理浮動垃圾，可能出現“Concurrent Mode Failure”失敗而導致另一次Full GC的產生。CMS併發清理階段用戶線程還在運行，伴隨程式運行自然有新的垃圾不斷產生，這部分垃圾出現在標記過程之後，CMS無法在當次收集中處理掉它們，只好留到下次GC再清理。這部分垃圾就是浮動垃圾。因為垃圾收集階段的用戶線程還要運行，所以CMS不像其他收集器那樣等老年代幾乎填滿了在收集，會預留一部分空間。-XX:CMSInitiatingOccupancyFraction可以設置觸發的百分比。當預留的記憶體無法滿足程式需要，就會出現出現“Concurrent Mode Failure”失敗，此時，虛擬機啟動後備方案：臨時啟用Serial Old。
• 標記-清除演算法的缺陷。易產生記憶體碎片。解決方法：通過參數配置，用於CMS在Full GC 時開啟記憶體碎片的合併整理過程，記憶體整理過程無法併發，會導致STW時間變長，因此有另一個參數配置，用於設置執行多少次不壓縮的Full GC後，執行壓縮會Full GC。

7.G1：面向服務端應用。

 G1 的特點

• 併發與並行：充分利用多CPU、多核環境的硬體優勢，縮短STW。
• 分代收集：保留分代概念，能獨立管理整個GC堆。
• 空間整理：基於“標記-整理“，局部（兩個Region）上看基於“複製”演算法。所以不會產生記憶體空間碎片。
• 可預知的停頓：這是G1相對於CMS的另一大優勢，能讓使用者明確指定一個長度為M毫秒的時間片段內，消耗在垃圾收集上的時間不得超過N毫秒。

 G1 的運作過程

• 初始標記(Initial Mark)：類似CMS
• 併發標記(Concurrent Mark)：類似CMS
• 最終標記(Remark)：類似CMS
• 篩選回收(cleanp)：在此階段將對象從一個或多個區域複製到單一區域，同時整理和釋放記憶體。

8.ZGC：JDK 11 引入的，號稱具有更低延遲的垃圾收集器，利用有色指針、載入屏障等技術，將 STW 控制在一次，只做一次掃描就能實現垃圾收集。

四、垃圾收集器的組合方式

參考資料：《深入理解Java虛擬機(第二版)》、《Java虛擬機規範(Java SE 8版)》、GC Algorithms: Implementations