Java 12-GC (JEP 346)在资源按使用付费的容器环境中行为是否特别不利？
Java 12-GC (JEP 346)Is behavior is particularly disadvantageous in container environments where resources are paid by use?
此 JEP 的既定目标是增强 G1 垃圾收集器，使其在空闲时自动 return Java 将堆内存分配给操作系统
由于G1尽量避免full GC，只会根据Java堆占用和分配activity触发并发循环，不会returnJava 在很多情况下都是堆内存，除非在外部强制这样做。
那么这在资源按使用付费的容器环境中是否不利？
谁能澄清一下....
参考：https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8204089
如果我没有误会你的话，你好像是在问在容器化环境中让 GC 回收内存是否不利，因为用户可能没有充分利用内存，从而对资源收取过多费用。
您提供的 link 实际上说明如下：
This behavior is particularly disadvantageous in container environments where resources are paid by use. Even during phases where the VM only uses a fraction of its assigned memory resources due to inactivity, G1 will retain all of the Java heap. This results in customers paying for all resources all the time, and cloud providers [not being able to fully utilize their hardware][4].
If the VM were able to detect phases of Java heap under-utilization ("idle" phases), and automatically reduce its heap usage during that time, both would benefit.
这个 JEP 的设计者似乎相信用户和云提供商都会从回收未使用的内存中获益，从上面的说法看来是有道理的。
但是，如果您的程序 运行 在定时环境（例如 AWS Lambda）中运行并且它的生命周期很短，您甚至可能想要利用 Epsilon GC，因为它不会回收任何内存，因为在某些情况下，这可能会让您受益更多（如果容器将被销毁，为什么要花费 CPU 周期回收内存？）。
根据 JEP document，新行为是选择加入
In the default values of the configuration we disable this feature. This results in no unexpected changes in the VM behavior for latency or throughput sensitive applications.
因此不会对任何系统造成影响。对于可能值得的环境，可以启用它然后评估影响。
虽然目标是帮助共享容器化或 VM 环境，但这并不一定意味着所有此类环境都会真正受益，因为这取决于它们的利用率，空闲期间可以削减多少峰值内存，是否 CPU或者内存更有价值还有很多其他因素。
因此是否有利（不利）必须根据具体情况进行评估。
此 JEP 的既定目标是增强 G1 垃圾收集器，使其在空闲时自动 return Java 将堆内存分配给操作系统
由于G1尽量避免full GC，只会根据Java堆占用和分配activity触发并发循环，不会returnJava 在很多情况下都是堆内存，除非在外部强制这样做。
那么这在资源按使用付费的容器环境中是否不利？
谁能澄清一下....
参考：https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8204089
如果我没有误会你的话，你好像是在问在容器化环境中让 GC 回收内存是否不利，因为用户可能没有充分利用内存，从而对资源收取过多费用。
您提供的 link 实际上说明如下：
This behavior is particularly disadvantageous in container environments where resources are paid by use. Even during phases where the VM only uses a fraction of its assigned memory resources due to inactivity, G1 will retain all of the Java heap. This results in customers paying for all resources all the time, and cloud providers [not being able to fully utilize their hardware][4].
If the VM were able to detect phases of Java heap under-utilization ("idle" phases), and automatically reduce its heap usage during that time, both would benefit.
这个 JEP 的设计者似乎相信用户和云提供商都会从回收未使用的内存中获益，从上面的说法看来是有道理的。
但是，如果您的程序 运行 在定时环境（例如 AWS Lambda）中运行并且它的生命周期很短，您甚至可能想要利用 Epsilon GC，因为它不会回收任何内存，因为在某些情况下，这可能会让您受益更多（如果容器将被销毁，为什么要花费 CPU 周期回收内存？）。
根据 JEP document，新行为是选择加入
In the default values of the configuration we disable this feature. This results in no unexpected changes in the VM behavior for latency or throughput sensitive applications.
因此不会对任何系统造成影响。对于可能值得的环境，可以启用它然后评估影响。
虽然目标是帮助共享容器化或 VM 环境，但这并不一定意味着所有此类环境都会真正受益，因为这取决于它们的利用率，空闲期间可以削减多少峰值内存，是否 CPU或者内存更有价值还有很多其他因素。
因此是否有利（不利）必须根据具体情况进行评估。