docker - 如何解决 gradle 在 docker 环境中被破坏的问题？

Question

Gradle在docker环境下无法正常工作，注定会占用过多的内存而被kill掉。

内存管理器使用下面的类获取它的快照

https://github.com/gradle/gradle/blob/master/subprojects/process-services/src/main/java/org/gradle/process/internal/health/memory/MemInfoOsMemoryInfo.java

特别是 Gradle 通过读取/proc/meminfo 来确定剩余多少可用内存，这在容器中提供了不准确的读数。

Gradle 仅在收到请求以创建具有更大最小堆大小的新工作程序守护程序时才终止工作程序守护程序，然后根据此阅读可用。

因此，Gradle 将继续制造 worker ，直到它用完容器的分配数量并被杀死。

有人对此有解决方法吗？真的不明白为什么这对更多人来说不是问题。我想只有当你的工作守护进程不能被重用而创建新的守护进程时，这才会真正成为一个问题，这对我来说就是这种情况，因为我有大量的模块。

我有一个临时解决方法，其中我给每个生成的 jvm 一个巨大的 -Xms，所以它总是触发最小堆大小 > 可用，所以总是删除之前的工作守护进程，但这并不令人满意。

-- 编辑

为了抢占某些东西，--max-workers 不会影响允许存在的 Worker Daemon 的数量，它只会影响允许处于事件状态的数量。即使使用 --max-workers = 1，也允许有任意多个空闲的 Worker Daemon。

Answer 1

编辑 - 忽略下面的内容，它有些工作，但我已经通过覆盖 MemInfoOsMemoryInfo 类来修补 Gradle，它工作得更好。将很快提供指向 MR 到 Gradle 的链接。

找到一个合理的解决方法，我们监听操作系统内存更新，每次完成任务时，我们请求比确定可用内存更多的内存，确保守护进程停止。

import org.gradle.process.internal.health.memory.OsMemoryStatus
import org.gradle.process.internal.health.memory.OsMemoryStatusListener
import org.gradle.process.internal.health.memory.MemoryManagertask 

task expireWorkers {
    doFirst {
        long freeMemory = 0

        def memoryManager = services.get(MemoryManager.class)
        gradle.addListener(new TaskExecutionListener() {
            void beforeExecute(Task task) {
            }
            void afterExecute(Task task, TaskState state) {
                println "Freeing up memory"
                memoryManager.requestFreeMemory(freeMemory * 2)
            }
        })
        memoryManager.addListener(new OsMemoryStatusListener() {
            void onOsMemoryStatus(OsMemoryStatus osMemoryStatus) {
                freeMemory = osMemoryStatus.freePhysicalMemory
            }
        })
    }
}