歡迎您光臨本站 註冊首頁

IntelliJ IDEA 性能優化的教程詳解

←手機掃碼閱讀     e36605 @ 2020-05-13 , reply:0

idea打開的多了 內存佔用也就多了 下邊是親試的優化ide性能的方法
1.設置JVM的啟動參數:
進入idea的安裝目錄的bin文件夾
打開 idea.exe.vmoptions 文件, 修改-Xmx 的 值為2048m
打開 idea64.exe.vmoptions 文件, 修改-Xmx 的 值為2048m
打開idea.properties文件,找到idea.max.intellisense.filesize,默認是2500,改為25000(數值僅供參考,具體數值根據自己文件大小來定)
參數作用:
-Xms1024m 設置初時的內存大小,提高Java程序的啟動速度
-Xmx2048m 設置最大內存數,提高該值,可以減少內存Garage收集的頻率,提高程序性能
-XX:ReservedCodeCacheSize=480m設置代碼內存容量
-XX:+UseParNewGC 使用並行收集算法
-server 控制內存garage方式,這樣你無需在花一到兩分鐘等待內存garage的收集
2.菜單配置設置JVM的啟動參數:通過 Help - Edit Custom VM Options... 菜單設置配置,IntelliJ會優先使用這個地方的配置文件
3.關閉代碼檢查:
IntelliJ的代碼檢測功能非常強大,但也佔用了一些資源,可以將默認的除 Error之外的其他級別的檢測都去掉
4.清空緩存並重建索引:
將編譯進程和Maven的堆值設置大一些
ps:下面看下IntelliJ IDEA 更新後,電腦卡成球,該如何優化?
來源 | https://urlify.cn/NBBbam
在和同事的一次討論中發現,對 IntelliJ IDEA 內存採用不同的設置方案,會對 IDE 的速度和響應能力產生不同的影響。
Don't be a Scrooge and give your IDE some more memory
不要做守財奴,給IDE多留點內存吧。
昨天,大家就是否自定義IntelliJ IDEA 的內存設置進行了討論,有些人選擇默認設置,有些人會對默認的設置進行簡單的變更,還有一些開發者會基於他們的需求進行全面複雜的設置。筆者目前的工作是處理幾個微服務項目和一個老項目,而客戶的核心業務需求非常大。對 IntelliJ IDEA 內存進行簡單設置以後,筆者明顯感受到了該 IDE 在速度和響應方面的改善。但當時筆者並未進行具體的測量,所以這只是主觀感受而已。
不過,參與討論的一位開發者給筆者發了一份他的設置,雖然是針對同個項目,該設置卻極其複雜。筆者對自己的設置並無不滿,但非常好奇,這些完全不同的設置對比 JetBrains 提供的默認設置,會有怎樣的不同。
目標
筆者的計劃是,在一個接近日常開發項目的場景下(加載一個大項目、加載2、3個微服務、git pull 後刷新大項目),測試各個設置帶來的效果,並選出內存消耗和速度都達到最優時的最佳設置。
測試機器和項目
筆記本電腦:MacBook Pro Retina, 2.3GHz Intel Core i7, 16GB 1600Mhz DDR3,SSD Disc, OS X Yosemite
項目
大項目―― Monolith ,70萬行代碼( Java[1] 8 和 Groovy ),303個Gradle模塊
兩個微服務――約有10000――20000行代碼( Java 8 和 Groovy )的小項目,各有一個Gradle模塊
測試場景
在 Idea 中關閉所有項目 基於測試文件 idea.vmoptions 進行設置 重啟電腦 啟動後關閉所有不相關的項目( communicators 等等) 打開 Idea(測試時間) 打開大項目(測試時間) 檢查 jstat -gcutil 打開兩個微服務項目(測試時間) 檢查 jstat -gcutil 返回大項目然後點擊“刷新 Gradle 項目”按鈕(測試時間) 檢查 jstat -gcutil
jstat -gcutil
jstat 是 JDK 自帶的工具,主要利用 JVM 內建的指令對 Java 應用程序的資源和性能進行實時的命令行監控,還包括對 Heap size 和垃圾回收狀況的監控。它有許多選項來收集各種數據,但這裡只會用到:
-gcutil :
-gcutil - Summary of garbage collection statistics.
S0: Survivor space 0 utilization as a percentage of the space's current capacity.
S1: Survivor space 1 utilization as a percentage of the space's current capacity.
E: Eden space utilization as a percentage of the space's current capacity.
O: Old space utilization as a percentage of the space's current capacity.
M: Metaspace utilization as a percentage of the space's current capacity.
CCS: Compressed class space utilization as a percentage.
YGC: Number of young generation GC events.
YGCT: Young generation garbage collection time.
FGC: Number of full GC events.
FGCT: Full garbage collection time.
GCT: Total garbage collection time.
這個命令的輸出結果如下:
S0 S1 E O M CCS YGC YGCT FGC FGCT GCT
89.70 0.00 81.26 74.27 95.68 91.76 40 2.444 14 0.715 3.159
在本文中,最重要的參數是 GC 事件( YGC 和 FGC )次數和收集時間( YGCT 和 FGCT )。
測試設置
筆者設置了四種不同的設置,為了好記,給它們起了不同的名字。
默認(灰色標識)
JetBrains 提供的默認設置:
-Xms128m
-Xmx750m
-XX:MaxPermSize=350m
-XX:ReservedCodeCacheSize=240m
-XX:+UseCompressedOops
Big(大)(紅色標識)
給 Xmx 配 4096MB, ReservedCodeCacheSize 設置 1024MB,這已經是相當多的內存了:
-Xms1024m
-Xmx4096m
-XX:ReservedCodeCacheSize=1024m
-XX:+UseCompressedOops
Balanced(平衡的)(藍色標識)
Xmx 和 Xms 都分配 2GB ,這是相當平衡的內存消耗:
-Xms2g
-Xmx2g
-XX:ReservedCodeCacheSize=1024m
-XX:+UseCompressedOops
Sophisticated(複雜的)(橘色標識)
和上面一樣, Xmx 和 Xms 都分配2GB,但是給 GC 和內存管理指定不同的垃圾回收器和許多不同的標誌:
-server
-Xms2g
-Xmx2g
-XX:NewRatio=3
-Xss16m
-XX:+UseConcMarkSweepGC
-XX:+CMSParallelRemarkEnabled
-XX:ConcGCThreads=4
-XX:ReservedCodeCacheSize=240m
-XX:+AlwaysPreTouch
-XX:+TieredCompilation
-XX:+UseCompressedOops
-XX:SoftRefLRUPolicyMSPerMB=50
-Dsun.io.useCanonCaches=false
-Djava.net.preferIPv4Stack=true
-Djsse.enableSNIExtension=false
-ea
以上便是筆者的測試設置,為了執行該測試用例,還需要在~/Library/Preferences/IntelliJIdea15/下創建一個idea.vmoptions文件(這是 Mac OS 系統下的路徑設置,基於你的操作系統進行設置)
現在,執行測試用例並比較結果。
結果Idea啟動時間
正如上圖所示,啟動時間並不依賴於內存設置。Idea 在所有場景下的測試時間都是10秒,無論內存分配有多少。這並不足為奇,因為在此早期階段,這些設置並不會影響到應用的行為。
加載大項目花費的時間
現在加載 Monolith 項目及其70萬行代碼。終於,出現了一些的差異。默認設置所花費的時間幾乎是其它的3倍。很明顯,如此龐大的代碼庫需要更多的內存。如果我們執行:
jstat -gcutil


會發現,對比其它設置, GC 在默認設置下會變得異常忙碌。
不僅 GC 釋放內存的總時間非常高(幾乎達到了50倍),而且 Full GC 的平均執行時間也非常非常長。大量的時間都花在了 Full GC 上面,這是 IDE 響應速度低的主要原因。
在IDEA中打開兩個微服務
現在加載這兩個微服務項目,在 IDEA 中打開並且對比他們所消耗的時間。
在這個測試用例下,差異還是非常明顯的,複雜設置表現最佳,而默認設置仍舊輸給了其他兩種設置。
再次使用jstat �Cgcutil
加載完兩個微服務項目後,來檢查一下同時打開3個項目的情況下, GC 的表現情況。經測試發現,3個不同的自定義設置表現幾乎差不多,而默認設置簡直弱爆了。
最後的角逐:重新加載Monolith
現在,筆者需要從倉庫中獲得 Monolith 項目的最新版本,並且刷新 Gradle 模塊,這樣, IDEA 能看到所有的新類。
重要提示:代表默認設置的灰色條形柱非常高,因為 IDEA 在刷新過程中崩潰了,筆者無法測量實際時間。顯然,默認分配的內存不足以執行該操作。
但從三個自定義例子中可以發現,大內存配置花費的時間是最短的。所以,內存分配還是起到了作用。
最後一次使用jstat-gcutil
因為 IDEA 在默認設置下無法刷新項目,所以,這次測試默認設置就不包括在裡面。
從上圖可以看出,三者之間的差異不大,但是 Big 配置下的 Full GC 執行時間最快。此外, Xmx 內存大些對響應能力提升的幫助非常明顯。
總結
在這次簡短的實驗中,大家可以發現,即使對 IntelliJ IDEA 內存進行微調,都可以大大提升 IDE 性能。當然,內存分配越多,執行效果就越好。但是,你也會發現, IDE 之外許多其他應用程序也需要消耗內存,所以,大家的目標應該是在提高性能和內存消耗之間找到一個平衡。筆者認為,在大多數情況下,把 Xmx 值設置在 2G 和 3G 之間是最佳的。如果你有更多的時間可以用 jstat 和 jvisualm 檢查用不同的 JVM 設置如何影響性能和內存佔用。


[e36605 ] IntelliJ IDEA 性能優化的教程詳解已經有117次圍觀

http://coctec.com/docs/developer/show-post-234325.html