根本原因是Daemon被挤掉或失效，而非配置未开启；常见于多项目/IDE并发构建、内存不足被杀、残留锁文件阻塞、或VSCode/Android Studio插件绕过配置拉起无约束Daemon。
为什么Gradle总在启动新Daemon而不是复用？
根本原因不是配置没开，而是守护进程被“挤掉”或“失效”了。Gradle Daemon按版本隔离（gradle-8.7 和 gradle-8.10 各自维护独立进程），但更常见的是：多个项目/IDE同时触发构建、内存不足被系统杀掉、残留锁文件阻塞新进程、或者 VSCode/Android Studio 的 Java 扩展绕过你的 gradle.properties 自行拉起无约束 Daemon。
如何让Daemon稳定复用不重启？
关键不是“开启”，而是“保活+匹配+隔离”。实操建议如下：
- 检查当前活跃 Daemon：
./gradlew --status—— 如果输出为空或只有旧版本，说明新构建没连上已有进程 - 确认 Gradle 版本一致性：不同子模块或 CI 脚本若混用
gradle wrapper和全局gradle命令，会触发多版本 Daemon 并存，互相不复用 - 禁用 IDE 的“自动拉起”行为：VSCode 中必须设置
redhat.java.jvmArgs（如"-Xmx512m"），否则它启动的 Daemon 不读~/.gradle/gradle.properties，且不显示在--status里 - 清理残留状态：删掉
~/.gradle/daemon/下所有子目录（尤其含pid或lock的），再执行pkill -f "Gradle Daemon"
org.gradle.daemon.maxConcurrency=1 真的有用吗？
有用，但只在特定场景下生效——它限制的是“同一 Gradle 版本下最多几个并发 Daemon 进程”，不是“只允许一个 Daemon”。如果你有 3 个模块并行构建（org.gradle.parallel=true），默认可能启 4 个 Daemon；设为 1 后，它们会排队复用同一个进程，避免内存爆炸。不过要注意：
- 该参数仅对 Gradle 7.6+ 生效，老版本忽略
- 设得太低（如
=1）会导致并行任务退化为串行，大项目反而更慢 - 真实推荐值：物理 CPU 核数 ÷ 2（例如 8 核设为
4），兼顾复用与吞吐
最常被忽略的内存陷阱
Daemon 复用失败，八成是因为 JVM 内存配置不当。不是“越大越好”，而是“够用且稳定”：
- 默认堆内存（
-Xmx）通常太小，大型项目构建中途 OOM，Daemon 异常退出后不再复用 - 但也不能盲目设高：比如给 16GB 内存机器配
-Xmx8g，空闲时仍占 300MB+，多个项目叠加直接拖垮系统 - 推荐写法（放在项目级
gradle.properties）：org.gradle.jvmargs=-Xmx2g -XX:MaxMetaspaceSize=512m -XX:+HeapDumpOnOutOfMemoryError - 验证是否生效：构建时加
--info，看日志里是否出现Starting daemon with JVM arguments及对应参数
真正难处理的，是那些不进 --status 列表、却在后台吃掉 1.5GB 内存的“孤儿 Daemon”——它们来自 IDE 插件，得从扩展配置里动手，不是改 gradle.properties 就能解决。
