升級 JDK17 一個不可拒絕的理由！

Java精選面試題（微信小程序）：5000+道面試題和選擇題，真實面經，簡歷模版，包含Java基礎、并發、JVM、線程、MQ系列、Redis、Spring系列、Elasticsearch、Docker、K8s、Flink、Spark、架構設計、大廠真題等，在線隨時刷題！

1. 背景 TLDR

垃圾回收器的暫停問題對實時響應要求較高的服務來說，一直是個痛點， CMS和G1等主流垃圾回收器的數十毫秒乃至上百毫秒的暫停時間相當致命。此外，調優門檻也相對較高，需要對垃圾回收器的內部機制有一定的了解，才能夠進行有效的調優。隨著ZGC的出現， 使得這一痛點徹底解決， ZGC 最初在 JDK 11 中作為實驗性功能引入，并在 JDK 15 中宣布為生產就緒， 由于JDK17才是比較正式提供給大眾實用的LTS支持版本，而且一部分公司已經在使用，所以本文力推JDK17。

ZGC 作為一款低延遲垃圾收集器，旨在滿足以下目標：

• 8MB到16TB的堆大小支持

• 10ms最大GC暫時

• 最糟糕的情況下吞吐量會降低15%（實測，如果參數配置的問題可能更糟， 官方這個稍微吹牛了點， 說實話就是用CPU換GC時間，也沒有那么高大上）

1.1. 升級JDK17的不可拒絕的理由

低延遲的業務需求，毫秒級耗時的GC

據美團的開發說：

在Zeus服務不同集群中，ZGC在低延遲（TP999 < 200ms）場景中收益較大：

• TP999 ：下降12~142ms，下降幅度18%~74%。

• TP99 ：下降5~28ms，下降幅度10%~47%。

可以忽略的升級JDK17的理由

• 新版的SpringBoot 官方最低支持 JDK17，想使用新Spring版本，就得升級

• JIT 編譯器的增強

• JDK 17 中的新功能，例如 Sealed 類、Pattern Matching、Records 等

• 升級到 JDK 17 可以獲得更好的安全性，包括修復的漏洞和強化的安全機制

1.2. 適用場景

• 網關服務

• Web API

暫不推薦場景：定時任務、批量任務、高CPU密集型應用

2. 升級前后對比

話不多說，先看效果

環境：

CPU： 4c Mem: 6GB

G1參數：

    -Xmx3500m -Xms3500m -XX:+UseG1GC -XX:MaxGCPauseMillis=100     -XX:G1ReservePercent=10 -XX:ConcGCThreads=2 -XX:ParallelGCThreads=5     -XX:G1HeapRegionSize=16m -XX:MaxTenuringThreshold=14     -XX:SurvivorRatio=8

ZGC參數：

--add-opens=java.base/java.lang=ALL-UNNAMED -Xms3500m -Xmx3500m -XX:ReservedCodeCacheSize=256m -XX:InitialCodeCacheSize=256m -XX:+UnlockExperimentalVMOptions -XX:+UseZGC -XX:ConcGCThreads=1 -XX:ParallelGCThreads=3 -XX:ZCollectionInterval=60 -XX:ZAllocationSpikeTolerance=4 -XX:+UnlockDiagnosticVMOptions -XX:-ZProactive  -Xlog:safepoint,classhisto*=trace,age*,gc*=info:file=/opt/gc-%t.log:time,tid,tags:filecount=5,filesize=50m

上述兩個參數，均已經在生產環境實驗過， 生產環境的機器是單機擁有1500業務tps的機器

2.1. GC耗時對比

從上圖可見， GC耗時是有著質的區別的，這個區別是你用CMS、Parallel GC、 G1 等嘔心瀝血也調校不出來的

這么短的GC， 可以保證，應用因為JVM層面的卡頓都保持在1ms 以內， 這也是為啥說這點才是不能拒絕的理由

2.2. CPU使用對比

從CPU使用上看， JDK17 相同的代碼， 比JDK8要高出10 ~ 20%

3. 升級方法

3.1. JDK選擇或安裝

使用JDK17前必須要安裝JDK17， 對于不同的Linux發行版或者操作系統安裝方法各不相同， 下面給出了一些樣例， 僅供參考。

# ubuntu 安裝jdk17 sudo apt install openjdk-17-jdk # docker 基礎鏡像 docker pull openjdk:17-slim docker pull openjdk:17-jdk-oraclelinux7 Dockerfile 復制代碼FROM openjdk:17-slim

3.2. JVM 參數調整

有了JDK17后，你已經具備了讓你的Java程序運行在JDK17上的基本條件了，下一步便是配置Jvm 參數如下（有需要的話，可以自行把換行整理下）：

    --add-opens=java.base/java.lang=ALL-UNNAMED \     -Xms1500m -Xmx1500m \     -XX:ReservedCodeCacheSize=256m \     -XX:InitialCodeCacheSize=256m \      -XX:+UnlockExperimentalVMOptions \     -XX:+UseZGC \     -XX:ConcGCThreads=1 -XX:ParallelGCThreads=2 \     -XX:ZCollectionInterval=30 -XX:ZAllocationSpikeTolerance=5 \     -XX:+UnlockDiagnosticVMOptions -XX:-ZProactive \     -Xlog:safepoint,classhisto*=trace,age*,gc*=info:file=/opt/gc-%t.log:time,tid,tags:filecount=5,filesize=50m \     -XX:+HeapDumpOnOutOfMemoryError \     -XX:HeapDumpPath=/opt/errorDump.hprof

4. 參數釋義

參數名

參數含義

--add-opens

JDK9模塊化后，導致javabase下面的一些基礎包訪問權限受阻， 需要開放訪問, 默認 設置java.base/java.lang=ALL-UNNAMED即可

-Xms1500m -Xmx1500m

堆內存設置，非常常見，不解釋

-XX:ReservedCodeCacheSize=256m

JIT編譯的代碼都放在CodeCache中，一般服務64m或128m就已經足夠

-XX:InitialCodeCacheSize=256m

初始code cache大小

-XX:+UnlockExperimentalVMOptions

開啟實驗性質的JVM選項，打開可以解鎖更多的JVM設置的能力

-XX:+UseZGC

使用ZGC

-XX:ConcGCThreads=1

并發回收垃圾的線程。默認是總核數的12.5%，8核CPU默認是1。調大后GC變快，但會多占用程序運行時的CPU資源

-XX:ParallelGCThreads=2

STW階段使用線程數，默認是總核數的60%

-XX:ZCollectionInterval=30

GC周期之間的最大間隔（單位秒）

-XX:ZAllocationSpikeTolerance=5

增大修正系數-XX:ZAllocationSpikeTolerance，更早觸發GC。ZGC采用正態分布模型預測內存分配速率，模型修正系數ZAllocationSpikeTolerance默認值為2

-XX:+UnlockDiagnosticVMOptions -XX:-ZProactive

是否啟用主動回收，默認開啟，這里的配置表示關閉

-Xlog:safepoint,classhisto*=trace,age*,gc*=info:file=/opt/gc-%t.log:time,tid,tags:filecount=5,filesize=50m

GC日志設置

-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/opt/errorDump.hprof

當發生OOM的時候HEAP DUMP 及其配置

歡迎大家加入技術交流群，全面提升自身技術能力。

來源：https://juejin.cn/post/7173271507047546893

公眾號“Java精選”所發表內容注明來源的，版權歸原出處所有（無法查證版權的或者未注明出處的均來自網絡，系轉載，轉載的目的在于傳遞更多信息，版權屬于原作者。如有侵權，請聯系，筆者會第一時間刪除處理！

最近有很多人問，有沒有讀者交流群！加入方式很簡單，公眾號Java精選，回復“加群”，即可入群！

文章有幫助的話，點在看，轉發吧！