[id_6[]]

别再当旁观者，给你的集成开发环境增加更多功能吧。

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

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

然而，在讨论中，一位开发者向笔者分享了他的配置方案，尽管它也是为了同一个项目，但该方案显得异常繁复。笔者对自己的配置并无任何不快，却对这种截然不同的配置方案与项目提供的标准配置进行对比，会产生何种差异感到极感兴趣。

目标

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

测试机器和项目

笔记本电脑型号为Pro，搭载2.3GHz的Intel Core i7处理器intellij idea 14教程，内存配置为16GB DDR3，配备SSD固态硬盘，操作系统为OS X。

项目

这是一项重大工程——，涉及70万行Java 8和其相关语言的代码，共由303个模块构成。

这两个微服务项目，其代码量大约在10000至20000行之间，主要采用Java 8语言编写，每个项目都包含一个独立的功能模块。

测试场景jstat -

jstat 是 Java Kit（JDK）中内置的一个工具，它主要通过调用 JVM（Java虚拟机）内置的指令，对运行中的 Java 应用程序进行实时监控，关注点包括资源使用情况和性能表现，同时亦涵盖对堆内存大小以及垃圾回收过程的监控。

jstat 完整的文档:

它有许多选项来收集各种数据，但这里只会用到：- :

-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  

本文的核心关注点在于 GC 事件（包括 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均设定为2GB，然而在垃圾回收器及内存管理方面，则采用了不同的回收机制，以及众多独特的参数选项。

-server
-Xms2g
-Xmx2g
-XX:NewRatio=3
-Xss16m
-XX:+UseConcMarkSweepGC
-XX:+CMSParallelRemarkEnabled
-XX:ConcGCThreads=4
-XX:ReservedCodeCacheSize=240m
-XX:+AlwaysPreTouch
-XX:+TieredCompilation
-XX:+UseCompressedOops
限制对特定参数的调整，确保每兆字节内存的软引用回收策略时间间隔为50毫秒。
-Dsun.io.useCanonCaches=false
在启动Java程序时，请确保设置-Djava.net.preferIPv4Stack参数为true，以优先使用IPv4协议栈。
配置文件中设置SNI扩展功能禁用，具体操作为将djsse.enableSNIExtension参数值设为false。
-ea

以上内容即为作者所设定的测试方案，要实施这一测试案例，需在相应位置创建一个名为idea的文件（请注意，这是针对Mac OS系统的路径设定，根据您的操作系统进行相应调整，关注“Java面试那些事儿”公众号，回复“idea”关键字，即可获取最新的idea教程信息）。

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

结果Idea启动时间

正如图表所展示，启动速度并不受内存配置的影响。在所有测试场景中，Idea的运行时长均为10秒钟，内存的分配量并不改变这一结果。这种现象并不令人感到意外，因为在应用的初期阶段，这些配置选项对应用的表现并无显著影响。更多关于IDEA的信息，敬请关注。

加载大项目花费的时间

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

jstat -gcutil <IDEA_PID>  

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

GC 释放内存所需的总时长极为可观（几乎相当于50倍）intellij idea 14教程，同时 Full GC 的平均执行时长同样极为漫长。在大量时间中，Full GC 占据了主导地位，正是这一原因导致了 IDE 响应速度的低下。

在IDEA中打开两个微服务

现在，我们需将这两个微服务项目加载，并在 IDEA 环境中逐一打开，以观察并比较它们各自所耗费的时间。

本测试案例中，差异现象显著可见，复杂配置展现出卓越性能，与此同时，预设配置却未能超越其他两种配置的表现。

再次使用jstat –

完成两个微服务项目的加载之后，我决定对在同时操作三个项目时垃圾回收（GC）的表现进行一番考察。测试结果显示，三个项目各自采用的不同自定义配置在性能上相差无几，然而，系统默认的配置则显得相当不理想。

最后的角逐：重新加载

目前，作者必须从库中提取项目的当前最新版本，同时更新模块，以确保IDE能够识别到所有新增的类。

请注意：该提示所指的灰色条形柱高度显著，这是由于在IDEA刷新期间发生崩溃，导致作者未能获取到实际耗时。显而易见，系统默认分配的内存容量不足以支持该任务的执行。

通过观察三个自定义的示例，我们可以发现，在配置大内存的情况下，所需的时间明显更少。因此，可以得出结论，内存的分配确实发挥了其应有的作用。

最后一次使用jstat-

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

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

总结

在本次简短的实验里，我们发现即便对IDE的内存进行细致的调整，也能显著增强其性能。显然，内存分配得越多，其运行效果自然更佳。然而，我们也注意到，除了IDE，许多其他应用程序同样需要占用内存资源。因此，我们的目标是在提升性能与控制内存消耗之间寻求一个合理的平衡点。

作者认为，在多数情形下，将 Xmx 参数设定在2G至3G范围内是较为理想的。若您拥有充裕的时间，不妨利用 jstat 工具来监测，观察不同 JVM 配置对性能与内存消耗的具体影响。

讨论

您的想法在设置上是如何进行的？您是否还有其他提升IDEA效能的策略？让我们来共同探讨一番。

译者：

请访问网址blog.com，进入apm-tech目录，然后点击426号页面。

dzone.com网站上的独此一家——至臻至纯的理念

如有侵权请联系删除！