自 JDK 8 以來，Java 的垃圾收集 (GC) 經(jīng)歷了重大演變，解決了延遲、暫停時(shí)間和記憶體開銷等常見挑戰(zhàn)。本文探討了這些進(jìn)步，重點(diǎn)在於對(duì)開發(fā)人員從 JDK 8 等舊版本過渡到 JDK 17 和 JDK 21 等現(xiàn)代替代版本的實(shí)際影響。無論您是維護(hù)舊版應(yīng)用程式還是規(guī)劃未來的遷移，了解這些更新都至關(guān)重要。

重點(diǎn)

1. 自 JDK 8 以來的改進(jìn)：較新版本的 JDK 在記憶體管理和應(yīng)用程式效能方面提供了顯著增強(qiáng)。
2. 了解 GC 選項(xiàng)：為您的應(yīng)用程式選擇正確的垃圾收集器可以最佳化行為和資源使用。
3. 增量更新：分代 GC 模式和基於區(qū)域的堆佈局等進(jìn)步已經(jīng)改變了垃圾收集，提供了更好的可擴(kuò)展性和效率。

Java 中的垃圾收集 (GC) 可自動(dòng)化記憶體管理，使開發(fā)人員無需處理低階細(xì)節(jié)。 GC 的兩個(gè)主要目標(biāo)是：

1. 快速分配：Java 使用執(zhí)行緒本地分配緩衝區(qū) (TLAB) 進(jìn)行快速、無同步的記憶體分配。
2. 高效回收：GC 演算法透過壓縮和空閒清單等技術(shù)回收未使用的記憶體。

現(xiàn)代 Java GC 將堆分為兩代：

• 年輕代：儲(chǔ)存短暫的對(duì)象，收集頻繁但速度很快。
• 老一輩：儲(chǔ)存在多個(gè) GC 週期中存活下來的長壽命物件。

這種劃分基於分代假設(shè)，該假設(shè)假設(shè)大多數(shù)物件都會(huì)在年輕時(shí)死亡，從而使年輕代收集比完整堆收集更有效。 Java 提供了多種 GC 演算法，每種演算法都針對(duì)特定用例量身定制：

G1 GC 作為 JDK 9 中的預(yù)設(shè)收集器引入，使用基於區(qū)域的堆佈局並支援並發(fā)標(biāo)記。這使得它可以在不停止應(yīng)用程式執(zhí)行緒的情況下確定活動(dòng)性。透過將年輕代和老一代集合合併成更小的混合集合，G1 減少了暫停時(shí)間並提高了整體反應(yīng)能力。

ZGC 專為超低延遲而設(shè)計(jì)，可以處理 TB 大小的堆，暫停時(shí)間在亞毫秒範(fàn)圍內(nèi)。它與應(yīng)用程式線程同時(shí)執(zhí)行大部分工作，非常適合需要一致響應(yīng)能力的應(yīng)用程序，例如雲(yún)端服務(wù)或金融系統(tǒng)。

ZGC 分代模式（在 JDK 21 中引入）透過應(yīng)用分代假設(shè)來分離短壽命和長壽命對(duì)象，進(jìn)一步提高吞吐量。

SPECjbb 2015 等基準(zhǔn)測試表明，自 JDK 8 以來，現(xiàn)代 GC 演算法在吞吐量和延遲方面都有顯著改進(jìn)：

• 並行 GC：從 JDK 8 到 JDK 17，吞吐量增加了 30%。
• G1 GC：從 JDK 8 到 JDK 17，吞吐量增加了 40% 以上。
• ZGC：與 JDK 21 中的分代模式相比，提高了 10%。

減少暫停時(shí)間

所有收集器的暫停時(shí)間都已大幅減少：

• 並行 GC：從 ~100ms 到 ~65ms。
• G1 GC：從 JDK 8 到 JDK 17 減少了 40%。
• ZGC：亞毫秒暫停。

由於記憶集和用於基於區(qū)域的集合的資料結(jié)構(gòu)的最佳化，G1 GC 顯著減少了本機(jī)記憶體開銷。從 JDK 8 到 JDK 17，G1 的本機(jī)記憶體使用量幾乎減少了一半。為了更好地說明 GC 的實(shí)際應(yīng)用，請(qǐng)考慮以下範(fàn)例：

範(fàn)例1：配置G1 GC

# Add these options to your JVM startup command
java -XX:+UseG1GC -XX:MaxGCPauseMillis=50 -Xmx2g -Xms2g -jar app.jar

此配置：

• 活化 G1 GC。
• 將目標(biāo)最大暫停時(shí)間設(shè)定為 50 毫秒。
• 分配 2GB 堆記憶體。

調(diào)整 ZGC 以實(shí)現(xiàn)低延遲應(yīng)用

java -XX:+UseZGC -Xms4g -Xmx4g -XX:SoftRefLRUPolicyMSPerMB=50 -jar app.jar

此設(shè)定：

• 使用 ZGC 實(shí)現(xiàn)超低延遲。
• 分配 4GB 堆記憶體。
• 調(diào)整軟引用的生命週期以實(shí)現(xiàn)更好的記憶體管理。

遷移到 JDK 8 以外的挑戰(zhàn)

雖然從 JDK 8 升級(jí)到更新版本（例如 JDK 17 或 21）可以帶來顯著的好處，但開發(fā)人員必須考慮：

• 相容性問題：某些程式庫或框架可能無法完全支援較新的 JDK 版本。
• 效能調(diào)優(yōu)：每個(gè) GC 都有特定的調(diào)優(yōu)參數(shù)，可能需要調(diào)整這些參數(shù)才能獲得最佳效能。
• 暫存環(huán)境測試：在推出變更之前始終在非生產(chǎn)環(huán)境中進(jìn)行徹底測試。

自 JDK 8 以來，Java 垃圾回收的進(jìn)步非常顯著。隨著吞吐量、延遲和記憶體開銷的顯著改進(jìn)，任何 Java 應(yīng)用程式都需要升級(jí)到較新的 JDK 版本。

無論您執(zhí)行小型容器或大型雲(yún)端服務(wù)，都有針對(duì)您的用例進(jìn)行最佳化的 GC 演算法。因此，如果您仍在使用 JDK 8，那麼是時(shí)候?qū)崿F(xiàn)飛躍並享受現(xiàn)代 Java 的效能優(yōu)勢了。

有關(guān)更多信息，請(qǐng)觀看 Devoxx 比利時(shí)的有關(guān) Java 中的垃圾收集的視頻：Stefan Johansson 自 JDK 8 以來的進(jìn)展

？

以上是Java 中的垃圾回收：自 JDK 8 以來的進(jìn)展的詳細(xì)內(nèi)容。更多資訊請(qǐng)關(guān)注PHP中文網(wǎng)其他相關(guān)文章！