解决mac上intellij idea频繁oom需同步调整三处内存：一、ide自身jvm（help→edit custom vm options设-xms4g -xmx8g，m芯片保留-xx:+useg1gc）；二、compiler中shared heap size调至2048mb以上；三、gradle.properties配org.gradle.jvmargs=-xmx4096m并执行./gradlew --stop。
Mac 上 IntelliJ IDEA 频繁报 java.lang.OutOfMemoryError: Java heap space 或 OutOfMemoryError: Metaspace，不是堆设得不够大，而是三个地方的内存配置没对齐：IDE 自身 JVM、编译器进程、项目构建工具（Gradle/Maven）——漏改任何一个，OOM 就会换着花样出现。
怎么改 IDEA 自身的 JVM 内存（idea.vmoptions）
关键不是盲目加 -Xmx，而是匹配你的物理内存和芯片类型：
- 用
Help → Edit Custom VM Options…打开用户级配置文件（路径类似~/Library/Application Support/JetBrains/IntelliJIdea2023.3/idea.vmoptions），别动安装目录下的默认文件 - Mac 16GB 内存建议设
-Xms4g -Xmx8g；M 系列芯片必须保留-XX:+UseG1GC（ZGC 不稳定，官方不推荐） - 元空间不足就加
-XX:MaxMetaspaceSize=1024m，但别超过 1536m，否则反而触发 GC 恶性循环 - 避免写
-Xmx12g这类超限值——Mac 系统本身要吃 4–6GB，浏览器+Docker 常驻再占 3GB，IDEA 实际能稳用的顶多 8g
为什么改了 -Xmx 还编译崩？查 Compiler 设置
IDEA 编译器（javac/Kotlin）跑在独立 JVM 里，和主 IDE 进程内存完全隔离。你改了 idea.vmoptions，它根本看不见。
- 进
Preferences → Build, Execution, Deployment → Compiler - 把
Shared build process heap size (MB)从默认 700 改成2048或更高（大型 Spring Boot 多模块项目建议 3072） - 这个值改完立刻生效，不用重启 IDE，但下次 Build 才会用新内存
- 如果项目含大量 Lombok 或 MapStruct 注解处理器，堆太小会直接卡死在 “Compiling annotation processors” 阶段
Gradle 构建时 OOM？别只盯 IDEA，先看 gradle.properties
Gradle Daemon 是个常驻后台的独立 JVM 进程，IDEA 启动时它可能还在用旧配置跑着，导致编译/依赖解析阶段爆内存。
- 编辑
~/.gradle/gradle.properties，确保有这行：org.gradle.jvmargs=-Xmx4096m -XX:MaxMetaspaceSize=512m - 执行
./gradlew --stop杀掉所有旧 Daemon，再跑构建 - 如果项目根目录也有
gradle.properties，优先级高于用户级配置，记得同步改 - 用 Toolbox 安装的 IDEA，有时会缓存旧 Daemon 参数，强制退出 Toolbox 再重开一次更保险
容易被忽略的硬伤：插件和索引残留
内存参数全调对了，OOM 还是反复出现？大概率是插件或索引层出了问题，不是 JVM 层面的事。
-
Database Tools and SQL插件连着 200+ 张表自动加载元数据，光这一项就能吃掉 1.2GB 堆 —— 关掉 “Auto-connect on project load” - Lombok 插件版本和当前 IDEA 不兼容（比如 2023.3 用 Lombok 1.18.30），会导致注解处理卡死并假性内存泄漏
- 索引损坏不会报 OOM，但会让 GC 频繁扫描无效文件，表现为 “Free memory” 在状态栏狂跳却始终低于 10% —— 用
File → Repair IDE… → Rebuild project index强制重建 - 状态栏右键开启
Memory Indicator，观察实际使用曲线：如果 “Used” 长期贴着 “Max”，说明参数真不够；如果 “Used” 波动剧烈但 “Free” 始终 >30%，那问题在插件或代码逻辑
最麻烦的不是参数怎么填，而是三处内存（IDE 主进程、Compiler 子进程、Gradle Daemon）互相不感知，改完一处得清另一处的缓存，再验证第三处的日志输出。一个 OutOfMemoryError 报错背后，往往藏着三个不同进程的配置断层。
