企业官网建设流程全解析

IntelliJ IDEA 用久了变卡，十有八九会被人甩一句"去把内存调大点"。可真到自己动手，改哪个文件、改成多少、为什么改了没反应，一串问号就冒出来了。我前后在十几台机器上折腾过「修改 IntelliJ IDEA 内存大小」这件事——从 8GB 内存的老笔记本到 64GB 的工作站，从社区版到完整版，从纯 Java 后端工程到夹着一堆前端和构建脚本的混合项目。踩过的坑比参数条数多得多：改大了启动直接报错，改小了跟没改一样，改在安装目录里升级一次全白干。

这篇就把这件事从"判断症状、算定数值、动手修改、验证生效、排查翻车"完整走一遍。路径、文件名、参数模板都写成可以直接抄的形式，适合刚装好 IDE 想顺手优化的新手，也适合天天和 OOM、卡顿打架、想让机器再多扛两年的老手对照着看。

1. 先判断症状：卡顿到底是不是内存的锅

改内存之前最该做的事，是先确认你遇到的是内存问题。我见过太多人把"打开项目要等三分钟"当成内存不足，结果把-Xmx从 2GB 调到 8GB，卡顿一点没变——因为那是索引和磁盘的锅，跟堆内存毫无关系。方向搞错，后面所有操作都是白费。

1.1 IDEA 的内存分好几块，别只盯着堆

IntelliJ IDEA 是一个跑在 JBR（JetBrains Runtime，可以理解成 JetBrains 定制版 OpenJDK）上的桌面应用，所以它的内存结构和任何一个 Java 进程一样，不是一个数字。任务管理器里看到的"内存占用 3.2GB"，其实由这么几部分组成：

• 堆内存（Heap）：就是我们改-Xmx控制的那块，放对象实例、索引结构、编辑器缓冲区。这是唯一一个大头能通过参数直接调整的部分。
• 元空间（Metaspace）：存类元数据，插件越多、类加载越多它越大，默认没有上限（受物理内存限制）。
• 代码缓存（CodeCache）：JIT 编译后的机器码放这里，对应参数是-XX:ReservedCodeCacheSize。
• 线程栈：每个线程一份，-Xss控制单份大小，线程数乘以它才是总量。
• 堆外内存：NIO 的 DirectByteBuffer、JNI 调用、图形渲染缓冲区，都不在-Xmx管辖范围内。

所以你会看到一个反直觉的现象：把-Xmx从 2GB 提到 4GB，任务管理器里的进程内存可能涨到 5GB 甚至更多。这不是设置失败，而是堆外和元空间在正常工作。理解这一点，后面才不会对着数字疑神疑鬼。

1.2 什么叫"真的内存不足"

判断是不是堆内存不够，有三条相对硬的证据，我个人按可信度排序：

第一，右下角内存指示器长期贴着上限。开启方式是在状态栏右键勾选内存指示器，或者走 Help → Diagnostic Tools → Show Memory Indicator。它显示的格式类似980M of 2048M，前者是当前已用堆，后者是-Xmx的值。稳态下占 50% 到 70% 属于健康区间；如果长期贴在 90% 以上、GC 一跑数字才掉下来，那确实是紧张了。

第二，日志里出现 OutOfMemoryError: Java heap space。这个不用解释，堆真的爆了。日志位置在 Help → Show Log in Explorer/Finder，盯着idea.log。注意要区分是 IDE 主进程爆了，还是某个构建进程爆了——后者改 IDEA 的-Xmx没用，得改 Gradle 或 Maven 的参数。

第三，全局搜索、重构、代码补全出现明显卡顿，且 CPU 占用并不高。CPU 不高但操作迟钝，典型特征就是 GC 在反复干活，世界都停下来等它。

反过来，如果卡顿发生时 CPU 或者磁盘占用很高，那多半是索引、扫描或者磁盘 I/O 的问题，改内存属于找错科室。我一般会先看一眼是不是正在进行 "Indexing" 或者 "Scanning files to index"，是的话先等它跑完再说。

1.3 这些卡顿改内存也救不了

有几个场景我必须点出来，免得你调完参数觉得"这方法没用"。

一是首次打开大项目。索引阶段是 CPU 和磁盘密集型的，堆内存再大也快不了多少，反而因为堆大、GC 周期长，偶尔还会更慢一点。

二是插件在 UI 线程上做了阻塞操作。这种情况内存曲线很平稳，就是点一下卡一下。排查方法是禁用插件二分法：先全禁，再一半一半往回开。

三是机械硬盘或者被杀软实时扫描拖慢。索引读写几万个文件，磁盘和杀软的干扰比内存参数影响大得多。

四是系统已经在换页。物理内存被占满，操作系统开始把内存页往磁盘挪，这时候的表现是整机都卡，不只是 IDEA。这种情况下加-Xmx是雪上加霜，正确做法是关掉别的吃内存程序，或者加物理内存。

2. 该给多少：一份可以直接对照的内存档位表

数值定多少，是这个问题里最容易被拍脑袋决定的部分。有人张口就是"越大越好，直接拉满"，也有人保守到只敢给 1GB。这两种都不太对。合理的做法是：先看清物理内存的余量，再按项目规模选档，最后给系统和其他程序留够活路。

2.1 先量一下物理内存和当前余量

这一步听着像废话，但我真的见过有人在一台 8GB 的办公本上把-Xmx设成 8192m，然后抱怨 IDEA 启动不了。度量方式很朴素：

Windows 上直接打开任务管理器，看"性能"标签页里的内存总量和当前可用量；也可以在 PowerShell 里跑Get-CimInstance Win32_OperatingSystem | Select-Object TotalVisibleMemorySize, FreePhysicalMemory。macOS 上用vm_stat或者活动监视器看"内存压力"曲线。Linux 上free -h最快，重点看 available 那一列而不是 free。

除了 IDEA，还要盘点同时跑着的吃内存大户：浏览器（尤其是开几十个标签页的）、Docker Desktop、数据库服务、另一个 IDE、模拟器。这些加起来经常能吃掉 8GB 以上。IDEA 的-Xmx应该是在这些之外还能分到的份额，而不是物理内存总量的一大块。

顺便回答一个被问得特别多的问题：虚拟内存（Windows 的页面文件、Linux/macOS 的交换区）设多大合适？我的建议是保持系统托管，Windows 上如果一定要手动设，给物理内存的 1 到 1.5 倍是个稳妥区间。不要为了"给 IDEA 腾地方"把页面文件关掉，一旦物理内存打满，没有页面文件兜底就是进程直接崩，而不是慢一点。

2.2 按物理内存和项目规模的推荐档位

下面这张表是我自己在用的参考值，数值取 512 的整数倍，方便记忆也方便心算。前提是同一台机器上还跑着浏览器和其他日常程序。

有一条经验公式可以拿来兜底：-Xmx不要超过物理内存的四分之一到三分之一。16GB 的机器给 4GB，32GB 的机器给 8GB，基本都能落在安全区间。如果项目特别大、索引本身就占 1GB 以上，可以在公式结果上再加 1GB 到 2GB，但要同步确认系统余量。

社区版有个小差别值得一提：社区版没有完整版里那些数据库工具、框架支持之类的重子系统，同等规模工程下的实际内存占用通常略低一些，所以参数可以相对保守一档，16GB 机器给 3072m 往往就够了，不必强求和完整版一致。

2.3 为什么不是越大越好：三个反直觉的代价

"内存给大点总没坏处"这个直觉在这里会翻车，原因有三。

第一，堆越大，单次 GC 的停顿越长。G1 回收器把堆切成很多 region，堆从 2GB 涨到 16GB，region 数量和管理开销同步上涨，并发标记周期里要扫描的对象更多，Full GC 一旦发生，停顿从几十毫秒变成几秒都有可能。交互式应用最怕的就是这种长停顿，手一抖输入的命令就丢了。

第二，堆越大，启动和预热越慢。如果-Xms也跟着设得很大，JVM 启动阶段就要向操作系统申请并触碰这些内存，冷启动时间会明显变长。我的习惯是-Xms保持在 512m 到 1g 之间，让 JVM 自己按需扩。

第三，超过物理内存就直接触发换页。这是最惨的一种情况：-Xmx设成 16g，物理内存只有 16g，堆真涨到 14g 的时候系统开始疯狂换页，整个操作系统的响应速度断崖式下跌，比内存不足的时候还难受。而且这种卡顿的现象是整机性的，很多人排查半天都想不到是内存参数设太大导致的。

还有一个附带代价：如果你开了-XX:+HeapDumpOnOutOfMemoryError，堆越大，OOM 时生成的堆转储文件越大，分析起来越费劲，磁盘也可能被一个几十 GB 的 dump 文件瞬间塞满。

3. 三种改法的完整路径与适用场景

改 IDEA 内存有三条路：图形界面的快捷入口、用户级自定义 VM 选项文件、安装目录下的默认配置文件。三条路都能到终点，但稳定性和持久性差得远。我建议新手先从图形界面熟悉概念，长期使用一定转到自定义 VM 选项文件。

3.1 Help 菜单里的 Change Memory Settings：最快但有边界

路径是 Help → Change Memory Settings，弹出一个带数字输入框的对话框，填完点 Save and Restart 就会重启 IDE 生效。这个入口是官方给的"傻瓜通道"，写进去的值会被保存到用户级自定义 VM 选项文件里，本质上和手动编辑那个文件是一回事。

它方便，但我不建议长期依赖，两个原因：一是它能表达的只有-Xmx一个参数，代码缓存、GC 选择这些一概管不了；二是数值偏大时它会给出警告提示，因为它默认按"小于物理内存一定比例"来把关，而这个把关逻辑有时比实际需求更保守。所以我的做法是：用它快速试一个值，确认有效之后，直接转到下面这种方式做精细调整。

注意：任何修改-Xmx的操作都需要重启 IDE 才会生效，热改是做不到的。改完不重启然后说"没用"，是最常见的乌龙。

3.2 编辑自定义 VM 选项文件：我唯一推荐的长期方案

路径是 Help → Edit Custom VM Options。第一次点击时 IDEA 会问要不要创建一个文件，选创建，它会用系统默认程序打开这个文件。这个文件的位置就是用户配置目录，各平台大致如下：

• Windows：%APPDATA%\JetBrains\IntelliJIdea<版本号>\idea64.exe.vmoptions
• macOS：~/Library/Application Support/JetBrains/IntelliJIdea<版本号>/idea.vmoptions
• Linux：~/.config/JetBrains/IntelliJIdea<版本号>/idea64.vmoptions

版本号目录名会随 IDE 版本变化，所以别手敲路径，直接用菜单打开，这是最不容易出错的方式。文件是纯文本，一行一个参数，直接改数值、加参数即可。

这里有一个非常关键但经常被忽略的点：当用户级自定义文件存在时，IDE 通常会用它替代安装目录里的默认文件，而不是合并。不同版本和平台的行为历史上略有差异，所以最稳妥的做法是——打开安装目录下的默认 vmoptions（Windows 是bin\idea64.exe.vmoptions，macOS 是Contents/bin/idea.vmoptions，Linux 是bin/idea64.vmoptions），把里面的内容整段复制到你的自定义文件里，然后再改-Xmx。这样无论"替代"还是"合并"，结果都不会缺参数。

改完之后用 Help → Edit Custom VM Options 再打开一次确认内容，然后重启。重启后在 Help → About 里能看到当前的运行时信息，配合下一节的命令行验证，就能百分百确认生效。

3.3 直接改安装目录的默认文件：不推荐，但要知道为什么

很多人第一步就是在安装目录的bin文件夹里找到idea64.exe.vmoptions，改完也确实生效了。问题出在后续：升级 IDE 会覆盖这个文件，你调好的参数在一次版本更新后无声无息地消失了。更麻烦的是，如果同时存在用户级自定义文件，你改的这个默认文件可能根本不生效，于是你反复修改、反复重启、反复疑惑。

我的建议是把安装目录的那个文件当作"参考副本"看待——用来看默认值长什么样，用来抄进自定义文件，但不要把它当成长期生效的阵地。

再补一个容易踩的细节：dos 环境变量IDEA_VM_OPTIONS可以指定一个额外的 vmoptions 文件路径，有些人的开发环境是脚本批量配的，这个变量被设置过但自己不知道。如果发现无论如何改都不生效，用echo %IDEA_VM_OPTIONS%（Windows）或者echo $IDEA_VM_OPTIONS（Linux/macOS）看一眼，很可能答案就在这儿。

3.4 一份可以直接抄的参数模板

下面这份模板我用了很久，适配 16GB 到 32GB 内存的机器，主要跑 Java/Kotlin 后端工程。你可以整段替换自定义 VM 选项文件的内容，然后按需调整两个数值。

-Xms512m -Xmx4096m -XX:ReservedCodeCacheSize=1024m -XX:+UseG1GC -XX:SoftRefLRUPolicyMSPerMB=50 -XX:CICompilerCount=2 -XX:+HeapDumpOnOutOfMemoryError -XX:-OmitStackTraceInFastThrow -ea -Dsun.io.useCanonCaches=false -Djdk.attach.allowAttachSelf=true -Dfile.encoding=UTF-8

逐条解释一下我为什么这么写，这样你改的时候心里有数：

-Xmx4096m是主角，16GB 机器上给 4GB 是稳妥值，32GB 机器可以改到 6144m 或 8192m。单位写m或g都可以，千万不要省略单位，-Xmx4096会被理解成 4096 字节，直接启动失败。

-Xms512m是初始堆。我故意不设成和-Xmx相等，就是为了缩短冷启动时间，代价是运行期间堆会扩容一次，对交互式使用完全无感。

-XX:ReservedCodeCacheSize=1024m是代码缓存。默认值一般在 240m 到 512m 之间，重插件、多语言混编的工程容易把它填满，一旦填满 JIT 会停止编译，性能肉眼可见地掉。给到 1GB 足够，再往上加基本没有收益，反而拉长缓存清理的时间。

-XX:+UseG1GC是回收器选择。近年的版本默认就是 G1，显式写出来是为了防止某些启动脚本或环境变量把它覆盖掉，属于"写明白心里踏实"。

-XX:SoftRefLRUPolicyMSPerMB=50关系到软引用对象的存活时间。IDEA 的索引用了大量软引用，这个值调小会让软引用更快被回收，堆压力小但索引可能被反复重建；调大则相反。50 是个折中值，也是 JetBrains 系产品常见的配置。

-XX:CICompilerCount=2限制 JIT 编译线程数，减少编译线程和其他工作线程抢 CPU，对启动阶段有帮助。

-XX:+HeapDumpOnOutOfMemoryError让 OOM 时自动落盘堆转储，出问题时能拿证据分析，代价是可能占磁盘空间，记得定期清理。

最后提醒两个格式禁忌：文件里不能用全角字符（全角空格、中文标点都可能让 JVM 解析失败），每行末尾不要留多余空格，一行只写一个参数。保存时用 UTF-8 无 BOM 编码，避免出现莫名其妙的A fatal exception has occurred启动错误。

4. 大项目专属：IDE 堆之外还有几块内存要管

把 IDEA 主进程的-Xmx调好，只解决了一半问题。真正的大型工程里，同时跑着的还有好几套独立的 JVM：Gradle 守护进程、Kotlin 编译守护进程、Maven 进程。它们各自有自己的堆上限，加起来吃掉的物理内存经常比 IDEA 本体还多。总账不算清，调优就是按下葫芦浮起瓢。

4.1 构建进程的堆：Gradle、Kotlin、Maven 分别怎么设

Gradle 项目的参数写在项目根目录的gradle.properties里：

org.gradle.jvmargs=-Xmx4096m -XX:MaxMetaspaceSize=1024m -Dfile.encoding=UTF-8 org.gradle.daemon=true org.gradle.parallel=true

org.gradle.jvmargs控制守护进程的堆，默认值偏小，大型多模块工程经常在构建阶段报 OOM 或者 GC 卡死。这里给 4GB 是我在 32GB 机器上的常用值，如果 IDEA 那边也给了 8GB，两个进程同时活跃时就会吃掉 12GB，所以两边要一起规划。

Kotlin 编译守护进程有独立参数，同样写在gradle.properties：

kotlin.daemon.jvmargs=-Xmx2048m

Kotlin 工程如果出现编译阶段的"内存不足"，十有八九是这里没调。注意这份参数和 Gradle 守护进程的是两份内存，不是共享的。

Maven 项目在 Settings → Build Tools → Maven → Runner 里勾选 VM options，填入-Xmx2048m；命令行构建则通过环境变量MAVEN_OPTS设置。两种场景的参数是分开的，改了一个不代表另一个也改了。

有一点必须强调：这些进程的-Xmx是各自独立的上限，不是总额。一次全量构建时，IDEA 主进程 4GB + Gradle 守护 4GB + Kotlin 守护 2GB 同时在线，物理内存要有 10GB 以上的余量才稳。这也是为什么我一再强调-Xmx要按物理内存总量的比例来定，而不是只看 IDE 一个进程。

4.2 索引与缓存：把负担从堆里挪出去

IDEA 的索引结构常驻在堆里，大型工程光索引就能占几百 MB 到 1GB 以上，这是堆内存消耗的大头之一。能做两件事来缓解。

一是定期做缓存清理。走 File → Invalidate Caches，勾选清理文件和标记，重启后重新索引。注意这是一把双刃剑：清理之后索引重建要花时间，如果你只是普通的一天工作，没必要天天清。我一般在升级 IDE 版本、切换分支导致索引错乱、或者补全明显不准的时候才做。

二是把索引数据放到更快的盘上。索引文件本身写在系统目录（system path）里，不占堆但严重影响速度。可以在自定义的idea.properties里通过idea.system.path把它挪到 SSD 上。这一步不改变内存占用，但对整体流畅度的提升往往比调-Xmx还明显，尤其是那些把项目放在机械盘上的老机器。

4.3 插件与外部工具：看不见的内存黑洞

插件是内存消耗里最难量化的一块。AI 助手类插件、数据库工具、Docker 和 WSL 集成、语言服务器客户端，这些插件要么在 IDE 堆里塞对象，要么在后台起独立的 JVM 或进程。我遇到过最夸张的一次是某个插件起了三个后台进程，加起来吃了 2GB，禁用之后整机都轻快了。

排查方法用二分法：Help → Diagnostic Tools → Show Memory Indicator 先看基线占用，然后 Settings → Plugins 里先禁用一半，重启观察，再逐步缩小范围。定位到具体插件之后，能换轻量替代的就换，不能换的就要在-Xmx上给它留出空间。

外部工具同理。终端里跑的本地服务、数据库、消息队列，都是独立进程。这些不归 IDE 管，但它们和 IDE 抢物理内存。所以"给 IDEA 多分点"这件事，本质上是在做系统级的内存预算，不是改一个数字那么简单。

4.4 GC 选择的取舍：什么时候值得换 ZGC

G1 在绝大多数场景下都是够用的，我不建议一上来就折腾回收器。只有当堆 ≥ 8GB，并且你在日志里确实观察到单次 GC 停顿超过一秒、操作有明显顿挫感的时候，才值得考虑换成 ZGC。

ZGC 的特点是停顿时间和堆大小基本脱钩，代价是更高的内存开销和更多的 CPU 消耗，而且需要较新的运行时支持。在小堆上换 ZGC 属于纯亏本买卖：省不下停顿，还多吃内存。我的优先级顺序是：先把堆调到合适大小，再检查是不是插件问题，最后才考虑换回收器。G1 本身也可以通过-XX:MaxGCPauseMillis调整目标停顿，但默认值已经是经过调优的，乱动经常适得其反。

如果实在想榨一点性能，可以试试给 G1 开字符串去重-XX:+UseStringDeduplication，IDE 场景里重复字符串不少，能看到一点收益，代价是额外的 GC 计算开销。这是可选项，不是必选项，加之前先做一次基线对比，加了没改善就撤掉。

5. 改完怎么验证：三种手段确认参数真的生效

改完参数重启，看到 IDE 正常打开，不代表参数生效了。命令行参数这种事，肉眼不可见，唯一可靠的办法是让 JVM 自己说出来。

5.1 最硬的办法：用 jps 打印真实启动参数

JBR 自带一套 JDK 工具，jps就在里面。用它打印 IDEA 进程的完整启动参数，一眼就能看到-Xmx到底是什么值。

Windows 上的命令大致是这样（进到 IDE 安装目录的jbr\bin下执行）：

jps.exe -lvm | findstr /i idea

Linux 或 macOS 上：

/path/to/ide/jbr/bin/jps -lvm | grep -i idea

输出里会有一长串启动参数，找-Xmx那一段。如果显示的是你设置的值，说明生效了；如果还是默认值，那就是改的位置不对，或者被更高优先级的配置覆盖了。

这个方法之所以最可靠，是因为它读的是进程真正运行时的参数，不依赖任何配置文件的读取顺序推测。我排查"改了没用"这类问题时，永远第一步就跑它。

5.2 状态栏内存指示器怎么读

开启位置在不同版本里略有差异，通常在状态栏右键的菜单里，或者走 Help → Diagnostic Tools → Show Memory Indicator。开启后右下角会出现一个类似1.2G of 4G的显示。

读法上有几个要点。显示的数字只反映堆内使用量，不含元空间和堆外内存，所以任务管理器里的数字永远比它大。判断紧张与否看稳态水位，而不是瞬时峰值——打开一个超大文件瞬间冲到 90% 很正常，几秒后回落就没事。真正要警惕的是"低强度操作下也长期维持在 85% 以上"，那说明确实该加。

还有一个使用细节：指示器上的数字不会实时刷新，通常有几十秒的更新间隔，别盯着它做精细判断。

5.3 一次真实的调优记录对比

光讲方法有点干，我把手头一个 32GB 内存、多模块 Kotlin 后端工程的调整前后数据放上来。数字是我自己机器上的观测，你的硬件和工程结构不同，绝对值会有差异，看趋势就好。

有意思的是启动时间的改善很小，因为启动阶段主要瓶颈是索引和磁盘 I/O，跟堆大小关系不大。真正拉开差距的是全局搜索和长时间工作后的稳定性——那才是堆不够的典型受害场景。这也印证了前面那句话：改内存解决的是堆压力问题，不是所有慢的问题。

6. 踩坑实录：改内存最容易翻车的几个地方

这部分是我这些年攒下来的"病历本"，每一条都对应一次真实的翻车。

6.1 启动不起来：报错信息直接对应病因

Error occurred during initialization of VM加上Could not reserve enough space for object heap：-Xmx设得超过了可用内存或连续地址空间。先把值砍一半重启试试。如果很小的值也报这个错，检查是不是在用 32 位运行时，32 位进程的堆上限远低于你的预期。

Error: Could not create the Java Virtual Machine：文件内容有语法问题。常见元凶是全角空格、中文引号、参数写成-Xmx4GB这种非法单位、或者一行里塞了两个参数。还有一种隐蔽情况是文件被编辑器存成了带 BOM 的 UTF-8，JVM 读到开头的字节就懵了。

改完直接卡在启动画面不动：多半是-Xms设得和-Xmx一样大，而且值很大。JVM 启动时要一次性提交这么多内存，物理内存不够就开始换页，表现就是卡死。把-Xms降下来。

提示：任何一次修改之前，先把原文件复制一份存成.bak。启动失败时把备份文件覆盖回去就能立刻恢复，比对着报错猜快十倍。

6.2 改了完全没生效的四种原因

第一种，改的是安装目录里的默认文件，但用户级自定义文件已经存在并覆盖了它。验证方法就是前面说的jps -lvm。

第二种，环境变量指向了别处。IDEA_VM_OPTIONS如果被设置过，它的优先级通常高于你的自定义文件。查一下这个变量。

第三种，多版本装了多个 IDE，改错了目录。用 Toolbox 管理的话，不同大版本有各自的配置目录，IntelliJIdea2023.3和IntelliJIdea2024.1是两个完全独立的文件夹。改之前先确认自己在哪个版本里点的菜单。

第四种，参数拼错了但被静默忽略。如果文件里有-XX:+IgnoreUnrecognizedVMOptions，那些写错的-XX开头的参数不会报错，直接被丢掉。这也是我为什么总用jps -lvm做最终确认——文件里写了什么不重要，进程实际用什么才重要。

6.3 参数优先级：心里有个顺序就不慌

综合我遇到的情况，参数生效优先级从高到低大致是：环境变量指定的 vmoptions 文件 → 用户级自定义 vmoptions → 安装目录默认 vmoptions。这是一个经验性总结，不同版本和平台的历史行为有过变化，所以不要死记硬背这个顺序，用jps验证才是唯一标准答案。

同一台机器上开多个 IDE 窗口时，每个窗口是自己的进程，各自读各自的参数，但配置目录如果被指定成同一个，参数就是共享的。想让不同项目用不同的内存配置，可以在启动脚本里通过命令行参数覆盖，这只是少数人的做法，日常使用没有这个必要。

6.4 我不推荐的几种做法

把-Xmx设成物理内存的 80% 以上。系统、浏览器、构建进程都要吃饭，IDE 吃掉大头的结果就是整机一起卡，得不偿失。

为了"省内存"禁用所有插件。这是治标不治本，你把功能砍光了当然占内存少，但 IDE 的意义也就没了。正确做法是定位到具体吃内存的插件，针对性处理。

调大-Xss。有人说栈大了不报 StackOverflowError，问题是 IDE 里几乎不会遇到这个错，调大只是让每个线程多吃内存。

盲目换并行回收器。有些老教程建议-XX:+UseParallelGC，那套参数是给吞吐优先的服务端场景写的，交互式桌面应用要的是低停顿，换过去反而更卡。

用第三方的"优化脚本"一键改配置。这类脚本经常顺手改一堆你没要求的参数，出了问题都不知道从哪查起。自己看懂、自己改，出问题才知道回退哪一行。

最后分享一个我自己的固定习惯：把-Xmx设成物理内存的四分之一，然后向上取整到 512 的整数倍，比如 16GB 机器取 4096m，32GB 机器取 8192m，但会减去刚好在跑的那几套构建进程的量。改完之后不急着下结论，先用一周，中间看一眼内存指示器的稳态水位，低于 60% 说明还有余量可以留白，长期贴在 85% 以上就再加一档。这套土办法不优雅，但在十几台机器上都没翻过车——真正省事的配置，永远是留了余量的那一档。