JVM性能調優實戰:讓你的IntelliJ Idea縱享絲滑
本文已被Github倉庫收錄 https://github.com/silently9527/JavaCore
前言在前面整理了一篇關于JVM故障診斷和處理工具，考慮到大部分的Java程序員都使用的是IntelliJ Idea，本篇就使用工具來實戰演練對IntelliJ Idea運行速度調優
調優前的運行狀態原始配置內容
要查詢idea原始配置文件的路徑可以在VisualVM中的概述中查看
原始配置內容：
-XX:ReservedCodeCacheSize=240m-XX:+UseCompressedOops-Dfile.encoding=UTF-8-XX:SoftRefLRUPolicyMSPerMB=50-ea-Dsun.io.useCanonCaches=false-Djava.net.preferIPv4Stack=true-Djdk.http.auth.tunneling.disabledSchemes=''-XX:+HeapDumpOnOutOfMemoryError-XX:-OmitStackTraceInFastThrow-XX:ErrorFile=$USER_HOME/java_error_in_idea_%p.log-XX:HeapDumpPath=$USER_HOME/java_error_in_idea.hprof-Xmx512m打印啟動時間插件開發
需要直觀的看到優化前和優化后啟動時間的變化，所以需要簡單做一個Idea的插件開發，關于Idea插件開發的流程建議參考我以前的文章《IDEA插件：多線程文件下載插件開發》
JVM的啟動時間到所有組件初始化完成后的時間就看做是IDEA的啟動時間，代碼如下
public class MyApplicationInitializedListener implements ApplicationInitializedListener { @Override public void componentsInitialized() { RuntimeMXBean bean = ManagementFactory.getRuntimeMXBean(); long startTime = bean.getStartTime(); long costTime = System.currentTimeMillis() - startTime; Messages.showMessageDialog('毫秒：' + costTime, '啟動耗時', Messages.getInformationIcon()); }}
plugin.xml中添加如下代碼：
<extensions defaultExtensionNs='com.intellij'> <applicationInitializedListener implementation='cn.silently9527.MyApplicationInitializedListener'/></extensions>
優化前的啟動信息與時間消耗
根據VisualGC和IDEA啟動插件收集到的信息：
IDEA啟動耗時 15s 總共垃圾收集22次，耗時1.2s，其中新生代GC 17次，耗時324ms; 老年代GC 5次，耗時953ms 加載類27526個，耗時 21s按照這個數據來看也算是正常，15s 其實也在接受范圍內，由于本文主要演示性能調優，所以需要測試能否在快一些
開始嘗試優化調整內存來控制垃圾回收頻率
圖上我們可以看出，啟動參數指定的512m的內存被分配到新生代的只有169m，由于IDEA是我們開發常用的工具，平時的編譯過程也需要足夠的內存，所以我們需要先把總的內存擴大，這里我設置最大的內存 -Xmx1024m ，為了讓JVM在GC期間不需要再浪費時間再動態計算擴容大小，同時也設置了 -Xms1024m ；
在啟動的過程中Eden共發生了17次GC，為了減少新生代gc次數，我把新生代的內存大小設置成 -Xmn256m ;
重新啟動之后查看VisualGC，新生代gc次數從 17次 降低到了 7次，耗時從 324ms 降低到了 152ms。
在調整內存前發生了5次Full GC，調整內存后的依然還是有4次Full GC，但是從兩張圖我們可以看出，老年代的空間還有很多剩余，是不應該發生Full GC的；考慮是否是代碼中有地方手動調用 System.gc() 出發了Full GC，所以添加了參數 -XX:+DisableExplicitGC ，再次重新啟動IDEA，結果很失望，依然還有4次Full GC；
再次仔細觀察優化前的圖，注意看 Last Cause: Metadata GC Threshold , 最后一次gc是應該Metaspace區域內存不夠發生的GC，為了驗證我們的猜想，打印出GC日志來看看。在 idea.vmoptions 中添加打印日志相關的參數：
-XX:+PrintGCDetails-XX:+PrintGCDateStamps-Xloggc:../gc.log
JVM的GC日志的主要參數包括如下幾個：
-XX:+PrintGC 輸出GC日志 -XX:+PrintGCDetails 輸出GC的詳細日志 -XX:+PrintGCTimeStamps 輸出GC的時間戳（以基準時間的形式） -XX:+PrintGCDateStamps 輸出GC的時間戳（以日期的形式，如 2013-05-04T21:53:59.234+0800） -XX:+PrintHeapAtGC 在進行GC的前后打印出堆的信息 -Xloggc:../logs/gc.log 日志文件的輸出路徑重新啟動idea，查看gc.log
其中 PSYoungGen: 表示新生代使用的ParallelScavenge垃圾收集器， 31416K->0K(181248K) 表示 gc前已使用的內存大小 -> gc后已使用內存大小（該區域的總內存大小）
從日志中我們看出每次Full GC都是因為 Metadata GC Threshold ，而Metaspace每次gc回收的內存幾乎沒有，僅僅是擴大了該區域的容量；找到了原因那就好辦了，添加如下的參數調整Metaspace的大小：
-XX:MetaspaceSize=256m
再次重啟Idea之后，發現Full GC沒有了，心情很爽
測試打開大項目點擊編譯代碼，發現自己的idea卡死了，查看VisualGC之后發現堆內存都還有空閑，只有Metaspace被全部占滿了，所以是自己給的最大空間設置太小，所以直接去掉了 -XX:MaxMetaspaceSize=256m
選擇垃圾收集器從剛才的gc日志中，我們可以發現默認使用的是ParallelScavenge + Parallel Old垃圾收集器，這個組合注重的是吞吐量，這里我們嘗試換一個注重低延時的垃圾收集器試一試
ParNew + CMS
在 idea.vmoptions 中添加如下配置：
-XX:+UseConcMarkSweepGC-XX:+UseParNewGC
重啟IDEA之后查看VisualGC
很尷尬，同樣發生了6次gc， ParallelScavenge + Parallel Old 的組合耗時197ms，而 ParNew + CMS 的組合耗時379ms；雖然是這個結果，但是我們需要考慮當前只發生了MinorGC，如果發生FullGC了結果又會如何了，大家可以自己測試一下
G1
我們在換一個最新的G1垃圾回收器試試，在 idea.vmoptions 中添加如下配置：
-XX:+UseG1GC
這個結果好像也還是要慢一點點，自己多次測試過這兩個垃圾回收器，雖然每次結果都不一樣，相差不遠，所以垃圾回收器可以自己選擇，這里我們選擇的是G1
類加載時間優化根據之前的分析，idea啟動加載類27526個，耗時 21s，這個我們有辦法能優化一下嗎？因為idea是常用的開發工具，經常很多人的使用，我們可以認為它的代碼是安全的，是否符合當前虛擬機的要求，不會危害虛擬機的安全，所以我們使用參數 -Xverify:none 來禁用字節碼的驗證過程
重啟IDEA
耗時下降到了11s，效果還是比較明顯的
總結做完了所有優化之后，經過多次重啟測試，平均的啟動時間下降到了11s，為了安慰我本次操作沒有白辛苦，搞一張11s以下的圖
我已經從零開始手寫了簡易版springmvc，以及編寫了詳細的說明文檔，希望能夠幫助伙伴們深入理解springmvc核心原理.
源碼獲取地址：我把開源的項目代碼都已經放到了Git倉庫，Github倉庫地址：https://github.com/silently9527 ，碼云倉庫地址：https://gitee.com/silently9527 ，
到此這篇關于JVM性能調優實戰:讓你的IntelliJ Idea縱享絲滑的文章就介紹到這了,更多相關JVM性能調優內容請搜索好吧啦網以前的文章或繼續瀏覽下面的相關文章希望大家以后多多支持好吧啦網！
相關文章：
網公網安備