OpenJDK 8具有幾種垃圾收集器算法，例如Parallel GC ， CMS和G1 。 哪一個最快？ 如果默認的GC從Java 8中的并行GC更改為Java 9中的G1（當前建議），將會發生什么？ 讓我們對其進行基準測試。

基準方法

• 使用不同的VM參數運行相同的代碼6次（ -XX:+UseSerialGC ， -XX:+UseParallelGC ， -XX:+UseConcMarkSweepGC ， -XX:ParallelCMSThreads=2 ， -XX:ParallelCMSThreads=4 ， -XX:+UseG1GC ） 。
• 每次運行大約需要55分鐘。
• 其他VM參數： -Xmx2048M -server
  OpenJDK版本： 1.8.0_51 （當前最新版本）
  軟體： Linux version 4.0.4-301.fc22.x86_64 硬件： Intel? Core? i7-4790 CPU @ 3.60GHz
• 每次運行都能使用OptaPlanner解決13個計劃問題。 每個計劃問題要運行5分鐘。 它以30秒的JVM預熱開始，該預熱將被丟棄。
• 解決計劃問題不涉及任何IO （啟動期間要加載輸入的時間只有幾毫秒）。 一個CPU完全飽和。 它會不斷創建許多短命的對象，然后GC會收集它們。
• 基準衡量每毫秒可以計算的分數數量。 越高越好。 為擬議的規劃解決方案計算分數并非易事：涉及許多計算，包括檢查每個實體與每個其他實體之間的沖突。

要在本地重現這些基準， 請從源代碼構建optaplanner并運行主類GeneralOptaPlannerBenchmarkApp 。

基準結果

執行摘要

為了方便起見，我將每種垃圾收集器類型與Java 8（并行GC）中的默認類型進行了比較。

結果很明顯： 該默認值（并行GC）是最快的。

原始基準數字

相對基準數字

Java 9是否應該默認為G1？

有建議使G1在服務器的OpenJDK9中成為默認的垃圾收集器 。 我的第一反應是拒絕這個提議 ：

• G1平均為17.60% 。
• 對于每個數據集，每個用例的G1始終較慢。
• 在最大數據集（Machine Reassignment B10）上，它使任何其他數據集的大小都34.07% ,， G1為34.07%較慢。
• 如果開發人員機器和服務器之間的默認GC不同，則開發人員基準測試的可信度將降低。

另一方面，需要注意一些細微差別：

• G1專注于限制GC暫停，而不是吞吐量。 對于這些用例（計算量很大），GC暫停長度基本上無關緊要。
• 這是（幾乎）單線程基準。 在并行或多線程求解中使用多個求解器進行進一步的基準測試可能會影響結果。
• 建議使用G1的堆大小至少為6 GB 。 該基準測試僅使用了2 GB的堆大小，甚至只有最大的數據集（Machine Reassignment B10）才需要該大小。

繁瑣的計算只是OpenJDK所使用的眾多功能之一：在整個社區辯論中，它只是利益相關者中的一員。 如果其他利益相關者（例如Web服務）證明相反，則值得更改默認GC。 但是，請先向我展示真實項目的基準 ！

結論

在Java 8中，默認的垃圾收集器（Parallel GC）通常是OptaPlanner用例的最佳選擇。

翻譯自: https://www.javacodegeeks.com/2015/08/what-is-the-fastest-garbage-collector-in-java-8.html

總結

以上是生活随笔為你收集整理的Java 8中最快的垃圾收集器是什么？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。