在調整JVM性能時,一般有三個組件須要考慮:vue
大多數調優選項都與調整堆大小和選擇合適的垃圾收集器有關,JIT編譯器對性能也有很大影響,但不多須要對其進行調優,尤爲是針對較新版本的JVM。java
一般,在進行Java程序調優的時候,會重點關注兩個主要指標:git
JVM自己是在不斷優化的,系統瓶頸的核心仍是在於應用代碼,更多的狀況下仍是要專一於應用代碼的優化。github
參數 | 描述 |
---|---|
-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參數及其默認值spring
參數 | 描述 |
---|---|
-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垃圾收集器在JDK8中是JVM默認的垃圾收集器,它是以吞吐量優先的垃圾收集器。其可調節的參數以下:springboot
參數 | 描述 |
---|---|
-XX:+UseParallelGC | 新生代使用並行垃圾收集器 |
-XX:+UseParallelOldGC | 老年代使用並行垃圾收集器 |
-XX:ParallelGCThreads | 設置用於垃圾回收的線程數 |
-XX:+UseAdaptiveSizePolicy | 打開自適應GC策略 |
CMS垃圾收集器是一個響應時間優先的垃圾收集器,Parallel收集器沒法知足應用程序延遲要求時再考慮使用CMS垃圾收集器,從JDK9開始CMS收集器已不建議使用,默認用的是G1垃圾收集器。markdown
參數 | 描述 |
---|---|
-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收集器是一個兼顧吞吐量和響應時間的收集器,若是是大堆(如堆的大小超過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數量控制 |
示例代碼:app
@SpringBootApplication public class SpringBootDemoApplication { public static void main(String[] args) { SpringApplication.run(SpringBootDemoApplication.class, args); Executors.newScheduledThreadPool(1) .scheduleAtFixedRate( () -> { new Thread( () -> { for (int i = 0; i < 150; i++) { try { byte[] temp = new byte[1024 * 512]; Thread.sleep(new Random().nextInt(1000)); } catch (InterruptedException e) { e.printStackTrace(); } } }) .start(); }, 100, 100, TimeUnit.MILLISECONDS); } }
GC分析主要查看GC致使的Stop The World的時間,它會致使程序的延時增長。dom
示例代碼運行的時候建議指定其堆內存的最大值,啓動時添加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日誌,更具監控進行相應的調節,進而找到最優值。