13、Gradle Daemon：Daemon原理、开启与关闭、性能调优、常见问题排查

聊到 Gradle 构建速度，Daemon 绝对是个绕不开的话题。我记得刚接触 Gradle 那会儿，每次跑构建都要等十几秒，心里那个急啊。后来才知道，原来有个叫 Daemon 的守护进程一直在后台等着我。说白了，它就是 Gradle 的「常驻工人」——不用每次干活前都重新招人、培训、热身，直接上手就干。

Daemon 的工作原理

Gradle Daemon 本质上是一个长期运行的后台 JVM 进程。你第一次运行 gradle build 时，它会启动一个 Daemon 进程。这个进程会加载项目配置、缓存依赖、预热类加载器。等你第二次再跑构建时，它直接复用这些资源。

为什么会快这么多？我打个比方：

  • 没有 Daemon：每次构建 = 启动 JVM + 加载 Gradle 运行时 + 解析构建脚本 + 执行任务。相当于每次做饭都要先生火、洗锅、切菜。
  • 有 Daemon：JVM 已经跑着，类已经加载好，构建脚本的缓存还在。相当于火已经生好了，锅也热了，直接下锅炒菜。

我个人习惯把 Daemon 理解成一个「热启动」机制。它把构建过程中最耗时的初始化阶段（JVM 启动、类加载、脚本解析）提前完成，后续的构建只需要增量执行任务即可。

核心要点：Daemon 不是加速单个任务的执行，而是消除每次构建的「冷启动」开销。对于大型项目，这个开销可能占到总构建时间的 30%-50%。

下面这张图展示了 Daemon 的工作流程：

Gradle Daemon 工作流程 第一次构建请求 启动 Daemon 进程 (JVM + 类加载 + 脚本解析) 执行构建任务 (编译、测试、打包) ✓ 第二次构建请求 复用已有 Daemon (跳过初始化，直接执行) 增量执行任务 (仅处理变更部分) ✓ 对比：有 Daemon vs 无 Daemon ❌ 无 Daemon：启动 JVM(3s) + 加载类(5s) + 解析脚本(4s) + 执行任务(8s) = 20s ✅ 有 Daemon：跳过初始化(0s) + 增量执行任务(3s) = 3s 注：以上时间为示例，实际耗时取决于项目规模和机器配置

开启与关闭 Daemon

Gradle 从 3.0 版本开始默认开启了 Daemon。你基本不用手动配置。但有些场景下，你可能需要显式控制它。

开启 Daemon

最直接的方式是在 gradle.properties 中设置：

# 开启 Daemon（默认就是 true）
org.gradle.daemon=true

也可以在命令行临时启用：

gradle build --daemon

我个人习惯在项目的 gradle.properties 里统一配置。这样团队所有成员都用同样的设置，避免出现「我本地能跑，你那边不行」的尴尬。

关闭 Daemon

有些 CI 环境或者内存受限的服务器上，你可能想关掉 Daemon：

# 关闭 Daemon
org.gradle.daemon=false

命令行方式：

gradle build --no-daemon

注意：关闭 Daemon 后，每次构建都会冷启动。对于大型项目，构建时间可能增加 2-3 倍。我建议只在以下情况关闭：

  • CI 环境每次构建使用独立的容器/虚拟机
  • 内存极度紧张（比如只有 512MB 可用内存）
  • 调试 Daemon 相关问题时临时关闭

停止 Daemon

有时候 Daemon 占用了太多内存，或者你怀疑它出了问题，可以手动停止：

gradle --stop

这个命令会停止所有 Gradle Daemon 进程。下次构建时会自动启动一个新的。

性能调优

Daemon 虽然好用，但默认配置不一定适合你的项目。我调优过不少项目，总结出几个关键参数。

JVM 参数调整

Daemon 运行在 JVM 上，JVM 参数直接影响构建性能。在 gradle.properties 中配置：

# 设置 Daemon 的 JVM 参数
org.gradle.jvmargs=-Xmx2048m -XX:MaxMetaspaceSize=512m -XX:+HeapDumpOnOutOfMemoryError

几个关键参数说明：

参数 说明 建议值
-Xmx 最大堆内存 项目大小 × 1.5，一般 2GB-8GB
-XX:MaxMetaspaceSize 元空间上限（类信息） 256MB-512MB
-XX:+HeapDumpOnOutOfMemoryError OOM 时自动 dump 堆 建议开启，方便排查

我的经验：对于中型项目（50-100 个模块），-Xmx2048m 基本够用。大型项目（200+ 模块）建议给到 4GB 以上。我曾经遇到一个项目，默认 512MB 堆内存，构建到一半就 OOM 了。调大到 4GB 后，构建时间从 15 分钟降到了 6 分钟。

并行构建

Daemon 配合并行构建，效果更佳：

# 开启并行构建
org.gradle.parallel=true

# 设置并行线程数（默认是 CPU 核心数）
org.gradle.workers.max=4

并行构建让 Daemon 同时处理多个任务。比如编译模块 A 的同时，可以并行编译模块 B。但要注意，线程数不是越多越好。我一般设置为 CPU 核心数减 1，留一个核心给系统和其他进程。

Daemon 存活时间

Daemon 默认会在空闲 3 小时后自动停止。你可以调整这个时间：

# 设置空闲超时时间（单位：分钟）
org.gradle.daemon.idletimeout=60

我个人习惯设置 30 分钟。太短的话，离开一会儿回来又要重新启动 Daemon。太长的话，Daemon 一直占着内存不释放。

常见问题排查

用了这么多年 Gradle，Daemon 相关的问题没少遇到。下面几个是最常见的。

问题一：Daemon 内存溢出（OOM）

现象：构建过程中报 OutOfMemoryError，或者构建突然卡死。

排查步骤：

  1. 检查 gradle.properties 中的 -Xmx 设置是否合理
  2. 查看 Daemon 的堆转储文件（如果开启了 HeapDumpOnOutOfMemoryError）
  3. 用 jvisualvm 或 jconsole 分析堆内存使用情况

解决方案：

  • 增大 -Xmx 值
  • 减少并行线程数
  • 检查是否有内存泄漏的插件或任务

我曾经遇到过一个诡异的问题：某个自定义插件每次构建都会加载一个巨大的 XML 文件到内存中，而且不释放。构建 3-4 次后 Daemon 就 OOM 了。排查了整整一天才发现是插件的问题。所以，如果你遇到反复 OOM，不妨检查一下自定义插件和脚本。

问题二：Daemon 版本冲突

现象：构建时提示 Daemon is running with a different version。

原因：你升级了 Gradle 版本，但旧的 Daemon 还在运行。新旧版本不兼容。

解决方案：

# 停止所有 Daemon
gradle --stop

# 然后重新构建，会自动启动新版本的 Daemon
gradle build

问题三：Daemon 启动失败

现象：构建卡在 Starting a Gradle Daemon 很久，然后报错。

排查步骤：

  1. 检查系统资源（内存、CPU）是否充足
  2. 查看 Daemon 日志：~/.gradle/daemon/<版本号>/daemon-<pid>.log
  3. 尝试手动启动 Daemon 看具体报错

解决方案：

  • 释放系统资源，关闭不必要的程序
  • 调整 JVM 参数，降低内存要求
  • 如果日志显示端口被占用，可以杀掉占用进程或重启系统

问题四：Daemon 占用磁盘空间

现象：~/.gradle 目录越来越大，尤其是 daemon 子目录。

原因：每次升级 Gradle 版本，旧的 Daemon 日志和临时文件不会自动清理。

解决方案：

# 手动清理旧版本的 Daemon 文件
rm -rf ~/.gradle/daemon/<旧版本号>

或者直接清理整个 daemon 目录（当前正在运行的 Daemon 会保留）：

gradle --stop
rm -rf ~/.gradle/daemon

小技巧：我每个月会跑一次 gradle --stop 然后清理 ~/.gradle/daemon 目录。顺便也清理一下 ~/.gradle/caches 中的旧缓存。这样能省出好几个 GB 的磁盘空间。

总结一下

Gradle Daemon 是个好东西，但也不是银弹。用好了，构建速度翻倍。用不好，反而可能引入各种问题。我的建议是：

  • 默认开启 Daemon，除非有特殊原因
  • 根据项目规模合理配置 JVM 参数
  • 遇到问题先看 Daemon 日志，别盲目重装
  • 定期清理旧版本的 Daemon 文件

嗯，Daemon 这块就聊到这儿。记住一点：它只是个工具，理解它的原理才能用好它。

公众号：蓝海资料掘金营，微信 deep3321

← 上一章 📖 返回目录 下一章 →