JVM垃圾收集器使用調查：CMS最受歡迎
近日，Plumbr 公司對特定垃圾收集器（GC）使用情況進行了一次調查研究。
本次研究的數據來自代表 2670 個不同使用環境的 84936 個案例。其中，13% 的環境已經明確指定了一個垃圾收集器，其余的根據 JVM 而定。在指定了明確垃圾收集器的 11062 個案例中，根據每個垃圾收集器使用的統計次數，研究人員做出了下面的垃圾收集器餅圖：
GC 使用統計
名詞解釋
- Serial：串行收集器，當進行垃圾收集時，會暫停所有線程
- Parallel：并行收集器，是串行收集器的多線程版本，多 CPU 下
- ParallelOld：老年代的 Parallel 版本
- ConcMarkSweep：簡稱 CMS，是并發收集器，將部分操作與用戶線程并發執行
- CMSIncrementalMode：CMS 收集器變種，屬增量式垃圾收集器，在并發標記和并發清理時交替運行垃圾收集器和用戶線程
- G1：面向服務器端應用的垃圾收集器，計劃未來替代 CMS 收集器
87% 的案例沒有指定垃圾收集器
在解釋垃圾收集器使用情況的詳情之前，我們先看下其他 87% 的案例為什么沒有出現在上面的餅圖中。從研究結果來看，有 2 個不同的原因導致了該情況的出現：
- JVM 對于默認情況的處理十分合理，開發人員無需指定垃圾收集器
- 對部分團隊來說，程序性能可能優先級不高，致使沒有指定垃圾收集器
所以，研究團隊沒有采用使用默認垃圾收集器的 JVM 案例。話又說回來，默認的垃圾收集器又是什么呢？這個問題既簡單又復雜。如果你運行在 JVM 的客戶端模式（Client）下，JVM 默認垃圾收集器是串行垃圾收集器（Serial GC，-XX:+USeSerialGC）；在 JVM 服務器模式（Server）下默認垃圾收集器是并行垃圾收集器（Parallel GC，-XX:+UseParallelGC）。至于是運行在 JVM 的客戶端模式還是服務器模式，取決于下面情況：
JVM 客戶端/服務器模式
大多數案例沒有做出最佳選擇
讓我們回到已經明確指定垃圾收集器的 13% 的案例，但僅有一小部分用戶的決策是按照上述表格中的建議進行的。據統計，只有 31 個案例根據自己的機器性能選擇了最佳的串行垃圾收集器，考慮到當前服務大多運行在多核服務器上，這個可以理解。
垃圾收集器使用類型統計
我們從上圖可以看出，并行（Parallel）和 ParallelOld 使用次數很接近。如果覺得并行模式這一新生代收集器更符合你的需求，那就選擇它。從第一張表格中我們也可以看出，并行垃圾收集器(Parallel)已經 是大多數平臺的默認選擇。從這個方面講，如果沒有指定明確的垃圾收集器，也并不意味著默認使用的垃圾收集器不流行。
說到 CMSIncrementalMode 的使用情況，只有 935 個環境使用了該種垃圾收集器，相比而言，經典的 CMS（ConcMarkSweep）則有 6655 個環境使用了它。這里提示下大家，在并發階段，垃圾收集器線程會使用一個或多個處理器。增量式垃圾收集器是通過一定的回收算法，把一個長時間的中斷，劃分 為很多個小的中斷，以減少垃圾收集器對用戶程序的影響。
研究中還有一個結果就是 G1 的采用率，有 826 個環境使用了該種垃圾收集器。但同等條件來講，G1 比 CMS 性能表現會差一些。
以上就是本次研究的結果，希望對各位有用。
<span id="shareA4" class="fl"> </span>
</div>