往期热门文章：

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

昨日，众人围绕是否自定义内存配置展开了热议，部分人倾向于保留预设值，另有部分用户对预设进行了简易调整，而部分开发者则根据自身需求进行了全面而细致的配置。目前，笔者正忙于数个微服务项目的维护以及一个老旧项目的处理，客户的业务核心需求尤为突出。经过对内存进行基础配置，作者明显察觉到了该集成开发环境在运行速度和反应速度上的提升。然而，作者当时并未进行详尽的量化测试，因此这仅是个人主观上的体验。

然而，一位参与讨论的开发者为笔者提供了一份他的配置方案，尽管它是针对同一个项目的，但该方案显得相当繁复。对于自己的配置，笔者并无任何抱怨，然而他充满了好奇，这些截然不同的配置与项目提供的标准配置相较，究竟会产生怎样的差异。

笔者的意图在于，模拟日常开发项目的情况（如加载一个大型项目、加载两三个微服务、执行git pull操作并刷新大项目），通过测试不同配置所产生的影响，从而筛选出在内存使用和运行速度两方面均表现最优异的配置方案。

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

项目

该大型项目——，涉及70万行代码（采用Java 8语言编写），共计303个模块。

该项目包含两个微服务，其代码量大约在10000至20000行之间，主要采用Java 8编写，并且每个微服务都配备了一个独立的模块。

jstat 是 JDK 内置的一个实用工具，其主要功能是通过JVM内置的指令，对Java应用程序的资源使用情况和性能表现进行实时监控。此外，它还涵盖了堆内存大小以及垃圾回收过程的监控。

jstat 完整的文档:

请勿访问该网页，该链接指向的是一份关于Unix系统中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.  
[id_1918911938]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  

在本文中，最为关键的指标包括了垃圾回收事件（包括年轻代垃圾回收和Full GC）的触发频率以及相应的耗时（即年轻代垃圾回收耗时和Full GC耗时）。

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

提供的默认设置：

-Xms128m
-Xmx750m
-XX:MaxPermSize=350m
XX中设置了保留代码缓存的大小，该值为240兆字节。
-XX:+UseCompressedOops

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

-Xms1024m
-Xmx4096m
XX配置项中，保留代码缓存的大小被设定为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
在启动参数中，确保将-Djava.net.preferIPv4Stack设置为true，以优先使用IPv4网络栈。
关闭了启用SNI扩展的功能设置，Djsse的配置属性中SNIExtension的值为false。
-ea

这便是笔者的测试配置，为了实施该测试案例，需在指定路径下建立一个名为idea的文件（请注意，此路径适用于Mac OS系统，请根据您的操作系统调整，如需了解详细信息，请关注“Java面试那些事儿”公众号，回复“idea”关键字，即可获取最新的教程指导）。

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

Idea启动时间

现在正在加载该项目以及其包含的70万行代码。经过一番努力，我们发现了若干差异。按照默认设置，处理这些差异所需的时间大约是其他情况的3倍。显而易见，如此庞大的代码库对内存的需求量也更大。若我们进行如下操作：

jstat -gcutil <IDEA_PID>  

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

GC 释放内存所需的总时长异常漫长（几乎膨胀了50倍），同时，Full GC 的平均运行时间同样极为漫长。大量宝贵的时间被 Full GC 所消耗，这直接导致了 IDE 响应速度的显著降低。

现在，我们需要加载这两个微服务项目，并在 IDEA 环境中逐一打开它们，同时进行时间消耗的对比分析。

在此测试案例中，差异显著可见，复杂配置展现出卓越性能intellij idea 14.0.3，相较之下，预设配置则未能超越其他两种配置。

完成两个微服务项目的加载后，我决定对同时开启三个项目时的GC性能进行一番考察。测试结果显示，三个项目各自采用的不同自定义配置在性能上相差无几，但与默认配置相比，那可真是相形见绌。

目前，作者必须取得仓库中项目的最先进版本，同时更新模块，以便 IDEA 能够识别出所有新增的类。

请注意，指示默认设置的灰度色条形柱显得格外高耸，这主要是因为在IDEA刷新过程中出现了崩溃，导致作者无法准确获取实际所需时间。显而易见，系统默认分配的内存容量不足以支撑这一操作。

通过观察三个自定义的示例，我们可以看出，在配置较大内存时，所需时间相对较短。因此，可以确认内存分配确实发挥了其应有的作用。

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

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

在这次实验过程中，大家能够观察到，即便对IDE的内存进行细微调整，也能显著增强其性能。显然，内存分配得越多，程序的运行效果越佳。然而，同时也会注意到，除了IDE之外，众多其他应用程序同样需要占用内存资源。因此，我们的目标应当是在提升性能与控制内存消耗之间寻求一个合理的平衡点。

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

你的想法在具体实施上是如何安排的？此外，你是否有其他途径来优化IDEA的性能表现？我们何不共同探讨一下呢？

译者：

如有侵权请联系删除！