快捷導(dǎo)航

idea啟動(dòng)后CPU飆升的問題解決

更新時(shí)間：2023年05月30日 11:15:50 作者：Ricoh.

IDEA運(yùn)行大型項(xiàng)目,項(xiàng)目啟動(dòng)卡頓,CPU使用率占用過高,下面這篇文章主要給大家介紹了關(guān)于idea啟動(dòng)后CPU飆升的問題解決,文中通過實(shí)例代碼介紹的非常詳細(xì),需要的朋友可以參考下

解決idea 啟動(dòng)后CPU飆升的問題

CPU飆升是因?yàn)閕dea產(chǎn)生了某種瘋狂消耗CPU資源，可以通過idea自帶的監(jiān)控來來觀察到底是什么進(jìn)程占用了CPU的資源

iead監(jiān)控所在地

Iead監(jiān)控

其實(shí)網(wǎng)上大部分講的都是因?yàn)镴IT（just in time,即時(shí)編譯技術(shù)）導(dǎo)致CPU飆升，但是經(jīng)過我的檢測(cè)發(fā)現(xiàn)，JIT也僅僅是我的idea卡頓的一部分原因。

配置前：

不配置JIT參數(shù)前

配置后：

可以觀測(cè)到idea CPU還是會(huì)飆升，但是JIT所占用的CPU大幅度下降，說明還是很有效果的。

# JIT 參數(shù)

# 設(shè)置用于編譯的編譯器線程數(shù)
-XX:CICompilerCount=2
# 開啟分層編譯
-XX:TieredStopAtLevel=1
# 控制最大數(shù)量嵌套調(diào)用內(nèi)聯(lián)
-XX:MaxInlineLevel=3
-XX:Tier4MinInvocationThreshold=100000
-XX:Tier4InvocationThreshold=110000
-XX:Tier4CompileThreshold=120000

后續(xù)又發(fā)現(xiàn)是因?yàn)椴粩嗟卦谶M(jìn)行GC導(dǎo)致CPU飆升，因?yàn)槊看蜧C都會(huì)消耗99%的CPU資源，于是想著修改JVM參數(shù)來解決這個(gè)問題。

因?yàn)槲业膇dea是新裝的，他的堆大小參數(shù)為：

-Xms128m
-Xmx2048m

然后查閱資料得知，當(dāng)Xms設(shè)置值比較小時(shí)，會(huì)頻繁的觸發(fā)GC，而GC又會(huì)出現(xiàn)STW的情況，所以idea一直GC，那你的idea也必然是一卡一卡的，同時(shí)大部分都推薦相同值，這是為什么呢？

這是為了避免在由于heap內(nèi)存擴(kuò)大或縮小導(dǎo)致應(yīng)用停頓，降低延遲，同時(shí)避免每次垃圾回收完成后JVM 重新分配內(nèi)存。

所以修改后的堆的大小為：

-Xms2048m
-Xmx2048m

然后又發(fā)現(xiàn)自己的GC收集器使用的是CMS，那么讀過JVM這本書的都知道，CMS采用標(biāo)記-清理的算法，標(biāo)記出垃圾對(duì)象，清除垃圾對(duì)象。算法是基于老年代執(zhí)行的，因?yàn)樾律a(chǎn)生無法接受該算法產(chǎn)生的碎片垃圾。他的缺點(diǎn)是：

無法清理浮動(dòng)垃圾，并發(fā)收集會(huì)造成內(nèi)存碎片過多
由于并發(fā)標(biāo)記和并發(fā)清理階段都是并發(fā)執(zhí)行，所以會(huì)額外消耗CPU資源

基于此，我將垃圾收集器也替換為了G1，G1的優(yōu)勢(shì)是：

可控制回收垃圾的時(shí)間
和CMS一樣采用標(biāo)記-清理的算法，但是G1不會(huì)產(chǎn)生空間碎片（G1從整體來講是基于標(biāo)記-整理來實(shí)現(xiàn)垃圾回收
從局部來講，又是把整個(gè)堆，切割為大小均勻的多個(gè)region，region與region之間采用標(biāo)記-復(fù)制算法實(shí)現(xiàn)），這樣就有效的使用了連續(xù)空間，不會(huì)導(dǎo)致連續(xù)空間不足提前造成GC的觸發(fā)。

最后貼出完整的JVM參數(shù)：

-server
-XX:MetaspaceSize=128M
-XX:MaxMetaspaceSize=512M
-XX:+AlwaysPreTouch
-Xms2048m
-Xmx2048m
-XX:ReservedCodeCacheSize=512m
-XX:+UseG1GC
-XX:+UseStringDeduplication
-XX:AutoBoxCacheMax=20000
-ea
-Dsun.io.useCanonCaches=false
-Dsun.awt.keepWorkingSetOnMinimize=true
-Djava.net.preferIPv4Stack=true
-Djdk.http.auth.tunneling.disabledSchemes=""
-Djsse.enablesSNIExtension=false
-XX:+HeapDumpOnOutOfMemoryError
-XX:-OmitStackTraceInFastThrow
-Dfile.encoding=UTF-8

# JIT 參數(shù)

# 設(shè)置用于編譯的編譯器線程數(shù)
-XX:CICompilerCount=2
# 開啟分層編譯
-XX:TieredStopAtLevel=1
# 控制最大數(shù)量嵌套調(diào)用內(nèi)聯(lián)
-XX:MaxInlineLevel=3
-XX:Tier4MinInvocationThreshold=100000
-XX:Tier4InvocationThreshold=110000
-XX:Tier4CompileThreshold=120000

如果以上操作還是不能解決CPU過高的話，還可以打開

1、打開idea設(shè)置 File–>Settings–> Build,Execution,Deployment --> Compiler
2、調(diào)整 Shared build process heap size(Mbytes) 大小，默認(rèn)值700，可修改至 1024（或者自定義數(shù)值）

至于網(wǎng)上還有提出的插件，或者代碼檢查我們也可以去嘗試一下，通過修改里面的配置結(jié)合idea自帶的監(jiān)控來快速準(zhǔn)確定位問題，但是也告訴我們，要對(duì)癥下藥，有自帶的工具去幫你，何樂而不為呢？

總結(jié)

到此這篇關(guān)于idea啟動(dòng)后CPU飆升的問題解決的文章就介紹到這了,更多相關(guān)idea啟動(dòng)后CPU飆升內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

您可能感興趣的文章: