第十九章. Gradle 守护进程

Chapter 19. The Gradle Daemon

19.1. 走进守护进程

19.1. Enter the daemon

Gradle 守护进程(有时也称为构建守护进程) 旨在改善 Gradle 的启动和执行时间。
The Gradle daemon (sometimes referred as the build daemon) aims to improve the startup and execution time of Gradle.

我们想到了几个关于守护进程非常有用的情形。对于一些工作流,用户会多次调用 Gradle 以执行少量相对较快的任务。例如:
We came up with several use cases where the daemon is very useful. For some workflows, the user invokes Gradle many times to execute a small number of relatively quick tasks. For example:

  • 当使用测试驱动开发时,单元测试会被执行多次。
    When using test driven development, where the unit tests are executed many times.
  • 当开发一个 web 应用程序中,应用程序会被组装多次。
    When developing a web application, where the application is assembled many times.
  • 当要了解一个构建能做什么时,gradle tasks 会被执行多次。
    When discovering what a build can do, where gradle tasks is executed a number of times.

对以上各种工作流来说,让调用 Gradle 的启动成本尽可能小是很重要的。
For above sorts of workflows, it is important that the startup cost of invoking Gradle is as small as possible.

此外,如果可以相对较快地建立 Gradle 模型,用户界面可以提供一些有趣的功能。例如,守护进程可能对以下情况有用:
In addition, user interfaces can provide some interesting features if the Gradle model can be built relatively quickly. For example, the daemon might be useful for following scenarios:

  • 在 IDE 中的内容帮助
    Content assistance in the IDE
  • 在 GUI 中的实时可视化构建
    Live visualisation of the build in a GUI
  • 在 CLI 中的 tab 键完成
    Tab completion in a CLI

一般来说,构建工具的敏捷行为总是方便的。如果你尝试在你的本地构建中使用守护进程的话,那么你将很难再回到 Gradle 的常规使用。
In general, snappy behavior of the build tool is always handy. If you try using the daemon for your local builds it's going to be hard for you to go back to regular use of Gradle.

Tooling API(请参阅《第62章,嵌入Gradle》)会始终使用守护进程。例如,如果没有守护进程,你就不能正式使用 Tooling API。这意味着无论你是在 Eclipse 中使用 STS Gradle 插件,还是在 Intellij IDEA 中使用 Gradle 支持,都已经使用了Gradle Daemon。
The Tooling API (see Chapter 62, Embedding Gradle) uses the daemon all the time, e.g. you cannot officially use the Tooling API without the daemon. This means that whenever you are using the STS Gradle plugin for Eclipse or the Gradle support in Intellij IDEA, you're already using the Gradle Daemon.

未来,该守护进程还会提供更多的功能:
In future the daemon will offer more features:

  • 敏捷的最新(up-to-date)检查:使用本地文件系统修改通知(例如,通过 jdk7 nio.2)预先执行 up-to-date 分析。
    Snappy up-to-date checks: use native file system change notifications (e.g. via jdk7 nio.2) to preemptively perform up-to-date analysis.
  • 甚至更快的构建:预先评估项目,以便在用户下一次调用 Gradle 时,模型就已准备就绪。
    Even faster builds: preemptively evaluate projects, so that the model is ready when the user next invokes Gradle.
  • 我们提到更快的构建了吗?守护进程可以预先下载依赖项或检查 snapshot 依赖的新版本。
    Did we mention faster builds? The daemon can potentially preemptively download dependencies or check for new versions of snapshot dependencies.
  • 使用可用于编译和测试的一个可复用过程池。例如,Groovy 和 Scala 的编译器都有很大的启动成本,构建守护进程可以维护已经加载了 Groovy 或 Scala 的进程。
    Utilize a pool of reusable processes available for compilation and testing. For example, both the Groovy and Scala compilers have a large startup cost. The build daemon could maintain a process with Groovy and/or Scala already loaded.
  • 预先执行某些任务,比如编译。更快的反馈。
    Preemptive execution of certain tasks, for example compilation. Quicker feedback.
  • 快速准确的 bash 的 tab 键完成。
    Fast and accurate bash tab completion.
  • Gradle 缓存的定期垃圾收集。
    Periodically garbage collect the Gradle caches.

19.2. 守护进程的重用和过期

19.2. Reusing and expiration of daemons

基本思想是,Gradle 命令会 fork 一个守护进程执行实际的构建。Gradle 命令的后续调用将重用守护进程,以避免启动开销。有时我们不能使用现有的守护进程,是因为它正忙或者它的 java 版本或 jvm 参数不同。关于何时会 fork 新的守护进程的具体细节,请阅读下面的专题。守护进程将在空闲 3 小时后自动失效。
The basic idea is that the Gradle command forks a daemon process, which performs the actual build. Subsequent invocations of the Gradle command will reuse the daemon, avoiding the startup costs. Sometimes we cannot use an existing daemon because it is busy or its java version or jvm arguments are different. For exact details on when exactly new daemon process is forked read the dedicated section below. The daemon process automatically expire after 3 hours of idle time.

以下是我们 fork 一个新的守护进程的所有情况:
Here're all situations in which we fork a new daemon process:

  • 如果该守护进程当前正忙于运行一些作业,则将启动一个全新的守护进程。
    If the daemon process is currently busy running some job, a brand new daemon process will be started.
  • 我们为每一个 java home 分配一个独立的守护进程。所以,即使有一些闲置的守护进程正在等待构建请求,但你碰巧用另一个 java home 运行构建,那么还是会 fork 一个全新的守护进程。
    We fork a separate daemon process per java home. So even if there is some idle daemon waiting for build requests but you happen to run build with a different java home then a brand new daemon will be forked.
  • 如果构建的 jvm 参数足够不同,我们也会 fork 一个单独的守护进程。例如,如果某个系统属性发生改变,我们不会 fork 一个新的守护进程。但是如果 -Xmx 内存设置或者一些基本的不可变的系统属性修改了(例如 file.encoding),那么就会 fork 新的守护进程。
    We fork a separate daemon process if the jvm arguments for the build are sufficiently different. For example we will not fork a new daemon if a some system property has changed. However if -Xmx memory setting change or some fundamental immutable system property changes (e.g. file.encoding) then new daemon will be forked.
  • 此刻,守护进程将与特定版本的 Gradle 结合在一起。这意味着即使某些守护进程闲置,但是你正在使用不同版本的 Gradle 来运行构建,也会启动一个新的守护进程。这对于 --stop 命令行指令也有一个后果:当运行 --stop 时,你只能停止运行这个命令的 Gradle 版本所启动的守护进程。
    At the moment daemon is coupled with particular version of Gradle. This means that even if some daemon is idle but you are running the build with a different version of Gradle, a new daemon will be started. This also has a consequence for the --stop command line instruction: You can only stop daemons that were started with the Gradle version you use when running --stop.

我们计划在将来改进管理及合并守护进程的方式。
We plan to improve the ways of managing / pooling the daemons in future.

19.3. 用法和故障排除

19.3. Usage and troubleshooting

对于命令行的用法,可以看看专题《附录 D,Gradle 命令行》。如果你已经厌倦了一次又一次地使用相同的命令行选项,可以看《第 20.1 节,“通过 gradle.properties 配置构建环境”》。这一章节包含了有关如何以一种"持久化"的方式配置守护进程某些行为(包括默认情况下开启守护进程)的信息。
For command line usage take a look dedicated section in Appendix D, Gradle Command Line. If you are tired of using the same command line options again and again, take a look at Section 20.1, “Configuring the build environment via gradle.properties”. The section contains information on how to configure certain behavior of the daemon (including turning on the daemon by default) in a more 'persistent' way.

以下是有关 Gradle 守护进程的故障排除的一些方法:
Some ways of troubleshooting the Gradle daemon:

  • 如果你的构建有问题,请尝试暂时禁用守护进程(可以通过使用命令行开关 --no-daemon)。
    If you have a problem with your build, try temporarily disabling the daemon (you can pass the command line switch --no-daemon).
  • 有时候,你可能想要通过 --stop 命令行选项或更有力的方式停止守护进程。
    Occasionally, you may want to stop the daemons either via the --stop command line option or in a more forceful way.
  • 守护进程的日志文件默认在 Gradle 用户主目录下。
    There is a daemon log file, which by default is located in the Gradle user home directory.
  • 你可能想要以 --foreground 模式启动守护程序,来观察构建是怎么执行的。
    You may want to start the daemon in --foreground mode to observe how the build is executed.

19.4. 配置守护进程

19.4. Configuring the daemon

可以配置一些守护进程的设置,例如 JVM 参数、 内存设置或 Java home 目录。更多有关信息请参阅《20.1 节,“通过 gradle.properties 配置构建环境”
Some daemon settings, such as JVM arguments, memory settings or the Java home, can be configured. Please find more information in Section 20.1, “Configuring the build environment via gradle.properties”