java - Java 和 PHP 应用程序的 GC 和内存行为？

Question

这个问题是关于当请求需要的内存多于分配给 Pod 的内存时的垃圾收集行为。如果GC无法释放内存，会继续持续运行GC还是抛出的内存。

一个 pod 包含基于 java 的应用程序，另一个 pod 包含基于 PHP 的应用程序。如果 java xmx 值与给定的 pod 限制相同。

Answer 1

我只能谈谈Java GC。 (PHP 的 GC 行为会有所不同。)

If GC is not able to free memory, will it continue to run GC continuously after regular interval or throw out of memory.

这取决于 JVM 选项。

JVM 从堆的初始大小开始，并将根据需要扩展它。但是，它只会将堆扩展到固定的最大大小。当 JVM 从选项 (-Xmx) 或默认堆大小规则启动时，确定该最大大小。启动后无法更改。

随着使用的堆空间接近极限，GC 可能会越来越频繁地发生。现代 JVM 上的默认行为是监视垃圾收集所花费的时间百分比。如果它超过(可配置的)阈值，那么您将收到 OOME，其中包含有关已超过 GC 开销阈值的消息。即使有足够的空间“跛行”一段时间，这种情况也可能发生。

您可以关闭 GC Overhead Limit 功能，但不建议这样做。

如果 JVM 在执行完整垃圾回收后没有足够的堆空间，它也会抛出 OOME。

最后，如果 JVM 尝试增大堆并且操作系统拒绝为其提供其请求的内存，则会抛出 OOME。发生这种情况的原因是:

• 操作系统内存不足
• 操作系统已用完交换空间
• 该进程已超出ulimit，或者
• 进程组(容器)已超出容器限制。

JVM 仅少量了解其环境中的可用内存。在裸机操作系统或虚拟机管理程序下的虚拟机上，默认堆大小取决于 RAM 量。在裸机操作系统上，这就是物理 RAM。在虚拟机上，它将是...客户操作系统所看到的物理内存。

对于 Kubernetes，应用程序可用的内存可能会受到 cgroup 或类似内容的进一步限制。据我所知，最近的 Java 版本进行了一些调整，使它们更适合在容器中运行。我认为这意味着他们在计算默认堆大小时可以使用 cgroup 内存限制而不是物理内存大小。