作者 |?Stefan Johansson

譯者 | 彎月

出品 | CSDN（ID：CSDNnews）

JDK17 發(fā)布已經(jīng)幾個(gè)月了，其中不僅包含很多新語言功能，而且與舊版 JDK 相比，性能提升也非常明顯。與之前 LTS 版本的 JDK 8 和 JDK 11 相比，JDK17 的性能提升尤為明顯。此次性能的提升大部分來自 JVM 的新功能和優(yōu)化，在本文中我們就來重點(diǎn)談一談垃圾收集的改進(jìn)。

最近，我發(fā)表過一個(gè)演講，重點(diǎn)介紹了自 JDK 8 以來 G1 中的新特性，本文將在此基礎(chǔ)之上進(jìn)一步擴(kuò)展，以涵蓋 Parallel GC 和 ZGC取得的進(jìn)步。此外，我們還有第四個(gè)受支持的收集器：Serial GC，但沒有包含在此次的比較之內(nèi)。Serial 是一個(gè)穩(wěn)定的收集器，開銷很低，但本文涉及的基準(zhǔn)測(cè)試需要高性能的 GC 才能正常工作。

服務(wù)于不同的目標(biāo)

?

有時(shí)，選擇使用哪個(gè)垃圾收集器并非一目了然。重要的是需要明白，為了做出正確的選擇，首先你需要搞清楚你的主要目標(biāo)是什么。常見的目標(biāo)包括優(yōu)化吞吐量、延遲和/或資源占用情況。最佳解決方案當(dāng)然是針對(duì)上述所有目標(biāo)進(jìn)行優(yōu)化，并在每種情況下獲得最佳性能。收集器力求從各個(gè)方面進(jìn)行優(yōu)化，但它們必須根據(jù)不同的目標(biāo)做出不同的權(quán)衡。

下面，快速介紹一下不同優(yōu)化的含義：

• 吞吐量：降低 GC 對(duì)可在指定時(shí)間內(nèi)完成的事務(wù)總數(shù)的影響。
• 延遲：降低 GC 對(duì)單個(gè)事務(wù)的影響。
• 資源占用情況：降低GC 使用的額外資源。

不同的權(quán)衡并不意味著無法從所有方面優(yōu)化收集器。在優(yōu)化收集器時(shí)，很大一部分工作是確保盡可能有效地進(jìn)行權(quán)衡。還有一種全面改進(jìn)的好方法是，重新評(píng)估舊的設(shè)計(jì)決策，并提出更好的解決方案。

自 JDK 8 以來的進(jìn)步

?

自 JDK 8 以來取得的進(jìn)步，我們能夠看到所有收集器在各個(gè)方面都有或多或少的改進(jìn)。為了更好地展示 GC 的進(jìn)步，下面的比較將使用標(biāo)準(zhǔn)化分?jǐn)?shù)來比較各個(gè)收集器。在此次比較中，我使用了SPECjbb? 20151，堆大小設(shè)置為16GB。這是一個(gè)眾所周知且非常穩(wěn)定的基準(zhǔn)測(cè)試，它的關(guān)注點(diǎn)不僅限于 GC 的性能，因此結(jié)果可以展示出整個(gè) Java 平臺(tái)的進(jìn)步。這個(gè)基準(zhǔn)測(cè)試有幾種不同的模式，可以同時(shí)生成吞吐量指標(biāo)和延遲指標(biāo)。延遲指標(biāo)是衡量響應(yīng)時(shí)間限制下的吞吐量。

對(duì)于暫停時(shí)間比較，我在固定負(fù)載下運(yùn)行了一個(gè)小時(shí)的基準(zhǔn)測(cè)試。也就是說，所有收集器都承擔(dān)了相同級(jí)別的負(fù)載。

最后請(qǐng)注意， ZGC 是 JDK 11（從 JDK15 正式投入使用）中引入的，因此我們只有兩個(gè) ZGC 數(shù)據(jù)點(diǎn)，而 G1 和 Parallel 有三個(gè)數(shù)據(jù)點(diǎn)。

吞吐量

通過以上吞吐量指標(biāo)，我們可以看到與舊版本相比，所有收集器都有了明顯的進(jìn)步，其中 ZGC 的提升最大。在此次測(cè)試中，G1 和 Parallel 的原始吞吐量更好，但增大了堆空間后，ZGC 彌補(bǔ)了這一差距。

當(dāng)談到這個(gè)指標(biāo)時(shí)，我們應(yīng)該注意，我們測(cè)量的不僅僅是 GC 的性能。Java 平臺(tái)的其他部分，例如 JIT 編譯器，對(duì)這些提升也有一定的幫助。

延遲

延遲的提升效果更明顯。我們可以看到為縮短 GC 暫停時(shí)間所做的努力都得到了回報(bào)。當(dāng)談到這個(gè)指標(biāo)時(shí)，我們應(yīng)該明白實(shí)際上很多提升都是因?yàn)?GC 的改進(jìn)。

對(duì)于這個(gè)指標(biāo)，G1 的進(jìn)步最大。從延遲的角度來看，ZGC 也有了很大的改進(jìn)。該圖中并沒有展示出提升最大的部分，因?yàn)樵摶鶞?zhǔn)測(cè)試測(cè)量的是應(yīng)用程序的延遲。ZGC 能夠?qū)和r(shí)間降到最低，我們看到其他因素也影響到了延遲的測(cè)試結(jié)果。如果我們深入研究暫停時(shí)間的改進(jìn)，就會(huì)發(fā)現(xiàn) ZGC 發(fā)揮了重要的作用。

我們來看看原始數(shù)據(jù)（因?yàn)闃?biāo)準(zhǔn)化的暫停時(shí)間有點(diǎn)奇怪），我們可以看到JDK 17 中的 ZGC 遠(yuǎn)低于目標(biāo)：亞毫秒級(jí)的暫停時(shí)間。G1 的目標(biāo)是在延遲和吞吐量之間保持平衡，遠(yuǎn)低于其默認(rèn)的目標(biāo)：200 毫秒的暫停時(shí)間。該圖表還包括額外的一欄，用于快速顯示不同收集器如何處理可擴(kuò)展性。ZGC 的設(shè)計(jì)會(huì)保證暫停時(shí)間不隨堆的大小而改變，我們可以清楚地看到當(dāng)堆擴(kuò)大到 128GB 時(shí)的情況。從暫停時(shí)間的角度來看，G1比Parallel 更善于處理更大的堆，因?yàn)樗軌虮ＷC暫停時(shí)間滿足特定目標(biāo)。

資源占用

該圖比較了三個(gè)不同收集器原生內(nèi)存的使用峰值。由于從這個(gè)角度來看 Parallel 和 ZGC 都非常穩(wěn)定，因此我們應(yīng)該看一看原始數(shù)字。我們可以看到 G1 在這方面確實(shí)有所改進(jìn)，主要原因是所有功能和增強(qiáng)功能都提高了記憶集管理的效率 。

即使其他收集器的開銷并沒有減少，但我們?nèi)匀粦?yīng)該記住，它們?cè)谄渌矫嬗幸灿兴倪M(jìn)，因此不必使用額外的內(nèi)存。

升級(jí)

?

無論使用哪種收集器，與舊版本相比，JDK 17 的整體性能都有很大的提升。如果你正仍在使用 JDK 8 并計(jì)劃升級(jí)，那么現(xiàn)在就可以重新評(píng)估打算使用的 GC。在 JDK 8 中，Parallel是默認(rèn)設(shè)置，但在 JDK 9 中改為了 G1。從那以后，G1 的改進(jìn)速度就超過了 Parallel，但在有些情況下可能 Parallel 仍然是最佳選擇。而 ZGC（從 JDK 15 開始正式使用）的加入，成為了第三種高性能替代方案。

參考鏈接：

https://kstefanj.github.io/2021/11/24/gc-progress-8-17.html