垃圾收集器的各種分類

• 按線程數(shù)分類: 分為單核(串行收集器)和多核(并行收集器)

  1. 單核 CPU中適合使用串行收集器
  2. 多核 CPU中適合使用并行收集器
     兩種收集器共同點都是采用獨占式, 也就是回收時都會 STW

• 按工作模式分類: 分為獨占式(串行& 并行)垃圾收集器和并發(fā)式垃圾收集器

  1. 獨占式垃圾收集器, 一旦開始回收, 會將所有的用戶線程 STW, 直到結(jié)束
  2. 并發(fā)式垃圾收集器是收集器與應用程序線程交替工作, 以盡可能減少應用程序的停頓時間

• 按碎片處理方式分類: 分為壓縮式垃圾收集器和非壓縮式垃圾收集器

• 按內(nèi)存區(qū)間分類: 分為新年代, 老年代垃圾收集器

• 按性能指標分類:

  1. 吞吐量(throughput)是指運行用戶代碼的時間, 在 CPU的總消耗時間的比值 公式為: 吞吐量 = 運行用戶代碼的時間 / (運行用戶代碼的時間 + 垃圾回收的時間)

  * 吞吐量優(yōu)先, 一般意味著垃圾回收相對不頻繁, 所以一次回收的垃圾會更多, 因此用戶線程暫停的時間會更長, 由此導致響應時間相對慢

  * 相對于響應時間優(yōu)先的程序, 省了線程間頻繁切換的性能消耗, 所以程序的運行速度會更快

  2. 暫停時間(pause times)是指垃圾回收時用戶線程暫停的時間

  * 暫停時間優(yōu)先約等于響應時間優(yōu)先, 就是相對吞吐量優(yōu)先的程序垃圾回收更頻繁
* 每次垃圾回收時間比較短, 所以程序暫停的時間短, 因此用戶交互響應快

  3. 內(nèi)存占用: 堆中所占的內(nèi)存大小

  * 值得注意的是大的內(nèi)存空間, 也會導致暫停時間加長, 因為觸發(fā)回收的條件會更寬松或面積大了需要掃描垃圾的范圍更廣

7款經(jīng)典收集器

image.png

組合關(guān)系

image.png

* 注: 當老年代配了CMS收集器時, 如果內(nèi)存使用率超過了一定的比例, 系統(tǒng)會拋出 Concurrent Mode Failure, 此時會自動采用Serial Old收集器做Full GC

1. 紅色虛線在 Jdk8時, 將Serial與 CMS的組合和ParNew與 Serial Old的組合聲明為廢棄, 并在 Jdk9時完全棄用了
2. 黃色虛線在 Jdk14時, 棄用了 Parallel Scavenge與 Serial Old的組合
3. 綠色虛線在 Jdk14時, 完全棄用了 CMS垃圾收集器

近期垃圾收集器發(fā)展過程

• Jdk1.7u4開始全面支持 G1垃圾收集器
• Jdk9時 G1成為了, 默認的垃圾收集器, 替代了 CMS. (CMS聲明為廢棄)
• Jdk10時 G1垃圾收集器, 實現(xiàn)了并行性來改善了最壞情況下的延遲
• Jdk11時引入了 Epsilon垃圾收集器, 又稱為 No-Op(無操作)收集器. 同時, 引入了 ZGC(The Z Garbage Collector), Oracle公司的可伸縮的低延遲垃圾收集器
• Jdk12時增強了 G1垃圾收集器, 自動返回未用的堆內(nèi)存給操作系統(tǒng). 同時, OpenJDK引入了 紅帽公司開發(fā)的 Shenandoah GC低延遲垃圾收集器(試驗性階段)
• Jdk13時增強了 ZGC, 自動返回未用堆內(nèi)存給操作系統(tǒng)
• Jdk14時完全棄用了 CMS垃圾收集器(如果顯式設(shè)置會提示警告, 但不會中斷. 而會自動選擇默認收集器就是 G1). 擴展了 ZGC在 MacOS和 Windows上的應用