gradle 2.10 The Gradle Daemon使用详解
来源:互联网 发布:虚拟机ubuntu安装错误 编辑:程序博客网 时间:2024/05/21 10:22
Chapter 6. The Gradle Daemon
From Wikipedia…
A daemon is a computer program that runs as a background process,rather than being under the direct control of an interactive user.
Gradle runs on the Java Virtual Machine (JVM) and uses several supporting libraries that require anon-trivial initialization time. As a result, it can sometimes seem a little slow to start. The solutionto this problem is the GradleDaemon: a long-lived background process that executesyour builds much more quickly than would otherwise be the case. We accomplish this by avoiding the expensivebootstrapping process as well as leveraging caching, by keeping data about your project in memory. RunningGradle builds with the Daemon is no different than without. Simply configure whether you want to use it ornot - everything else is handled transparently by Gradle.
6.1. Enabling the Daemon
The Gradle Daemon is not enabled by default, but we do recommend always enabling it for developers’machines (but leaving it disabled for continuous integration servers). There are several ways to enable theDaemon, but the most common one is to add the line
org.gradle.daemon=true
to the file «USER_HOME»/.gradle/gradle.properties
, where«USER_HOME»
is your home directory. That’s typically one of the following, depending on your platform:
C:\Users\<username>
(Windows Vista & 7+)/Users/<username>
(Mac OS X)/home/<username>
(Linux)
If that file doesn’t exist, just create it using a text editor. You can find details of other ways to enable(and disable) the Daemon in the FAQ further down. That section also contains more detailed information onhow the Daemon works.
Once you have globally enabled the Daemon in this way, all your builds will take advantage of thespeed boost, regardless of the version of Gradle a particular build uses.
Continuous integration
At the moment, we recommend that you leave the Daemon disabled for continuous integration serversas using a fresh runtime for each build is more reliable since the runtime iscompletelyisolated from previously builds. Additionally, since the Daemon primarily acts to reduce buildstartup times, this isn't as critical in CI as it is on a developer's machine.
6.2. Stopping an existing Daemon
As mentioned, the Daemon is a background process. You needn’t worry about a build up of Gradleprocesses on your machine, though: every Daemon stops after 3 hours of inactivity. If you want toexplicitly stop a Daemon process for any reason, just use the commandgradle --stop
.
This will terminate all Daemon processes that were started with the same version of Gradle used to execute thecommand. If you have the Java Development Kit (JDK) installed, you can easily verify that a Daemon has stopped byrunning thejps command. You’ll see any running Daemons listed with the name GradleDaemon.
6.3. FAQ
6.3.1. What ways are there to enable the Gradle Daemon?
There are two recommended ways to enable the Daemon persistently for an environment:
Via environment variables - add the flag
-Dorg.gradle.daemon=true
to theGRADLE_OPTS
environment variableVia properties file - add
org.gradle.daemon=true
to the«GRADLE_USER_HOME»/gradle.properties
file
Note, «GRADLE_USER_HOME»
defaults to «USER_HOME»/.gradle
, where «USER_HOME»
is the home directory of the current user.This location can be configured via the-g
and --gradle-user-home
command line switches,as well as by theGRADLE_USER_HOME
environment variable and org.gradle.user.home
JVM system property.
Both approaches have the same effect.Which one to use is up to personal preference.Most Gradle users choose the second option and add the entry to the usergradle.properties
file.
On Windows, this command will enable the Daemon for the current user:
(if not exist "%USERPROFILE%/.gradle" mkdir "%USERPROFILE%/.gradle") && (echo org.gradle.daemon=true >> "%USERPROFILE%/.gradle/gradle.properties")
On UNIX-like operating systems, the following Bash shell command will enable the Daemon for the current user:
touch ~/.gradle/gradle.properties && echo "org.gradle.daemon=true" >> ~/.gradle/gradle.properties
Once the Daemon is enabled for a build environment in this way, all builds will implicitly use a Daemon.
The --daemon
and --no-daemon
command line switches enable and disable usage of the Daemon for individual build invocations when using the Gradle command line interface.Typically, it is more convenient to enable the Daemon for an environment (e.g. a user account) so that all builds use the Daemon without requiring to remember to supply the--daemon
switch.
6.3.2. How do I disable the Gradle Daemon?
The Gradle Daemon is not enabled by default.However, once it is enabled it is sometimes desirable to disable for some projects or for some build invocations.
The --no-daemon
command line switch can be used to force that a Daemon not be used for that build.This is rarely used, but can sometimes be useful when debugging issues with certain builds or Gradle plugins.This command line switch has the highest precedence when considering the build environment.
6.3.3. How do I suppress the “please consider using the Gradle Daemon” message?
Gradle may emit a warning at the end of the build suggesting that you use the Gradle Daemon.To avoid this warning you can enable the Daemon via the methods above, or explicitly disable the Daemon.You can explicitly disable the Daemon by using the--no-daemon
command line switch as described above,or use one of the methods for enabling the Daemon mentioned above but using a value offalse
for the org.gradle.daemon
property instead oftrue
.
As it is not recommend to use the Daemon for Continuous Integration builds, Gradle will not emit the message if theCI
environment variable is present.
6.3.4. Why is there more than one Daemon process on my machine?
There are several reasons why Gradle will create a new Daemon, instead of using one that is already running.The basic rule is that Gradle will start a new Daemon if there are no existing idle or compatible Daemons available.Gradle will kill any Daemon that has been idle for 3 hours or more, so you don't have to worry aboutcleaning them up manually.
- idle
An idle Daemon is one that is not currently executing a build or doing other usefulwork.
- compatible
A compatible Daemon is one that can (or can be made to) meet the requirements of therequested build environment. The Java runtime used to execute the build is an exampleaspect of the build environment. Another example is the set of JVM system propertiesrequired by the build runtime.
Some aspects of the requested build environment may not be met by an Daemon.If the Daemon is running with a Java 7 runtime, but the requested environment calls for Java 8 then the Daemon is not compatible and another must be started.Moreover, certain properties of a Java runtime cannot be changed once the JVM has started.It is not possible to change the memory allocation (e.g.-Xmx1024m
), default text encoding, default locale, etc of a running JVM.
The “requested build environment” is typically constructed implicitly from aspects of the build client’s (e.g. Gradle command line client, IDE etc.) environment and explicitly via command line switches and settings.SeeChapter 11, The Build Environment for details on how to specify and control the build environment.
The following JVM system properties are effectively immutable.If the requested build environment requires any of these properties, with a different value than a Daemon’s JVM has for this property, the Daemon is not compatible.
- file.encoding
- user.language
- user.country
- user.variant
- com.sun.management.jmxremote
The following JVM attributes, controlled by startup arguments, are also effectively immutable.The corresponding attributes of the requested build environment and the Daemon’s environment must match exactly in order for a Daemon to be compatible.
- The maximum heap size (i.e. the -Xmx JVM argument)
- The minimum heap size (i.e. the -Xms JVM argument)
- The boot classpath (i.e. the -Xbootclasspath argument)
- The “assertion” status (i.e. the -ea argument)
The required Gradle version is another aspect of the requested build environment.Daemon processes are coupled to a specific Gradle runtime.Working on multiple Gradle projects during a session that use different Gradle versions is a common reason for having more than one running Daemon process.
6.3.5. How much memory does the Daemon use and can I give it more?
If the requested build environment does not specify a maximum heap size, the Daemon will use up to 1GB of heap.It will use your the JVM's default minimum heap size.1GB is more than enough for most builds.Larger builds with hundreds of subprojects, lots of configuration, and source code may require, or perform better, with more memory.
To increase the amount of memory the Daemon can use, specify the appropriate flags as part of the requested build environment.Please seeChapter 11, The Build Environment for details.
6.3.6. How can I stop a Daemon?
Daemon processes will automatically terminate themselves after 3 hours of inactivity.If you wish to stop a Daemon process before this, you can either kill the process via your operating system or run thegradle --stop
command.The --stop
switch causes Gradle to request thatall running Daemon processes, of the same Gradle version used to run the command, terminate themselves.
6.3.7. What can go wrong with Daemon?
Considerable engineering effort has gone into making the Daemon robust, transparent and unobtrusive during day to day development.However, Daemon processes can occasionally be corrupted or exhausted.A Gradle build executes arbitrary code from multiple sources.While Gradle itself is designed for and heavily tested with the Daemon, user build scripts and third party plugins can destabilize the Daemon process through defects such as memory leaks or global state corruption.
It is also possible to destabilize the Daemon (and build environment in general) by running builds that do not release resources correctly.This is a particularly poignant problem when using Microsoft Windows as it is less forgiving of programs that fail to close files after reading or writing.
If it is suspected that the Daemon process has become unstable, it can simply be killed.Recall that the--no-daemon
switch can be specified for a build to prevent use of the Daemon.This can be useful to diagnose whether or not the Daemon is actually the culprit of a problem.
6.4. When should I not use the Gradle Daemon?
It is recommended that the Daemon is used in all developer environments.It is recommend tonot enable the Daemon for Continuous Integration and build server environments.
The Daemon enables faster builds, which is particularly important when a human is sitting in front of the build.For CI builds, stability and predictability is of utmost importance.Using a fresh runtime (i.e. process) for each build is more reliable as the runtime is completely isolated from previous builds.
6.5. Tools & IDEs
The Gradle Tooling API (see Chapter 13, Embedding Gradle), that is used by IDEs and other tools to integrate with Gradle,always use the Gradle Daemon to execute builds.If you are executing Gradle builds from within you're IDE you are using the Gradle Daemon and do not need to enable it for your environment.
However, unless you have explicitly enabled the Gradle Daemon for you environment your builds from the command line will not use the Gradle Daemon.
6.6. How does the Gradle Daemon make builds faster?
The Gradle Daemon is a long lived build process.In between builds it waits idly for the next build.This has the obvious benefit of only requiring Gradle to be loaded into memory once for multiple builds, as opposed to once for each build.This in itself is a significant performance optimization, but that's not where it stops.
A significant part of the story for modern JVM performance is runtime code optimization.For example, HotSpot (the JVM implementation provided by Oracle and used as the basis of OpenJDK) applies optimization to code while it is running.The optimization is progressive and not instantaneous.That is, the code is progressively optimized during execution which means that subsequent builds can be faster purely due to this optimization process.Experiments with HotSpot have shown that it takes somewhere between 5 and 10 builds for optimization to stabilize.The difference in perceived build time between the first build and the 10th for a Daemon can be quite dramatic.
The Daemon also allows more effective in memory caching across builds.For example, the classes needed by the build (e.g. plugins, build scripts) can be held in memory between builds.Similarly, Gradle can maintain in-memory caches of build data such as the hashes of task inputs and outputs, used for incremental building.
6.6.1. Potential future enhancements
Currently, the Daemon makes builds faster by effectively supporting in memory caching and by the JVM optimizer making the code faster.In future Gradle versions, the Daemon will become even smarter and perform workpreemptively.It could, for example, start downloading dependencies immediately after the build script has been edited under the assumption that the build is about to be run and the newly changed or added dependencies will be required.
There are many other ways in that the Gradle Daemon will enable even faster builds in future Gradle versions.
- gradle 2.10 The Gradle Daemon使用详解
- gradle daemon
- 解决使用gradle打包报错“The first result from the daemon was empty. ”
- Gradle使用详解
- Android Gradle使用详解
- Android Gradle使用详解
- Gradle Daemon (守护进程)
- Gradle 的Daemon配置
- Gradle 的Daemon配置
- Gradle开启daemon特性
- Gradle sync failed: Unable to start the daemon process
- 第3章 The Gradle Daemon(守护进程)
- Android Studio Gradle project sync failed,Gradle sync failed: Unable to start the daemon process.
- 在idea中使用gradle,daemon自动退出的问题
- Gradle详解-Chapter 4. Using the Gradle Command-Line
- Gradle 功能及使用详解
- Gradle 关于Daemon的配置
- Gradle详解
- 远程用户的WSDL访问问题以及SoapUI如何远程调用其他主机上的服务
- PKUSC2016 酱油记
- Java泛型
- [从头读历史] 第245节 三皇与五帝时期的全面解读
- Mysql错误:1396 (HY000): Operation CREATE USER failed for 'XXX'
- gradle 2.10 The Gradle Daemon使用详解
- 移动端小技巧
- android中通过条件查找通讯录联系人
- win Qt qextserialport 编写串口通信程序全程图文讲解
- Redis + Keepalived主从集群的搭建及故障转移
- 数字证书原理
- Error:The project is using an unsupported version of the Android Gradle plug-in (0.8.3). The recomme
- 设计模式--简单共厂模式
- mark使某些文字高亮显示,表示强调