目标

笔者的意图在于，在模拟日常开发项目的过程（如加载一个大型项目、引入2至3个微服务、执行git pull操作并刷新大项目）中，检验不同配置所产生的影响，最终筛选出在内存占用和运行速度均达到最佳状态下的理想配置。

测试机器和项目

该笔记本电脑配置为：搭载2.3GHz的Intel Core i7处理器，内存容量为16GB DDR3，配备SSD固态硬盘，操作系统为OS X。

[]

该大型项目——，由70万行代码构成，其中涉及Java 8语言，并包含303个独立的模块。

该项目包含两个微服务，其代码量介于一万至两万行之间，均采用Java 8语言编写，且每个微服务都配备了一个独立的功能模块。

测试场景

在 Idea 中关闭所有项目

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

重启电脑

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

打开 Idea（测试时间）

打开大项目（测试时间）

检查 jstat -

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

检查 jstat -

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

检查 jstat -

jstat -

jstat 是 JDK 内置的一项工具，主要功能是通过 JVM 内置的指令，对 Java 应用程序的资源使用情况和性能表现进行实时监控。该工具涵盖了 Heap 大小以及垃圾回收状态的监控。它提供了丰富的选项用于数据收集，然而在本例中，我们将仅使用其中的一部分。

- :

[id_1899764363]of垃圾回收数据统计。
S0: Survivor space 0 utilization as a percentage of the space's current capacity.
S1: 在空间1中，生存空间的利用率以百分比形式呈现s current capacity.
E: Eden space utilization as a percentage of the space's current capacity.
老旧空间利用率，即占空间总量的百分比，不得更改。s current capacity.
M: Metaspace utilization as a percentage of the space's current capacity.
CCS：压缩后的班级空间利用率，以百分比形式表示。
YGC表示年轻代垃圾回收事件的数量。
青年世代垃圾分类收集时刻。
全垃圾回收事件数。
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 设置 ，这已经是相当多的内存了：

设置JVM堆内存初始值为1024兆字节，最大值为4096兆字节，保留代码缓存大小为1024兆字节，并启用压缩对象指针功能。

(平衡的)（蓝色标识）

Xmx与Xms均设定为2GB，这样的内存分配相当均衡intellij idea mac，能够有效控制内存消耗。

-Xms2g
-Xmx2g
请勿修改预留的代码缓存大小，其值设定为1024兆字节。
-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
-XX:SoftRefLRUPolicyMSPerMB=50
-Dsun.io.useCanonCaches=false
-Djava.net.preferIPv4Stack=true
-Djsse.enableSNIExtension=false
-ea

这便是作者所设定的测试环境，为了实施这一测试案例，我们需在指定路径下建立一个名为idea的文件（请注意，这是针对Mac OS系统的路径配置，请根据您的操作系统进行相应的调整）。

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

结果

Idea启动时间

正如图中所示，启动速度与内存配置无关。在所有测试环境中，Idea的运行时长均为10秒钟，内存分配量的多少并不改变这一结果。这种情况并不令人意外，因为在应用的早期阶段，这些配置对应用的表现并无显著影响。

加载大项目花费的时间

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

jstat -gcutil 

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

GC 释放内存所需的总时长极为可观（几乎是其他方式50倍之多），同时，Full GC 的平均执行时间同样极其漫长。在这其中，大量时间被 Full GC 所占据，正是导致 IDE 响应速度缓慢的根源所在。

在IDEA中打开两个微服务

启动这两个微服务项目，于 IDEA 环境中逐一打开，并观察它们各自所耗费的时间。

在此测试场景中，不同设置间的差异相当显著；在复杂配置下，性能最为出色；然而，默认配置依旧未能超越其他两种配置。

再次使用jstat –

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

最后的角逐：重新加载

目前，作者必须从仓储中提取该项目的最新版本，同时更新模块，以便IDE能够识别所有新增的类。

请注意，指示默认设置的灰色条形柱显得异常高大，这主要是因为在IDEA刷新过程中发生了崩溃，导致作者无法获取到实际所需的时间。显而易见，系统默认分配的内存容量不足以支持这一操作的执行。

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

最后一次使用jstat-

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

观察图表可发现，三者间的区别并不显著，然而在Big配置中，Full GC的执行速度是最快的。另外，当Xmx内存容量增加时，对系统响应速度的提升效果尤为显著。

总结

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

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

此翻译链接指向的是关于“唯一”理念的唯一资源。

完

往期推荐

有道无术，术可成；有术无道，止于术

如有侵权请联系删除！