點擊上方?藍字?關注我們！

Java，Python，C/C++，Linux，PHP，Go，C#，QT，大數(shù)據(jù)，算法，軟件教程，前端，簡歷，畢業(yè)設計等分類，資源在不斷更新中... 點擊領取！

每天 11 點更新文章，餓了點外賣，點擊 ??《無門檻外賣優(yōu)惠券，每天免費領！》

目標

測試機器和項目
測試場景
jstat -gcutil
測試設置
默認（灰色標識）
Big（大）（紅色標識）
Balanced(平衡的)（藍色標識）
Sophisticated（復雜的）（橘色標識）

結果

Idea啟動時間
加載大項目花費的時間
在IDEA中打開兩個微服務
再次使用jstat –gcutil

最后的角逐：重新加載Monolith

最后一次使用jstat-gcutil

總結
討論

【編者按】本文作者在和同事的一次討論中發(fā)現(xiàn)，對 IntelliJ IDEA 內存采用不同的設置方案，會對 IDE 的速度和響應能力產(chǎn)生不同的影響。

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

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

昨天，大家就是否自定義 IntelliJ IDEA 的內存設置進行了討論，有些人選擇默認設置，有些人會對默認的設置進行簡單的變更，還有一些開發(fā)者會基于他們的需求進行全面復雜的設置。筆者目前的工作是處理幾個微服務項目和一個老項目，而客戶的核心業(yè)務需求非常大。對 IntelliJ IDEA 內存進行簡單設置以后，筆者明顯感受到了該 IDE 在速度和響應方面的改善。但當時筆者并未進行具體的測量，所以這只是主觀感受而已。

不過，參與討論的一位開發(fā)者給筆者發(fā)了一份他的設置，雖然是針對同個項目，該設置卻極其復雜。筆者對自己的設置并無不滿，但非常好奇，這些完全不同的設置對比 JetBrains 提供的默認設置，會有怎樣的不同。

目標

筆者的計劃是，在一個接近日常開發(fā)項目的場景下（加載一個大項目、加載2、3個微服務、git pull 后刷新大項目），測試各個設置帶來的效果，并選出內存消耗和速度都達到最優(yōu)時的最佳設置。

測試機器和項目

筆記本電腦：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 -gcutil

jstat -gcutil

jstat 是 JDK 自帶的工具，主要利用 JVM 內建的指令對 Java 應用程序的資源和性能進行實時的命令行監(jiān)控，還包括對 Heap size 和垃圾回收狀況的監(jiān)控。它有許多選項來收集各種數(shù)據(jù)（完整的文檔），但這里只會用到：-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

在本文中，最重要的參數(shù)是 GC 事件（ YGC 和 FGC ）次數(shù)和收集時間（ YGCT 和 FGCT ）。

測試設置

筆者設置了四種不同的設置，為了好記，給它們起了不同的名字。

默認（灰色標識）

JetBrains 提供的默認設置：

-Xms128m
-Xmx750m
-XX:MaxPermSize=350m
-XX:ReservedCodeCacheSize=240m
-XX:+UseCompressedOops

Big（大）（紅色標識）

給 Xmx 配 4096MB， ReservedCodeCacheSize 設置 1024MB，這已經(jīng)是相當多的內存了：

-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

以上便是筆者的測試設置，為了執(zhí)行該測試用例，還需要在~/Library/Preferences/IntelliJIdea15/下創(chuàng)建一個idea.vmoptions文件（這是 Mac OS 系統(tǒng)下的路徑設置，查看這篇文章，基于你的操作系統(tǒng)進行設置）

現(xiàn)在，執(zhí)行測試用例并比較結果。

結果

Idea啟動時間

正如上圖所示，啟動時間并不依賴于內存設置。Idea 在所有場景下的測試時間都是10秒，無論內存分配有多少。這并不足為奇，因為在此早期階段，這些設置并不會影響到應用的行為。

加載大項目花費的時間

現(xiàn)在加載 Monolith 項目及其70萬行代碼。終于，出現(xiàn)了一些的差異。默認設置所花費的時間幾乎是其它的3倍。很明顯，如此龐大的代碼庫需要更多的內存。如果我們執(zhí)行：

jstat?-gcutil?

會發(fā)現(xiàn)，對比其它設置， GC 在默認設置下會變得異常忙碌。

不僅 GC 釋放內存的總時間非常高（幾乎達到了50倍），而且 Full GC 的平均執(zhí)行時間也非常非常長。大量的時間都花在了 Full GC 上面，這是 IDE 響應速度低的主要原因。

在IDEA中打開兩個微服務

現(xiàn)在加載這兩個微服務項目，在 IDEA 中打開并且對比他們所消耗的時間。

在這個測試用例下，差異還是非常明顯的，復雜設置表現(xiàn)最佳，而默認設置仍舊輸給了其他兩種設置。

再次使用jstat –gcutil

加載完兩個微服務項目后，來檢查一下同時打開3個項目的情況下， GC 的表現(xiàn)情況。經(jīng)測試發(fā)現(xiàn)，3個不同的自定義設置表現(xiàn)幾乎差不多，而默認設置簡直弱爆了。

最后的角逐：重新加載Monolith

現(xiàn)在，筆者需要從倉庫中獲得 Monolith 項目的最新版本，并且刷新 Gradle 模塊，這樣， IDEA 能看到所有的新類。

重要提示：代表默認設置的灰色條形柱非常高，因為 IDEA 在刷新過程中崩潰了，筆者無法測量實際時間。顯然，默認分配的內存不足以執(zhí)行該操作。

但從三個自定義例子中可以發(fā)現(xiàn)，大內存配置花費的時間是最短的。所以，內存分配還是起到了作用。

最后一次使用jstat-gcutil

因為 IDEA 在默認設置下無法刷新項目，所以，這次測試默認設置就不包括在里面。

從上圖可以看出，三者之間的差異不大，但是 Big 配置下的 Full GC 執(zhí)行時間最快。此外， Xmx 內存大些對響應能力提升的幫助非常明顯。

總結

在這次簡短的實驗中，大家可以發(fā)現(xiàn)，即使對 IntelliJ IDEA 內存進行微調，都可以大大提升 IDE 性能。當然，內存分配越多，執(zhí)行效果就越好。但是，你也會發(fā)現(xiàn)， IDE 之外許多其他應用程序也需要消耗內存，所以，大家的目標應該是在提高性能和內存消耗之間找到一個平衡。筆者認為，在大多數(shù)情況下，把 Xmx 值設置在 2G 和 3G 之間是最佳的。如果你有更多的時間可以用 jstat 和 jvisualm 檢查用不同的 JVM 設置如何影響性能和內存占用。

討論

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

往期推薦

微服務項目優(yōu)雅上線、下線小技巧，你學廢了嗎？

愛不釋手的 9 個 JSON 工具

Nginx HTTPS 調優(yōu) - 看我如何提速 30%？

Dockerd 資源泄露應該如何應對？

看完文章，餓了點外賣，點擊 ??《無門檻外賣優(yōu)惠券，每天免費領！》

END

若覺得文章對你有幫助，隨手轉發(fā)分享，也是我們繼續(xù)更新的動力。

長按二維碼，掃掃關注哦

?「C語言中文網(wǎng)」官方公眾號，關注手機閱讀教程??

必備編程學習資料

目前收集的資料包括：?Java，Python，C/C++，Linux，PHP，go，C#，QT，git/svn，人工智能，大數(shù)據(jù)，單片機，算法，小程序，易語言，安卓，ios，PPT，軟件教程，前端，軟件測試，簡歷，畢業(yè)設計，公開課?等分類，資源在不斷更新中...

點擊“閱讀原文”，立即免費領取最新資料！

??????

IDEA 卡成一個球了 ！如何優(yōu)化 ?

目標