IntelliJ IDEA 內存優化最佳實踐

提醒:此文是博主摘自其餘地方的,覺着不錯就貼到本身的博客裏留做筆記用,同時也做分享用。無心冒犯原創。html

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

  

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

  不要作守財奴,給IDE多留點內存吧。intellij-idea

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

  不過,參與討論的一位開發者給筆者發了一份他的設置,雖然是針對同個項目,該設置卻極其複雜。筆者對本身的設置並沒有不滿,但很是好奇,這些徹底不一樣的設置對比 JetBrains 提供的默認設置,會有怎樣的不一樣。ide

  目標微服務

  筆者的計劃是,在一個接近平常開發項目的場景下(加載一個大項目、加載二、3個微服務、git pull 後刷新大項目),測試各個設置帶來的效果,並選出內存消耗和速度都達到最優時的最佳設置。工具

  測試機器和項目筆記本電腦:MacBook Pro Retina, 2.3GHz Intel Core i7, 16GB 1600Mhz DDR3,SSD Disc, OS X Yosemite性能

  項目測試

  大項目—— Monolith ,70萬行代碼( Java 8 和 Groovy ),303個Gradle模塊

  兩個微服務——約有10000——20000行代碼( Java 8 和 Groovy )的小項目,各有一個Gradle模塊

  測試場景在 Idea 中關閉全部項目基於測試文件 idea.vmoptions 進行設置重啓電腦啓動後關閉全部不相關的項目( communicators 等等)打開 Idea(測試時間)打開大項目(測試時間)檢查 jstat -gcutil打開兩個微服務項目(測試時間)檢查 jstat -gcutil返回大項目而後點擊「刷新 Gradle 項目」按鈕(測試時間)檢查 jstat -gcutiljstat -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 設置如何影響性能和內存佔用。

  討論

  你的 idea.vmoptions 是如何配置的呢?你還有其它提升 InteliJ IDEA 性能的方法嗎?不妨一塊兒討論討論吧。