IDEA 内存优化最佳实践 技术分享 第1张

别再当个懒虫，给你的集成开发环境多加些功能吧。

不要做守财奴，给IDE多留点内存吧。

昨日intellij idea logo，众人围绕是否对IDEA的内存配置进行自定义展开了热议，部分人倾向于保留预设值，部分人则对预设值进行小幅调整，而另一些开发者则会根据自身需求进行细致而全面的配置。笔者目前正忙于数个微服务项目的开发以及一个旧项目的维护，且客户的核心业务需求量颇大。在完成对 IDEA 内存进行基础配置后，我明显察觉到了该集成开发环境在运行速度和响应速度上的提升。然而，当时我并未进行详尽的量化测试，因此这仅是基于个人体验的主观评价。

然而，在讨论中，一位开发者向笔者分享了他的配置方案，尽管它也是针对同一项目，但结构异常繁复。笔者对自己的配置并无任何抱怨，却对这种截然不同的配置方案充满好奇，心想与系统提供的标准配置相比，它们之间会有怎样的差异。

目标

笔者的目的是，在模拟日常开发环境（如加载一个大型项目、引入2至3个微服务、执行git pull操作并刷新大项目）的条件下，检验不同配置所产生的成效，进而筛选出在内存占用和运行速度方面均表现最佳的配置方案。

测试机器和项目

项目

测试场景

在 Idea 中关闭所有项目

基于测试文件 idea. 进行设置

重启电脑

启动后关闭所有不相关的项目（ 等等）

打开 Idea（测试时间）

打开大项目（测试时间）

检查 jstat -

打开两个微服务项目（测试时间）

检查 jstat -

返回大项目然后点击“刷新 项目”按钮（测试时间）

检查 jstat -

jstat -

jstat是JDK集成的一款工具，其主要功能是通过JVM内置的指令对Java应用程序的资源消耗和运行性能进行实时监控。此外，它还涵盖了Heap空间大小及垃圾回收过程的监测。该工具提供了丰富的选项用于收集各类数据（详细文档可参考），然而在本例中，我们将仅使用以下选项：- :

-gcutil - Summary of垃圾收集数据统计。
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年轻一代的GC活动。
青年一代垃圾分类时刻。
FGC: Number of full GC events.  
FGCT：完整的垃圾回收时长。
GCT：总垃圾回收时长。

这个命令的输出结果如下：

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  

在本文中，最为关键的指标包括了垃圾收集事件（包括年轻代垃圾收集事件YGC和全垃圾收集事件FGC）的频率以及相应的耗时（即年轻代垃圾收集耗时YGCT和全垃圾收集耗时FGCT）。

测试设置

笔者设置了四种不同的设置，为了好记，给它们起了不同的名字。

默认（灰色标识）

提供的默认设置：

-Xms128m
-Xmx750m
-XX:MaxPermSize=350m
XX中指定的预留代码缓存大小为240兆字节。
-XX:+UseCompressedOops

Big（大）（红色标识）

给 Xmx 配 ， e 设置 ，这已经是相当多的内存了：

-Xms1024m
-Xmx4096m
系统已设定，保留代码缓存的大小为1024兆字节。
-XX:+UseCompressedOops

(平衡的)（蓝色标识）

Xmx与Xms均设定为2GB，这样的内存分配显得相当均衡，既不过分消耗，也足以满足需求。

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

（复杂的）（橘色标识）

与之前一致，Xmx与Xms均设定为2GBintellij idea logo，然而，针对垃圾回收与内存管理，我们采用了不同的回收器，并设置了众多独特的参数。

-server
-Xms2g
-Xmx2g
-XX:NewRatio=3
-Xss16m
-XX:+UseConcMarkSweepGC
-XX:+CMSParallelRemarkEnabled
-XX:ConcGCThreads=4
-XX:ReservedCodeCacheSize=240m
-XX:+AlwaysPreTouch
-XX:+TieredCompilation
-XX:+UseCompressedOops
禁止对软引用LRU策略的每兆字节时间阈值进行修改，其设定值为50。
-Dsun.io.useCanonCaches=false
在启动参数中指定-Djava.net.preferIPv4Stack=true，以确保Java程序优先使用IPv4协议栈。
禁止启用SNI扩展功能，设置值为false。
-ea

以上内容即是笔者的测试配置，为了实施这一测试案例，必须在指定路径下建立一个名为idea的文件（此为Mac操作系统中的路径设定，请参照本文，根据您的操作系统进行调整）。

现在，执行测试用例并比较结果。

结果Idea启动时间

IDEA 内存优化最佳实践 技术分享 第2张

如上图所展示，启动过程并不受内存配置的限制。在所有测试场景中，Idea的运行时长均为10秒钟，内存的分配量并不改变这一结果。这种现象并不令人意外，因为在应用的初期阶段，这些配置对应用表现的影响微乎其微。

加载大项目花费的时间

当前正在导入该项目及附带的七十万行代码。经过一番努力，我们发现了若干差异。采用默认配置所需的时间几乎是其他配置的三倍之多。显而易见，如此庞大的代码库确实需要更多的内存空间。若我们执行：

jstat -gcutil <IDEA_PID>  

会发现，对比其它设置， GC 在默认设置下会变得异常忙碌。

IDEA 内存优化最佳实践 技术分享 第3张

IDEA 内存优化最佳实践 技术分享 第4张

GC释放内存所需的总时长极其漫长（几乎增至50倍之多），同时，Full GC的平均运行时间也极为漫长。在大量时间里，Full GC占据了主导，这直接导致了IDE响应速度的低下。

在IDEA中打开两个微服务

现在我们需要加载这两个微服务项目，并在 IDEA 环境中对其进行打开，同时观察并对比它们各自所耗费的时间。

IDEA 内存优化最佳实践 技术分享 第5张

在此测试案例中，差异显著可见；复杂配置展现出卓越性能，与此同时，标准配置则未能战胜另外两种配置。

再次使用jstat –

完成两个微服务项目的加载后，我决定对同时操作三个项目时的GC性能进行一番检验。测试结果显示，三个项目各自采用的不同自定义配置在性能上几乎相当，但与之形成鲜明对比的是，默认配置的表现则显得相当不尽人意。

IDEA 内存优化最佳实践 技术分享 第6张

IDEA内存优化技术分享会第七部分的高潮环节：重温优化之道

目前，作者必须从储存设施中提取该项目的最先进版本，同时更新相关模块，以确保IDEA能够识别并展示所有新增的类别。

IDEA 内存优化最佳实践 技术分享 第8张

请注意：指示默认设置的灰度色块异常地高耸，这是由于在IDEA刷新时程序崩溃，导致作者未能获取到实际所需的时间。显而易见，系统分配的内存容量不足以支持这一操作。

从那三个自设的案例中可以看出，进行大容量内存配置所需的时间最为短暂。因此，可以明确内存的分配确实发挥了其应有的作用。

最后一次使用jstat-

由于 IDEA 在其预设配置中不具备项目刷新的功能，因此在本轮测试中，我们未将默认配置纳入考量范围。

IDEA 内存优化最佳实践 技术分享 第9张

IDEA 内存优化最佳实践 技术分享 第10张

观察图表可知，这三者间的区别并不显著，然而在Big配置中，Full GC的执行速度最为迅速。再者，增加Xmx内存容量对于提升系统响应速度的效果尤为显著。

总结

在这次短暂的实验里，大家观察到即便对IDE的内存进行细致的调整，也能显著增强IDE的工作效率。显然，分配给内存的资源越多，程序的运行效果越佳。然而，同时也会注意到，除了IDE，许多其他应用程序同样需要占用内存资源。因此，我们的目标应当是在提升性能与控制内存使用之间寻求一个合理的平衡点。作者认为，在多数情形下，将 Xmx 参数调整至2G至3G这一区间，通常能取得较优的效果。若您拥有充裕的时间，不妨利用 jstat 工具来监测，探究不同 JVM 配置对性能与内存消耗的具体影响。

讨论

您的想法在配置上是如何安排的？另外，您是否还有其他途径来增强IDEA的性能？让我们来共同探讨一下这个问题吧。

看到这里，说明你喜欢本文

如有侵权请联系删除！