jvm垃圾收集器
阿新 • • 發佈：2020-09-02
對於Java程式，優化的重點集中在記憶體分配和GC策略調整上。JVM垃圾回收會不同程度的導致程式中斷。
JVM垃圾回收效能主要有兩個度量指標：
- 吞吐量：工作時間（不包含GC時間）佔總時間的百分比。工作時間包括 執行時間+記憶體分配時間
- 暫停：測試時間內，有垃圾回收導致的程式停止響應次數。
- FootPrint決定擴充套件性。分散式系統中，Promptness及時性（物件死亡到記憶體被釋放的時間）需要重點考慮
垃圾收集器
官方的JVM（Oracle/SUN釋出的）主要有一下三種垃圾收集器
序列收集器（Serial Collector）
採用單執行緒執行所有的垃圾回收工作，適用於單核的伺服器或者多核伺服器上資料集小於100MB的應用
並行收集器（Parallel Collector）
吞吐量收集器，以並行方式執行Monitor回收（年輕代垃圾回收），可以顯著降低垃圾回收的開銷。適用於多處理器或多執行緒硬體上執行中型或大型應用。通過並行壓縮的特性，可以使並行收集器以並行的方式執行Major回收（整個堆的垃圾回收），如果不啟用並行壓縮，Major回收將使用單執行緒執行，會降低擴充套件性
併發收集器（Concurrent Collector）
併發的方式執行大部分垃圾回收，縮短垃圾回收的暫停時間。適用於響應時間優先於吞吐量的應用。該收集器雖然最小化暫停時間，但是會降低應用效能
JDK 8中新增加的併發收集器
CMS收集器（Concurrent Mark Sweep Collector，併發標記收集器）
適用於縮短垃圾回收暫停時間並且負擔得起與垃圾回收共享處理器資源的應用
G1收集器（Garbage-First Garbage Collector）
適用於大容量記憶體的多核伺服器
總結
如果應用程式的資料集小於100MB，選擇序列收集器
如果應用運行於單核系統並沒有暫停時間的要求，可以由JVM自行選擇收集器或者使用序列收集器
如果優先考慮應用程式峰值效能，沒有暫停時間要求或者可以接受1秒甚至更長時間的暫停，可以由JVM自行選擇或者選擇並行收集器
如果應用程式響應時間比整體吞吐量重要，垃圾回收暫停時間必須小於1秒，可以用併發收集器