Java gradle守护程序的高内存使用率

我正在使用Gradle2.5编译一个Java项目，该项目由5个模块组成。为了加快速度，我还使用了gradle守护进程。但是，在编译过程中，gradle守护进程最多运行18个实例。编译完成后，仍然剩下15个守护进程实例。守护进程消耗大约600 MB的RAM。在后台运行这么多守护程序是正常的还是gradle守护程序配置错误

更新：

---

我的操作系统是Debian Jessie。Java版本是Oracle Java 8。

根据Antoniosss的建议，我联系了一位开发人员。事实证明，格拉德尔事实上非常渴望资源。即使对于一个简单的“Hello World”应用程序，守护进程也可能会使用高达150 MB甚至更多的内存。 也可以启动多个守护进程线程，只要它们在同一JVM中运行。 用户端只有有限的控制来控制/限制内存使用。 可以设置GRADLE_OPTS变量，以便将Xmx选项传递给JVM，例如，我使用以下设置构建了我的Android项目：

$ export GRADLE_OPTS="-Xmx64m -Dorg.gradle.jvmargs='-Xmx256m -XX:MaxPermSize=64m'"

第一个-Xmx选项是为在CLI中启动的Gradle设置的，第二个选项（在-Dorg.Gradle.jvmargs之后）是Gradle守护程序的-Xmx值

显然，JVM的内存越少，构建失败的风险就越高。因此，您可能必须调整这些设置，直到它们适合您的目的

---

这些设置也可以在gradle.properties文件中设置。

否，这是不正常的。您是如何启动构建的？从CLI或Android Studio？我正在使用CLI。我发出的命令是“/gradlew build”，那么我不确定您是否正在使用守护进程-应该将gradle的全局配置设置为使用deamon和ommit

daemon

参数。试试

/gradle build--daemon

我的$HOME/.gradle/gradle.properties文件中有以下内容：“org.gradle.daemon=true”。每当我在启动后启动一个构建时，我都会从gradle那里得到一条消息，即后续构建会更快，因为守护进程现在正在运行。我还可以看到带有“htop”的守护进程线程。在杀死守护进程后，我还是发出了你的命令。同样的行为。多个守护进程线程再次启动，守护进程的内存消耗量仍然约为600 mB。这很奇怪，看起来一切正常。一般来说，新的守护进程是在已经运行且“不兼容”的情况下启动的，这主要意味着构建是使用不同的JVM配置（如最大内存等）运行的。为此，您应该尝试在gradles支持网站上发布一个问题，谢谢，但我不同意“JVM允许的内存越少，构建失败的风险就越高-很明显。”-我的构建失败，因为构建占用了太多内存，Docker映像配置为不允许更多内存。