学术入门做Java或Android开发的人，对Gradle构建卡顿应该都不陌生：CPU飙满、风扇狂转、构建日志卡在最后一行，运气好等几分钟过去，运气不好直接给你抛一个OutOfMemoryError。更恶心的是Gradle daemon悄悄崩掉，下一次构建又从头开始跑，进度条一点点爬，心态直接崩。很多人第一反应是去Help里把Android Studio的内存调大，结果调完之后发现该崩还是崩，因为真正干活的是Gradle daemon，不是IDE那个进程。
这篇文章就专门聊Gradle的内存配置优化，核心是org.gradle.jvmargs这组JVM参数。我会把参数逐个拆开讲清楚原理，给出不同规模项目的参考配置模板，整理常见的OOM报错定位思路，再补几个和内存配置配合起来效果更好的构建加速手段。无论你是单模块的小项目，还是几十个模块的大型工程，都能找到一套能直接抄的配置方案。目标只有一个：让你看完能动手改自己项目里的gradle.properties，并且知道每一行参数为什么这么写。
1. 先搞清楚Gradle的内存模型：不是调大Xmx就完事
1.1 daemon是什么，为什么构建时总有一个Java进程赖着不走
Gradle之所以常驻一个后台进程，是为了避免每次构建都重新启动JVM、重新加载插件和构建脚本。第一次执行gradlew时，Gradle会启动一个daemon进程，构建结束之后它并不退出，而是继续在后台等下一次任务。默认情况下，daemon空闲3小时后才会被回收。这个设计本身没问题，问题在于daemon所在JVM的内存参数直接影响整个构建的吞吐量。
你可以用一条命令看看自己机器上到底趴着多少个daemon：
bash复制./gradlew --status
# 或者直接看Java进程
jps -l | grep GradleDaemon
如果你同时跑过多个Gradle版本，或者改动过gradle.properties里的JVM参数，很可能发现有好几个daemon同时在内存里。每个Gradle版本的daemon是独立的，不同JVM参数的daemon也不会互相复用，旧daemon会占用内存直到超时回收。
理解了daemon的复用机制，你才能理解后面很多坑：为什么改了参数没生效、为什么构建时系统莫名多了几个Java进程、为什么内存明明给得很大还是卡。
1.2 堆内存只是第一层，Metaspace更容易被忽略
很多人对JVM内存调优的印象就是调-Xmx，以为最大堆内存给到4G、8G就万事大吉。但Gradle构建场景和普通Java应用不太一样，它会有海量的类加载：解析构建脚本、加载插件、创建任务对象、跑编译和字节码处理，这些类的元数据存放在Metaspace区域，也就是JDK8之后替代PermGen的那块内存。
堆内存存的是Java对象实例，Metaspace存的是类定义、方法元数据、常量池这些东西。默认情况下Metaspace上限很高，基本等同于物理内存可用量，但它不是无限的。一旦某个构建场景加载的类特别多，或者有插件存在类加载泄漏，Metaspace就会一路涨。所以调优时除了-Xmx，还需要关注-XX:MaxMetaspaceSize，给它一个明确上限，避免内存被悄悄吃光。堆内存不足，系统会报Java heap space；Metaspace不足，报的就是java.lang.OutOfMemoryError: Metaspace。
另外还有JIT编译产生的Code Cache、线程栈等堆外内存，这些在Gradle构建场景中一般不会成为瓶颈。我的建议是不要过度优化：你只需要把堆和Metaspace管好，90%的Gradle内存问题都能解决。
1.3 为什么调了Android Studio的内存，构建还是卡
这是最常见的认知误区。Android Studio本身是一个基于JVM的IDE，它也有自己的内存参数，在studio.vmoptions文件里配置，负责的是代码索引、编辑器、UI这些功能。而Gradle构建跑在独立的daemon JVM中，IDE的堆大小和构建进程没有直接关系。你给IDE分配8G内存，代码提示流畅了，但Gradle编译该OOM还是OOM。
在Android Studio里，你能通过Preferences搜索“Gradle JDK”看到当前构建用的Java版本，但这里的设置只决定daemon用哪个JVM，并不负责管理堆大小。真正控制daemon堆内存的地方，是项目根目录下gradle.properties中的org.gradle.jvmargs。记住这条界限：IDE内存管IDE，Gradle daemon内存管构建，两者别混着调。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。