GC之7大垃圾收集器詳解
目錄
- GC之CMS收集器
- GC之SerialOld收集器
- GC之如何選擇垃圾收集器
- GC之G1收集器
第一部分請參見： GC之7大垃圾收集器詳解（上）
6. GC之CMS收集器
- CMS收集器(ConcurrentMarkSweep：并發标記清除）是一種以擷取最短回收停頓時間為目标的收集器。
- 适合應用在網際網路站或者B/S系統的伺服器上，這類應用尤其重視伺服器的響應速度，希望系統停頓時間最短。
- CMS非常适合堆記憶體大、CPU核數多的伺服器端應用，也是G1出現之前大型應用的首選收集器。
GC之7大垃圾收集器詳解（下）GC之7大垃圾收集器詳解 - Concurrent Mark Sweep 并發标記清除，并發收集低停頓，并發指的是與使用者線程一起執行
- 開啟該收集器的JVM參數：-XX:+UseConcMarkSreepGC，開啟該參數後會自動将-XX:+UseParNewGC打開
- 開啟該參數後，使用ParNew(Young區用）+CMS(Old區用）+SerialOld的收集器組合，SerialOld将作為CMS出錯的後備收集器
- CMS四步驟
- 初始标記（CMS initial mark）：隻是标記一下GC Roots能直接關聯的對象，速度很快，仍然需要暫停所有的工作線程
- 并發标記（CMS concurrent mark）和使用者線程一起：進行GC Roots跟蹤的過程，和使用者線程一起工作，不需要暫停工作線程。主要标記過程，标記全部對象
- 重新标記（CMS remark）：為了修正并發标記期間，因使用者程式繼續運作而導緻标記産生變動的那一部分對象的标記記錄，仍然需要暫停所有的工作線程。由于并發标記時，使用者線程仍然運作，是以在正式清理前，再做修正。
- 并發清除（CMS concurrent sweep）和使用者線程一起：清除GC Roots不可達對象，和使用者線程一起工作，不需要暫停工作線程。基于标記結果，直接清理對象
- 由于耗時最長的并發标記和并發清除過程中，垃圾收集線程可以和使用者一起并發工作，是以總體上來看CMS收集器的記憶體回收和使用者線程是一起并發地執行。
- CMS簡圖：
GC之7大垃圾收集器詳解（下）GC之7大垃圾收集器詳解 - CMS優點：并發收集低停頓
- CMS缺點：
-
并發執行，對cpu資源壓力大：由于并發進行，CMS在收集與應用線程會同時會增加對堆記憶體的占用，也就是說，CMS必須要在老年代堆記憶體用盡之前完成垃圾回收，否則CMS回收失敗時，将觸發擔保機制，串行老年代收集器将會以
STW的方式進行上次GC，進而造成較大停頓時間。
- 采用的标記清除算法會導緻大量碎片：标記清除算法無法整理空間碎片，老年代空間會随着應用時長被逐漸耗盡，最後将不得不通過擔保機制對堆記憶體進行壓縮。CMS也提供了參數 -XX:MSFuIIGCsBeForeCompaction (預設0，即每次都進行記憶體整理）來指定多少次CMS收集之後，進行一次壓縮的FullGC。
-
7. GC之SerialOld收集器
- SerialOld是Serial垃圾收集器老年代版本，它同樣是個單線程的收集器，使用标記-整理算法，這個收集器也主要是運作在Client預設的java虛拟機預設的年老代垃圾收集器。
- 在Server模式下，主要有兩個用途（了解，版本己經到8及以後）：
- 在JDK1.5之前版本中與新生代的Parallel Scavenge收集器搭配使用。(ParallelScavenge+SerialOld）
- 作為老年代版中使用CMS收集器的後備垃圾收集方案。
8. GC之如何選擇垃圾收集器
9. GC之G1收集器
G1收集器内容比較重要，也比較多，另開一篇：GC之G1垃圾收集器