垃圾回收機制GC從JDK 8到JDK 17的效能提升 - kstefanj

JDK 17 已經發布了幾個月，它不僅包含了新的語言功能。在效能提升相比老版本的JDK也確實顯著。與之前的 LTS 版本 JDK 8 和 JDK 11 相比，這一點變得尤為明顯。 效能的大部分改進來自JVM中的新功能和優化，在這篇文章中，重點將放在垃圾收集領域的改進上.

不同型別GC服務於不同的用例

決定使用哪個垃圾收集器並不總是顯而易見的。重要的是要明白，要做出正確的選擇，您首先需要弄清楚您的主要目標是什麼。通常目標是優化吞吐量、延遲和/或佔用空間。最佳解決方案當然是針對上述所有情況進行優化，並在每種情況下獲得最佳效能。收集器在各個方面都力求儘可能優化，但它們旨在進行不同的權衡以支援不同的用例。

快速總結我們在不同領域進行改進的含義：

• 吞吐量- 降低 GC 對可在設定時間內完成的事務總數的影響
• 延遲– 降低 GC 對任何單個事務的影響
• 佔用空間——降低 GC 使用的額外資源

做不同的權衡並不意味著不能從各個方面改進收集器。在改進收集器時，很大一部分是確保儘可能有效地進行權衡。另一個全面改進的好方法是重新評估舊的設計決策並提出更好的解決方案。

JDK JDK11和JDK17的吞吐量比較

檢視吞吐量指標，我們看到與舊版本相比，所有收集器都有顯著改進。ZGC是這方面改進最大的一個。G1 和 Parallel 在此設定中仍然具有更好的原始吞吐量，但擴充套件了堆，ZGC 彌補了這一差距。

當談到這個指標時，我們還應該記住，我們不僅僅是在測量 GC 效能。Java 平臺的其他部分，例如 JIT 編譯器，也有助於這些改進。

延遲

從延遲的角度來看，結果得到了更大的改善。在這裡，我們可以看到為縮短 GC 暫停時間所做的工作所帶來的所有好處。當談到這個指標時，很多改進確實可以對 GC 中的改進做出貢獻。

當考慮這個指標時，G1 顯示了最好的進展。從延遲的角度來看，ZGC 也有了很大的改進。最令人印象深刻的部分未在此圖表中看到，因為基準測試正在測量應用程式延遲。

GC暫停

ZGC 在保持短暫停頓方面做得非常好，我們開始看到影響延遲分數的其他因素。如果我們看看暫停時間是如何改進的，我們可以看到ZGC 中發生了一些非凡的工作。

當考慮這個指標時，G1 顯示了最好的進展。從延遲的角度來看，ZGC 也有了很大的改進。最令人印象深刻的部分未在此圖表中看到，因為基準測試正在測量應用程式延遲。ZGC 在保持短暫停頓方面做得非常好，我們開始看到影響延遲分數的其他因素。如果我們看看暫停時間是如何改進的，我們可以看到ZGC 中發生了一些非凡的工作。

JDK 17 中的 ZGC 遠低於其亞毫秒級暫停時間的目標。G1 的目標是在延遲和吞吐量之間保持平衡，遠低於其預設的 200 毫秒暫停時間目標。該圖表還包括一個額外的欄，用於快速顯示不同收集器如何處理可擴充套件性。ZGC 被設計為具有不隨堆大小擴充套件的暫停時間，我們清楚地看到當堆擴大到 128 GB 時就是這種情況。從暫停時間的角度來看，G1 比 Parallel 更好地處理更大的堆，因為它具有保持暫停時間目標的邏輯。

記憶體佔用

此圖表比較了三個不同收集器的峰值本機記憶體開銷。由於從這個角度來看 Parallel 和 ZGC 都非常穩定，因此在這裡檢視原始數字也更有意義。我們可以看到G1在這方面確實有所改進，其主要原因是所有功能和增強功能使記憶集管理更加高效。

即使其他收集器沒有減少他們的開銷，我們仍然應該記住，他們在其他方面有所改進，而不必使用額外的記憶體。

總結

與舊版本相比，JDK 17的整體效能要好得多，無論您使用哪種收集器。如果您仍在使用 JDK 8 並計劃升級，那麼現在可能是重新評估要使用的 GC的好時機。在 JDK 8 Parallel 是預設設定，但在 JDK 9 中更改為 G1。從那時起，G1 以比 Parallel 更高的速度改進，但仍然存在 Parallel 是最佳選擇的用例。隨著 ZGC（自 JDK 15 以來的生產就緒）的引入，還有第三種高效能替代方案可以加入等式。​​​​​​​