idea打開的多了 內存占用也就多了 下邊是親試的優化ide性能的方法

1.設置JVM的啟動參數：

　　進入idea的安裝目錄的bin文件夾

　　打開 idea.exe.vmoptions 文件， 修改-Xmx 的 值為2048m

　　打開 idea64.exe.vmoptions 文件， 修改-Xmx 的 值為2048m

　　打開idea.properties文件，找到idea.max.intellisense.filesize，默認是2500，改為25000（數值僅供參考，具體數值根據自己文件大小來定）

　　參數作用：

　　　　-Xms1024m 設置初時的內存大小，提高Java程序的啟動速度
　　　　-Xmx2048m 設置最大內存數，提高該值，可以減少內存Garage收集的頻率，提高程序性能
　　　　-XX:ReservedCodeCacheSize=480m設置代碼內存容量
　　　　-XX:+UseParNewGC 使用并行收集算法
　　　　-server 控制內存garage方式，這樣你無需在花一到兩分鐘等待內存garage的收集

2.菜單配置設置JVM的啟動參數：通過Help - Edit Custom VM Options...菜單設置配置，IntelliJ會優先使用這個地方的配置文件

3.關閉代碼檢查：　　

IntelliJ的代碼檢測功能非常強大，但也占用了一些資源，可以將默認的除 Error之外的其他級別的檢測都去掉　　

4.清空緩存并重建索引：

　　將編譯進程和Maven的堆值設置大一些

ps：下面看下IntelliJ IDEA 更新后，電腦卡成球，該如何優化？

來源 | https://urlify.cn/NBBbam

在和同事的一次討論中發現，對 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[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 設置如何影響性能和內存占用。

到此這篇關于IntelliJ IDEA 更新后電腦卡成球該如何優化的文章就介紹到這了,更多相關IntelliJ IDEA更新電腦卡內容請搜索腳本之家以前的文章或繼續瀏覽下面的相關文章希望大家以后多多支持腳本之家！