JVM 參數及調優

調優基本概念

在調整 JVM 性能時，通常有三個組件需要考慮：

1. 堆大小調整
2. 垃圾收集器調整
3. JIT 編譯器

大多數調優選項都與調整堆大小和選擇合適的垃圾收集器有關，JIT 編譯器對性能也有很大影響，但很少需要對其進行調優，尤其是針對較新版本的 JVM。

通常，在進行 Java 程序調優的時候，會重點關注兩個主要指標：

• 響應性：應用程序對請求進行響應的速度，對於專注響應性的應用程序，長時間的暫停是不可接受的，需要在最短時間內做出響應
• 吞吐量：側重於在特定時間內最大化應用程序的工作量，對於專注於吞吐量的應用程序，符合要求的暫停是可以接受的。

JVM 本身是在不斷優化的，系統瓶頸的核心還是在於應用代碼，更多的情況下還是要專注於應用代碼的優化。

常用 JVM 參數

參數	描述
-XX:+AlwaysPreTouch	JVM 啓動時分配內存，堆的每個頁面都在初始化期間按需置零，而不是在應用程序執行期間遞增
-XX:Errorfile = filename	錯誤日誌
-XX:+TraceClassLoading	跟蹤類加載信息
-XX:+PrintClassHistogram	按下 Ctrl+Break 後打印類信息
-Xmx -Xms	最大堆 最小堆
-xx:permSize	永久代大小
-xx:metaspaceSize	元數據空間大小
-XX:+HeapDumpOnOutOfMemoryError	當拋出 OOM 時進行 HeapDump
-XX:+HeapDumpPath	OOM 時堆導出的路徑
-XX:OnOutOfMemoryError	當發生 OOM 時執行用戶指定的命令

命令： java -XX:+PrintFlagsFinal -version 會 打印所有的 - XX 參數及其默認值

GC 調優思路

1. 分析場景，如：啓動速度慢，偶爾出現響應慢於平均水平或出現卡頓
2. 確定目標，如：內存佔用，低延時，吞吐量
3. 收集日誌，如：通過參數配置收集 GC 日誌，通過 JDK 工具查看 GC 狀態
4. 分析日誌，如：使用工具輔助分析日誌，查看 GC 次數，GC 時間
5. 調整參數，如：切換垃圾收集器或者調整垃圾收集器參數

常用 GC 參數

參數	描述
-XX:ParallelGCThreads	並行 GC 線程數量
-XX:ConcGcThreads	併發 GC 線程數量
-XX:MaxGCPauseMillis	最大停頓時間，單位毫秒，GC 盡力保證回收時間不超過設定值
-XX:GCTimeRatio	垃圾收集時間佔總時間的比值，取值 0-100，默認 99，即最大允許 1% 的時間做 GC
-XX:SurvivorRatio	設置 eden 區大小和 survivor 區大小的比例，8 表示兩個 survivor:eden=2:8，即一個 survivor 佔年輕代的 1/10
-XX:NewRatio	新生代和老年代的比，4 表示新生代：老年代 = 1:4，即年輕代佔堆的 1/5
-verbose:gc，-XX:+PrintGC	打印 GC 的簡要信息
-XX:+PrintGCDetails	打印 GC 詳細信息（JDK9 之後不再使用）
-XX:+PrintGCTimeStamps	打印 GC 發生的時間戳（JDK9 之後不再使用）
-Xloggc:log/gc.log	指定 GC log 的位置，以文件輸出
-XX:PrintHeapAtGC	每次 GC 後都打印堆信息

垃圾收集器 Parallel 參數調優

Parallel 垃圾收集器在 JDK8 中是 JVM 默認的垃圾收集器，它是以吞吐量優先的垃圾收集器。其可調節的參數如下：

參數	描述
-XX:+UseParallelGC	新生代使用並行垃圾收集器
-XX:+UseParallelOldGC	老年代使用並行垃圾收集器
-XX:ParallelGCThreads	設置用於垃圾回收的線程數
-XX:+UseAdaptiveSizePolicy	打開自適應 GC 策略

垃圾收集器 CMS 參數調優

CMS 垃圾收集器是一個響應時間優先的垃圾收集器，Parallel 收集器無法滿足應用程序延遲要求時再考慮使用 CMS 垃圾收集器，從 JDK9 開始 CMS 收集器已不建議使用，默認用的是 G1 垃圾收集器。

參數	描述
-XX:+UseConcMarkSweepGC	新生代使用並行收集器，老年代使用 CMS + 串行收集器
-XX:+UseParNewGC	新生代使用並行收集器，老年代 CMS 收集器默認開啓
-XX:CMSInitiatingOccupanyFraction	設置觸發 GC 的閾值，默認 68%，如果內存預留空間不夠，就會引起 concurrent mode failure
-XX:+UseCMSCompactAtFullCollection	Full GC 後，進行一次整理，整理過程是獨佔的，會引起停頓時間變長
-XX:+CMSFullGCsBeforeCompaction	設置進行幾次 Full GC 後進行一次碎片整理
-XX:+CMSClassUnloadingEnabled	允許對類元數據進行回收
-XX:+UseCMSInitiatingOccupanyOnly	表示只在達到閾值的時候才進行 CMS 回收
-XX:+CMSIncrementalMode	使用增量模式，比較適合單 CPU

垃圾收集器 G1 參數調優

G1 收集器是一個兼顧吞吐量和響應時間的收集器，如果是大堆（如堆的大小超過 6GB）, 堆的使用率超過 50%，GC 延遲要求穩定且可預測的低於 0.5 秒，建議使用 G1 收集器。

參數	描述
-XX:G1HeapRegionSize	設置 Region 大小，默認 heap/2000
-XX:G1MixedGCLiveThresholdPercent	老年代依靠 Mixed GC, 觸發閾值
-XX:G1OldSetRegionThresholdPercent	定多包含在一次 Mixed GC 中的 Region 比例
-XX:+ClassUnloadingWithConcurrentMark	G1 增加默認開啓，在併發標記階段結束後，JVM 即進行類型卸載
-XX:G1NewSizePercent	新生代的最小比例
-XX:G1MaxNewSizePercent	新生代的最大比列
-XX:G1MixedGCCountTraget	Mixed GC 數量控制

調優示例

GC 分析主要查看 GC 導致的 Stop The World 的時間，它會導致程序的延時增加。

示例代碼運行的時候建議指定其堆內存的最大值，啓動時添加 JVM 參數 - Xmx1024m。程序運行起來之後可以利用 jps 或者 jcmd 產看運行的程序進程號。

拿到進程號之後利用 jstat 命令查看 GC 信息，如動態監控 GC 統計信息，間隔 1000 毫秒統計一次，每 10 行數據後輸出列標題：

上述兩個步驟也可以合併成一個 jstat -gc -h10 $(jcmd | grep “com.example.springbootdemo.SpringBootDemoApplication” | awk ‘{print $1}’) 1000

當然除了動態監控 GC 信息，也可以將 GC 日誌信息打印到文件，然後利用 GC 分析工具進行分析。
在程序啓動時添加 JVM 參數”-Xmx1024m -Xloggc:/gc.log“，則可以可以將 GC 日誌打印到 gc.log 文件，然後可以利用 GCViewer 工具輔助分析 GC 日誌文件，參考地址：https://github.com/chewiebug/GCViewer

GCViewer 下載後雙擊 gcviewer-x.xx-SNAPSHOT.jar 文件即可運行，然後將 gc.log 日誌文件導入即可觀察 GC 信息。

GC 調優之前，我們需要了解當前 JVM 參數的信息。命令 java -XX:+PrintFlagsFinal -version 會打印所有的 JVM 參數，如需查看指定參數，如查看 UseAdaptiveSizePolicy 的值可以使用 java -XX:+PrintFlagsFinal -version | grep UseAdaptiveSizePolicy

調整 - XX:ParallelGCThreads 的值可以指定 GC 併發的線程數，如在 JVM 啓動參數中可以添加 “-Xmx1024m -XX:ParallelGCThreads=4”，調節 GC 併發的線程數，觀察 GC 的信息，如 Full GC 次數 FGC，Full GC 的總時間 FGCT，GC 的總時間 GCT 等進行調優。

同樣我們可以在 JVM 啓動參數中指定 - XX:MaxGCPauseMills，使用 G1 收集器 - XX:+UseG1GC 等，調節 JVM 啓動參數，收集 GC 日誌，更具監控進行相應的調節，進而找到最優值。