Java 垃圾優先 (G1) 垃圾收集器的相對性能？

Question

有誰知道 Java 的新垃圾優先 (G1) 垃圾收集器的任何性能基准測試（與“舊”GC 相比）？

在 GC 暫停時間方面，Sun 表示 G1 有時比 CMS 好有時差。 雖然 G1 收集器成功地限制了總暫停時間，但它仍然只是一個軟實時收集器。 換句話說，它不能保證它不會一直影響應用程序線程滿足其最后期限的能力。 但是，它可以在一組明確定義的范圍內運行，這使其成為需要保持高吞吐量性能的軟實時系統的理想選擇。

我想看看 Java 的 CMS（並發標記掃描）和 G1（垃圾優先）收集器的吞吐量和延遲的實際度量。

• 多布博士 | G1：Java 的 Garbage First 垃圾收集器
• InfoQ | Sun 的垃圾優先收集器在很大程度上消除了低延遲/高吞吐量的折衷
• Java HotSpot 垃圾收集 | 垃圾優先垃圾收集器

Answer 1

原始科學文章（Detlefs、Flood、Heller 和 Printezis 撰寫的“垃圾優先垃圾收集” ）包含有關實際措施的一些詳細信息（在第 4 節中）。

Answer 2

更新：見下文

如果您有一個 Web 應用程序，或另一個處理大量客戶端/請求的應用程序，並且響應時間對您很重要，那么您最好使用 CMS。 此測試在“Java 性能和可擴展性”中找到

更新：2019 年 11 月 18 日

這里比較了每個垃圾收集器的暫停。 它是 2019 年，我認為 WebApp 的最佳選擇仍然是 CMS，直到您可以直接切換到 ShenandoahGC（跳過 G1）

鏈接 : ShenandoahGC Main

重要的是要了解 GC 暫停可能不是常規應用程序中響應時間的唯一重要因素。 有很大的 GC 暫停很可能會導致響應時間問題，但沒有長時間的 GC 暫停並不總是意味着響應時間不錯。 排隊延遲、網絡延遲、其他服務延遲、操作系統調度程序抖動等可能是造成成本的原因。 建議使用響應時間測量運行 Shenandoah 以全面了解系統中正在發生的事情，然后可以將其用於與 GC 暫停時間統計信息相關聯。

例如，這是一個關於其中一個工作負載的 jHiccup 示例報告：

Answer 3

我們剛剛使用類似的人體工程學完成了對 CMS 和 G1 的一系列測試。 這是特定於產品且非常主觀的，並且我們使用的是 Java 6（因此 G1 處於“預覽”版本中）但是......

使用 CMS 的系統比 G1 快 20%。 這是用 8GB 和 12GB 堆空間以及 1GB 和 1.5GB 年輕空間（分別）測試的。

同樣 - 主觀的、單一的系統、特定的負載 - 但這是我們的經驗。

Answer 4

這篇Taranfx 文章(2009-08-29) 在 4 個簡單的基准測試中比較了 Java 5、6 和 7 的性能。

Answer 5

由於多線程的想法，G1 比 CMS 更快。 與我不知道的 Parallel-GC 相比 - 它可能是相同的。 當然 G1 更實時，因為沒有兩種線程在運行（主要是小線程）。 它更快，因為任何線程都應該對性能產生相同的影響。 甚至壓縮也只在復制時完成。 有關更多詳細信息，請仔細查看： http : //geekroom.de/java/java-expertise-g1-fur-java-7/