打開監控
結果出乎我的意料，從上圖可以看到，JIT（即時編輯）占了大頭，這也解釋了為什么每當我在修改新的代碼文件的內容時 CPU 占用率飆升，因為 JIT Compiler 即時編譯將 class 文件編譯成本地機器代碼占用了大量的 CPU 資源導致的卡頓，這下子問題找到了，該研究解決辦法了。
解決方法
知道了是 JIT 的鍋之后，我們該思考怎么解決它，我在網上參考了一篇博客修改了 JVM 的配置，如下圖：
`# 堆棧設置
-Xms2048m
-Xmx4096m
-Xverify:none
-XX:+DisableExplicitGC
-XX:ReservedCodeCacheSize=720m
-XX:+UseConcMarkSweepGC
-XX:SoftRefLRUPolicyMSPerMB=50
-ea
-Dsun.io.useCanonCaches=false
-Djava.net.preferIPv4Stack=true
-Djdk.http.auth.tunneling.disabledSchemes=""
-XX:+HeapDumpOnOutOfMemoryError
-XX:-OmitStackTraceInFastThrow
JIT 參數
設置用於編譯的編譯器線程數
-XX:CICompilerCount=2
開啟分層編譯
-XX:TieredStopAtLevel=1
控制最大數量嵌套調用內聯
-XX:MaxInlineLevel=3
即時編譯的東西（沒弄懂...）
-XX:Tier4MinInvocationThreshold=100000
-XX:Tier4InvocationThreshold=110000
-XX:Tier4CompileThreshold=120000
`
-XX:CICompilerCount
默認情況下，server JVM的線程數設置為2，clientJVM的線程數設置為1，如果使用分層編譯，則線程數將縮放為內核數
-XX:TieredStopAtLevel
開啟分層編譯
-XX：MaxInlineLevel
默認值為9，控制最大數量嵌套調用內聯。