3

该 JEP 的既定目标是增强 G1 垃圾收集器，以便在空闲时自动将 Java 堆内存返回给操作系统

由于 G1 努力完全避免完全 GC，并且仅根据 Java 堆占用和分配活动触发并发循环，因此在许多情况下它不会返回 Java 堆内存，除非在外部强制这样做。

那么这在资源按使用付费的容器环境中是否不利？

任何人都可以澄清这一点......

参考：https ://bugs.java.com/bugdatabase/view_bug.do?bug_id=8204089

4

2 回答 2

3

如果我没有误解您，您似乎是在问在容器化环境中让 GC 回收内存是否不利，因为用户可能没有充分利用内存，因此对资源收费过高。

您提供的链接实际上说明了以下内容：

这种行为在资源按使用付费的容器环境中尤其不利。即使在虚拟机由于不活动而仅使用其分配的内存资源的一小部分的阶段，G1 也会保留所有 Java 堆。这导致客户一直为所有资源付费，而云提供商[无法充分利用他们的硬件][4]。

如果 VM 能够检测到 Java 堆未充分利用的阶段（“空闲”阶段），并在此期间自动减少其堆使用量，那么两者都会受益。

这个 JEP 的设计者似乎相信用户和云提供商都将从回收未使用的内存中受益，从上面的陈述来看似乎是有道理的。

但是，如果您的程序在定时环境（例如 AWS Lambda）中运行并且它是短暂的，那么您甚至可能希望使用 Epsilon GC，其中不会回收任何内存，因为在某些情况下这可能会使您受益更多（如果容器将被销毁，为什么要花费 CPU 周期来回收内存？）。

于 2019-02-02T06:05:45.427 回答
3

根据JEP 文档，新行为是可选的

在配置的默认值中，我们禁用此功能。这不会导致对延迟或吞吐量敏感的应用程序的 VM 行为发生意外变化。

所以不会对任何系统产生影响。对于可能值得的环境，可以启用它，然后评估影响。

虽然目标是帮助共享容器化或虚拟机环境，但这并不一定意味着所有这些环境都会真正受益，因为这取决于它们的利用率、在空闲期间可以削减多少峰值内存、CPU 或内存是否更有价值以及许多其他因素。

因此，它是否（不利）有利将必须根据具体情况进行评估。

于 2019-02-05T20:28:29.390 回答