IntelliJ IDEA 卡成球了？

在和同事的一次討論中發現，對 IntelliJ IDEA 內存採用不一樣的設置方案，會對 IDE 的速度和響應能力產生不一樣的影響。

Don’t be a Scrooge and give your IDE some more memory

不要作守財奴，給IDE多留點內存吧。

昨天，你們就是否自定義IntelliJ IDEA 的內存設置進行了討論，有些人選擇默認設置，有些人會對默認的設置進行簡單的變動，還有一些開發者會基於他們的需求進行全面複雜的設置。筆者目前的工做是處理幾個微服務項目和一個老項目，而客戶的核心業務需求很是大。對 IntelliJ IDEA 內存進行簡單設置之後，筆者明顯感覺到了該 IDE 在速度和響應方面的改善。但當時筆者並未進行具體的測量，因此這只是主觀感覺而已。

不過，參與討論的一位開發者給筆者發了一份他的設置，雖然是針對同個項目，該設置卻極其複雜。筆者對本身的設置並沒有不滿，但很是好奇，這些徹底不一樣的設置對比 JetBrains 提供的默認設置，會有怎樣的不一樣。 關注微信公衆號果汁簡歷 ，回覆 IDEA  就 可 以避免費獲取註冊碼

目標

筆者的計劃是，在一個接近平常開發項目的場景下（加載一個大項目、加載二、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模塊

測試場景

1. 在 Idea 中關閉全部項目
2. 基於測試文件 idea.vmoptions 進行設置
3. 重啓電腦
4. 啓動後關閉全部不相關的項目（ communicators 等等）
5. 打開 Idea（測試時間）
6. 打開大項目（測試時間）
7. 檢查 jstat -gcutil
8. 打開兩個微服務項目（測試時間）
9. 檢查 jstat -gcutil
10. 返回大項目而後點擊「刷新 Gradle 項目」按鈕（測試時間）
11. 檢查 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 <IDEA_PID> 
 
      

    

會發現，對比其它設置， GC 在默認設置下會變得異常忙碌。

不只 GC 釋放內存的總時間很是高（幾乎達到了50倍），並且 Full GC 的平均執行時間也很是很是長。大量的時間都花在了 Full GC 上面，這是 IDE 響應速度低的主要緣由。

在IDEA中打開兩個微服務

如今加載這兩個微服務項目，在 IDEA 中打開而且對比他們所消耗的時間。

在這個測試用例下，差別仍是很是明顯的，複雜設置表現最佳，而默認設置仍舊輸給了其餘兩種設置。

再次使用jstat –gcutil

加載完兩個微服務項目後，來檢查一下同時打開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 設置如何影響性能和內存佔用。

翻譯：https://dzone.com/articles/the-one-and-only-reason-to-customize-intellij-idea

本文分享自微信公衆號 - 碼農沉思錄（code-thinker）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。