Java8最快的垃圾搜集器是哪個

這篇文章主要介紹“Java8最快的垃圾搜集器是哪個”，在日常操作中，相信很多人在Java8最快的垃圾搜集器是哪個問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”Java8最快的垃圾搜集器是哪個”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

OpenJDK 8 有多種 GC（Garbage Collector）算法，如 Parallel GC、CMS 和  G1。哪一個才是最快的呢？如果在 Java 9 中將 Java 8 默認的 GC 從 Parallel GC 改為 G1  （目前只是建議）將會怎么樣呢？讓我們對此進行基準測試。

基準測試方法

運行相同的代碼六次，每次使用不同的VM參數（-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

每次運行13個?OptaPlanner?規劃問題方案。每次運行時間為5分鐘。前30秒用于JVM預熱，不計算在內。

解決規劃問題不涉及 IO （除了啟動時需要幾毫秒來加載輸入信息）。單個 CPU 使用完全飽和。通常會創建許多存活時間很短的對象，GC 之后就會回收這些對象。

衡量標準可以是計算每毫秒的得分，越高越好。計算一個擬議規劃解決方案是一個不可小覷的問題：涉及到大量的計算，包括每個實體與其他所有實體的沖突檢測。

為了能在本地重復運行這些基準測試，可以從源碼進行構建，然后運行主類 GeneralOptaPlannerBenchmarkApp。

基準測試結果

執行結果

為了方便查看，我已經對每種 GC 與 Java 8 默認 GC（Parallel GC）進行了比較。

結果非常清楚：默認（Parallel GC）是最快的。

原始基準測試數據

相對基準測試數據

Java 9 默認應該為 G1 嗎？

有一種提議是在 OpenJDK9 的服務器端使用 G1 作為默認 GC。我***反應就是拒絕該提議：

G1 的平均值要慢17.60%

G1 在每個數據集用例下都比較慢。

在***數據集（Machine Reassignment B10）下，表現比其它數據集都要差，G1 慢了34.07%。

如果在開發機和服務器之間采用不同的默認 GC，則開發者基準測試的可信度就會下降。

另一方面，存在幾個需要注意的細節：

G1 關注是 GC 暫停的問題，而不是吞吐量。對于這些用例（計算量比較大），GC 暫停時長基本沒影響。

這是一個（基本是）單線程的基準測試。并行解決多個問題或采用多線程解決的基準測試，結果可能不同。

G1 推薦的堆內存至少是 6GB。而這次基準測試的堆內存是 2GB，即使在***數據集（Machine Reassignment B10）也只需要這么多內存。

海量計算只是 OpenJDK 的諸多功能中的一個：這是在社區廣泛爭論的一個問題。如果有其他方面（如網站服務）的證明，可能值得改變默認GC。但是，請首先向我展示你實際項目的基準測試。

到此，關于“Java8最快的垃圾搜集器是哪個”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！