垃圾收集器
1. Serial 收集器 ★
Serial 收集器最基本、發展歷史最悠久的收集器；是一個新生代的單線程收集器（老生代版本Serial Old）。
進行垃圾收集時，必須暫停其他所有的工作線程，直到它收集結束；即“Stop The World”，實際上是由虛擬機在後臺自動發起和自動完成的，在用戶不可見的情況下把用戶正常工作的線程全部停掉，這對很多應用來說是難以接受的。
- 工作過程
- 在安全點（safepoint）暫停用戶線程；
- GC線程運行，新生代採用複製算法；老年代使用標記-整理算法收集垃圾；
- 恢復用戶線程。
2. ParNew 收集器
ParNew收集器其實就是Serial收集器的多線程版本，其控制參數、收集算法、Stop The World、對象分配規則、回收策略等都完全一樣；
區別是：在新生代的採用多線程進行復制算法回收垃圾；而老年代依然使用單線程。
3. Parallel Scavenge 收集器
Parallel Scavenge 收集器是一個新生代收集器，使用複製算法，同時又是併發的多線程收集器。
4. Serial Old 收集器
Serial Old 是Serial 收集器的老年代版本，同樣是一個單線程收集器，使用“標記-整理”算法，
5. Parallel Old 收集器
Parallel Old是Parallel Scavenge 收集器的老年代版本
6. CMS 收集器 ★
CMS（Concurrent Mark Sweep）收集器是一種以獲取最短回收停頓時間爲目標的收集器。 目前很大一部分Java應用集中在互聯網網站或者B/S系統的服務端上，這類應用尤其重視服務器的響應速度，希望系統停頓時間最短，以給用戶帶來較好的體驗。
CMS收集器基於“標記-清除”算法實現，整個過程分爲4個步驟：
- 初始標記（CMS initial mark）
僅僅標記一下GC Roots能夠直接關聯到的對象，速度很快 - 併發標記（CMS concurrent mark）
進行GC Roots Tracing的過程（可達性分析） - 重新標記（CMS remark）
爲了修正併發標記期間因爲用戶程序繼續運作而導致標記產生變動的那一部分對象的標記記錄 - 併發清除（CMS concurrent sweep）
垃圾回收，內存回收過程是與用戶線程一起併發執行的。
- 三個缺點
-
CMS收集器對CPU資源非常敏感。默認啓動的回收線程數是（CPU數量+3）/ 4。
-
CMS收集器無法處理浮動垃圾（Floating Garbage），可能出現“Concurrent Mode Failure”失敗而導致另一次Full GC的產生。由於CMS併發清理階段用戶線程還在運行着，伴隨程序運行自然就還會有新的垃圾不斷產生，這一部分垃圾出現在標記過程之後，CMS無法在本次收集中處理掉它們，只好留到下一次GC時再清理。
-
CMS是一款基於“標記-清除”算法實現的收集器，會產生內存碎片，CMS收集器提供了一個-XX：+UseCMSCompactAtFullCollection開關參數（默認是開啓的），用於在CMS收集器頂不住要進行FullGC時開啓內存碎片的合併整理過程，內存整理過程是單線程。
7. G1 收集器 ★
特點
- 並行與併發
- 分代收集
- 空間整合
- 可預測的停頓
**將Java堆劃分爲多個大小相等的獨立區域（Region），**雖然還保留有新生代和老年代的概念，但新生代和老年代不再是物理隔離，它們都是一部分Region（不需要連續）的集合。
過程：
- 初始標記（Initial mark）
僅僅標記一下GC Roots能夠直接關聯到的對象，並且修改TAMS（Next Top at Mark Start）的值，讓下一階段用戶程序併發運行時，能在正確可用的Region中創建新對象，需要停頓線程，但耗時很短。 - 併發標記（Concurrent mark）
從GC Root開始對堆中對象進行可達性分析，找出存活的對象，這階段耗時較長，但可與用戶程序併發執行。 - 最終標記（Final marking）
爲了修正併發標記期間因爲用戶程序繼續運作而導致標記產生變動的那一部分對象的標記記錄，虛擬機將這段時間對象變化記錄在線程Remembered Set Logs中，最終標記階段需要把Remembered Set Logs的數據合併到Remembered Set，這階段需要停頓線程，但是可並行執行。 - 篩選回收（Live Data Counting and Evacuation）
首先對各個Region的回收價值和成本進行排序，根據用戶所期望的GC停頓時間來制定回收計劃，這個階段也可以做到與用戶程序一起併發執行，因爲只回收一部分Region，時間是用戶可控制的，而且停頓用戶線程將大幅提高收集效率。
