這樣調(diào)優(yōu)：讓你的 IDEA 快到飛起來，效率真高！

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

不要做守財奴，給IDE多留點(diǎn)內(nèi)存吧。

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

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

目標(biāo)

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

測試機(jī)器和項(xiàng)目

項(xiàng)目

測試場景

jstat -gcutil

jstat 是 JDK 自帶的工具，主要利用 JVM 內(nèi)建的指令對 Java 應(yīng)用程序的資源和性能進(jìn)行實(shí)時的命令行監(jiān)控，還包括對 Heap size 和垃圾回收狀況的監(jiān)控。它有許多選項(xiàng)來收集各種數(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. ?

這個命令的輸出結(jié)果如下：

S0 ? ? S1 ? ?E ? ? O ? ? M ? ?CCS ?YGC YGCT FGC ?FGCT ? GCT ?
89.700.0081.2674.2795.6891.76402.44414 ?0.715 ?3.159 ?

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

測試設(shè)置

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

默認(rèn)（灰色標(biāo)識）

JetBrains 提供的默認(rèn)設(shè)置：

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

Big（大）（紅色標(biāo)識）

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

-Xms1024m
-Xmx4096m
-XX:ReservedCodeCacheSize=1024m
-XX:+UseCompressedOops

Balanced(平衡的)（藍(lán)色標(biāo)識）

Xmx 和 Xms 都分配 2GB ，這是相當(dāng)平衡的內(nèi)存消耗：

-Xms2g
-Xmx2g
-XX:ReservedCodeCacheSize=1024m
-XX:+UseCompressedOops

Sophisticated（復(fù)雜的）（橘色標(biāo)識）

和上面一樣， Xmx 和 Xms 都分配2GB，但是給 GC 和內(nèi)存管理指定不同的垃圾回收器和許多不同的標(biāo)志：

-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

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

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

結(jié)果

Idea啟動時間

正如上圖所示，啟動時間并不依賴于內(nèi)存設(shè)置。Idea 在所有場景下的測試時間都是10秒，無論內(nèi)存分配有多少。這并不足為奇，因?yàn)樵诖嗽缙陔A段，這些設(shè)置并不會影響到應(yīng)用的行為。

加載大項(xiàng)目花費(fèi)的時間

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

jstat -gcutil  ?

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

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

在IDEA中打開兩個微服務(wù)

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

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

再次使用jstat –gcutil

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

最后的角逐：重新加載Monolith

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

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

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

最后一次使用jstat-gcutil

因?yàn)?IDEA 在默認(rèn)設(shè)置下無法刷新項(xiàng)目，所以，這次測試默認(rèn)設(shè)置就不包括在里面。

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

總結(jié)

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

討論

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

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

往期熱門文章：
1、《歷史文章分類導(dǎo)讀列表！精選優(yōu)秀博文都在這里了！》
2、萬億級數(shù)據(jù)應(yīng)該怎么遷移？
3、從應(yīng)用到底層 36張圖帶你進(jìn)入Redis世界
4、寫代碼有這16個好習(xí)慣，可以減少80%非業(yè)務(wù)的bug
5、順豐快遞：請簽收MySQL靈魂十連
6、一個基于SpringBoot + MyBatis + Vue的代碼生成器
7、Redis 分布式鎖使用不當(dāng)，超賣了100瓶飛天茅臺?。?！
8、如何設(shè)計訂單系統(tǒng)？這篇寫得太好了！
9、如果MySQL磁盤滿了，會發(fā)生什么？還真被我遇到了！
10、阿里開源的27個項(xiàng)目，值得收藏！