报错含com.sun.tools.javac等类名时，需调高shared heap size而非idea.vmoptions；若oom为metaspace，应取消run配置中“provided依赖加入类路径”并设-xx:maxmetaspacesize；gradle/maven需单独配置其jvm参数；最后须清理残留java进程及缓存。
直接改 idea.vmoptions 不一定能解决问题，因为 IDEA 里有至少 4 个独立内存区域，各自溢出时表现一样（都是 java.lang.OutOfMemoryError），但原因和修复点完全不同。
改哪里？先看报错堆栈里带不带 com.sun.tools.javac
如果错误日志里出现 com.sun.tools.javac、Resolve、Attr 等类名，说明是编译器进程崩了，不是 IDEA 主界面或你的服务崩了。这时候改 idea.vmoptions 没用——它只管 IDEA 自身 JVM，不管 javac 编译器。
- 必须去
Settings → Build, Execution, Deployment → Compiler调整Shared heap size，建议从默认700改成2048或更高 - 这个值改完立即生效，无需重启 IDEA
- 若同时用 Lombok 或 MapStruct，这类注解处理器会显著增加编译内存压力，
Shared heap size得再往上加
Run 配置里 -Xmx 设了也没用？检查是否勾选了 provided 依赖
很多 Spring Boot 多模块项目在 Run 配置里设了 -Xmx6g 还是启动就崩，报 OutOfMemoryError: Metaspace，大概率是因为勾选了 Add dependencies with "provided" scope to classpath。
- 这个选项会把
provided的 jar（比如spring-boot-starter-tomcat）也加载进运行时类路径，白占几百 MB 元空间 - 务必取消勾选，再配合
-XX:MaxMetaspaceSize=1536m才能稳住 -
-Xms和-Xmx建议设成相同值（如-Xms4g -Xmx4g），避免运行中频繁扩容触发 GC 飙升
Gradle/Maven 构建卡在 resolve dependencies？别只盯 IDEA 内存
构建工具的 Daemon 进程完全独立于 IDEA，它用的是自己那套 JVM 参数。你在 idea.vmoptions 里加了 -Xmx4g，对 Gradle 守护进程毫无影响。
- Gradle：编辑
~/.gradle/gradle.properties，确保有org.gradle.jvmargs=-Xmx4096m -XX:MaxMetaspaceSize=512m - Maven：在
$M2_HOME/conf/maven.config或项目根目录.mvn/jvm.config里写入-Xmx4096m - 改完立刻执行
./gradlew --stop或mvn -Dmaven.clean=true clean，否则旧 Daemon 还在用老参数跑
改完还是崩？先杀光残留 Java 进程再试
Windows 上常见现象：IDEA 关了，但后台还挂着几个 java.exe，它们占着端口、锁着文件、还偷偷用着旧内存配置。新启动的 IDEA 或构建任务一上来就撞上资源冲突。
- PowerShell 一行清空：
Get-Process java | Stop-Process -Force - 再删掉项目下
target/或build/目录，避免缓存污染 - 最后执行
File → Invalidate Caches and Restart → Just Restart，不要选 “Clear file system cache”——那个会删掉索引，反而拖慢后续启动
真正麻烦的从来不是参数填多少，而是同一台机器上 IDEA 主进程、编译器子进程、Run 配置进程、Gradle Daemon 进程这四套 JVM 同时在跑，每套都可能因不同原因溢出，而错误日志长得几乎一样。
