點選上方“芋道原始碼”，選擇“置頂公眾號”

技術文章第一時間送達！

原始碼精品專欄

 

• 精盡 Dubbo 原理與原始碼 69 篇

• 精盡 Netty 原理與原始碼 61 篇

• 中文詳細註釋的開源專案

• Java 併發原始碼合集

• RocketMQ 原始碼合集

• Sharding-JDBC 原始碼解析合集

• Spring MVC 和 Security 原始碼合集

• MyCAT 原始碼解析合集

來源：http://blog.oneapm.com/apm-tech/426.html

---

• 標的

• 結果

• 總結

• 討論

---

【編者按】本文作者在和同事的一次討論中發現，對 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 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 設定如何影響效能和記憶體佔用。

討論

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

---

---

如果你對 Dubbo / Netty 等等原始碼與原理感興趣，歡迎加入我的知識星球一起交流。長按下方二維碼噢：

目前在知識星球更新了《Dubbo 原始碼解析》目錄如下：

01. 除錯環境搭建
02. 專案結構一覽
03. 配置 Configuration
04. 核心流程一覽

05. 拓展機制 SPI

06. 執行緒池

07. 服務暴露 Export

08. 服務取用 Refer

09. 註冊中心 Registry

10. 動態編譯 Compile

11. 動態代理 Proxy

12. 服務呼叫 Invoke

13. 呼叫特性 

14. 過濾器 Filter

15. NIO 伺服器

16. P2P 伺服器

17. HTTP 伺服器

18. 序列化 Serialization

19. 叢集容錯 Cluster

20. 優雅停機

21. 日誌適配

22. 狀態檢查

23. 監控中心 Monitor

24. 管理中心 Admin

25. 運維命令 QOS

26. 鏈路追蹤 Tracing

… 一共 69+ 篇

目前在知識星球更新了《Netty 原始碼解析》目錄如下：

01. 除錯環境搭建
02. NIO 基礎
03. Netty 簡介
04. 啟動 Bootstrap

05. 事件輪詢 EventLoop

06. 通道管道 ChannelPipeline

07. 通道 Channel

08. 位元組緩衝區 ByteBuf

09. 通道處理器 ChannelHandler

10. 編解碼 Codec

11. 工具類 Util

… 一共 61+ 篇

目前在知識星球更新了《資料庫物體設計》目錄如下：

01. 商品模組
02. 交易模組
03. 營銷模組
04. 公用模組

… 一共 17+ 篇

目前在知識星球更新了《Spring 原始碼解析》目錄如下：

01. 除錯環境搭建
02. IoC Resource 定位
03. IoC BeanDefinition 載入

04. IoC BeanDefinition 註冊

05. IoC Bean 獲取

06. IoC Bean 生命週期

… 一共 35+ 篇

原始碼不易↓↓↓↓↓

點贊支援老艿艿↓↓