java - GC 是否将内存释放回操作系统？

Question

当垃圾收集器运行并释放内存时，这些内存是返回给操作系统还是作为进程的一部分保留。我有一个强烈的印象，即内存从未真正释放回操作系统，而是作为内存区域/池的一部分保留，以供同一进程重用。

因此，进程的实际内存永远不会减少。 An article这让我想起了这个，而 Java 的运行时是用 C/C++ 编写的，所以我想同样的事情也适用吗？

更新
我的问题是关于 Java 的。我提到 C/C++ 是因为我假设 Java 的分配/解除分配是由 JRE 使用某种形式的 malloc/delete 完成的

Answer 1

HotSpot JVM确实会将内存释放回操作系统，但这样做并不情愿，因为调整堆的大小很昂贵，并且假定如果您需要该堆，您将再次需要它。

一般来说，缩小能力和行为取决于所选择的垃圾收集器，JVM 版本，因为缩小能力通常在添加 GC 本身很久之后在后来的版本中引入。一些 Collection 家可能还需要传递额外的选项来选择缩减。有些人很可能永远不会支持它，例如EpsilonGC。因此，如果需要堆收缩，则应针对特定的 JVM 版本和 GC 配置进行测试。

JDK 8 及更早版本

在这些版本中没有明确的提示内存回收选项，但您可以通过设置 -XX:GCTimeRatio=19 -XX:MinHeapFreeRatio=20 -XX:MaxHeapFreeRatio=30 这将允许它花费更多的 CPU 时间来收集和限制 GC 周期后分配但未使用的堆内存量。

如果您使用并发收集器，您还可以将 -XX:InitiatingHeapOccupancyPercent=N 和 N 设置为某个较低的值，让 GC 几乎连续运行并发收集，这将消耗更多 CPU循环但更快地缩小堆。这通常不是一个好主意，但在某些类型的具有大量备用 CPU 内核但内存不足的机器上，它可能有意义。

如果您使用的是 G1GC，请注意它只获得了 yield back unused chunks in the middle of the heap 的能力对于 jdk8u20，早期版本只能返回堆末尾的 block ，这对可以回收的量设置了显着限制。

如果您使用的收集器具有默认的暂停时间目标(例如 CMS 或 G1)，您还可以放宽该目标以减少对收集器的限制，或者您可以切换并行收集器以优先考虑占用空间而不是暂停时间.

要验证缩小是否发生或诊断 GC 决定不缩小的原因，您可以使用带有 -XX:+PrintAdaptiveSizePolicy 的 GC 日志记录也可以提供洞察力，例如当 JVM 尝试为年轻代使用更多内存以实现某些目标时。

JDK 9

添加了 -XX:-ShrinkHeapInSteps 选项，可用于更积极地应用由上一节中提到的选项引起的收缩。 Relevant OpenJDK bug .

对于日志记录，-XX:+PrintAdaptiveSizePolicy 已替换为 -Xlog:gc+ergo

JDK 12

引入了通过 G1PeriodicGCInterval ( JEP 346 ) 为 G1GC 启用快速内存​​释放的选项，同样以一些额外的 CPU 为代价。 JEP 还在 Shenandoah 中提到了类似的功能和 OpenJ9 VM .

JDK 13

添加了类似的行为 for ZGC ，在本例中默认启用。此外，XXSoftMaxHeapSize 有助于某些工作负载将平均堆大小保持在某个阈值以下，同时仍允许 transient 峰值。