GC 是否将内存释放回操作系统? [英] Does GC release back memory to OS?
问题描述
当垃圾收集器运行并释放内存时，这些内存会返回给操作系统还是作为进程的一部分保留.我的印象是，内存从未真正释放回操作系统，而是作为内存区域/池的一部分保留，供同一进程重用.
When the garbage collector runs and releases memory does this memory go back to the OS or is it being kept as part of the process. I was under the strong impression that the memory is never actually released back to OS but kept as part of the memory area/pool to be reused by the same process.
因此，进程的实际内存永远不会减少.一篇让我想起的文章这是和 Java 的运行时是用 C/C++ 编写的，所以我想同样的事情也适用吗?
As a result the actual memory of a process would never decrease. An article that reminded me was this and Java’s Runtime is written in C/C++ so I guess the same thing applies?
更新
我的问题是关于 Java 的.我提到 C/C++ 是因为我假设 Java 的分配/释放是由 JRE 使用某种形式的 malloc/delete 完成的
Update
My question is about Java. I am mentioning C/C++ since I assume the Java’s allocation/deallocation is done by JRE using some form of malloc/delete
推荐答案
HotSpot JVM将内存释放回操作系统，但不情愿地这样做，因为调整堆的大小代价高昂，并且假设您需要该堆后，您将再次需要它.
The HotSpot JVM does release memory back to the OS, but does so reluctantly since resizing the heap is expensive and it is assumed that if you needed that heap once you'll need it again.
一般来说，收缩能力和行为取决于选择的垃圾收集器，JVM 版本，因为收缩能力通常是在添加 GC 本身很久之后才引入的.一些收集器可能还需要传递额外的选项来选择收缩.有些人很可能永远不会支持它，例如EpsilonGC.因此，如果需要堆收缩，则应针对特定的 JVM 版本和 GC 配置进行测试.
In general shrinking ability and behavior depends on the chosen garbage collector, the JVM version since shrinking capability was often introduced in later versions long after the GC itself was added. Some collectors may also require additional options to be passed to opt into shrinking. And some most likely never will support it, e.g. EpsilonGC. So if heap shrinking is desired it should be tested for a particular JVM version and GC configuration.
在这些版本中没有用于提示内存回收的明确选项，但您可以通过设置 -XX:GCTimeRatio=19 -XX:MinHeapFreeRatio=20 -XX:MaxHeapFreeRatio=30 来使 GC 更积极.代码>，这将允许它花费更多的 CPU 时间来收集和限制 GC 周期后已分配但未使用的堆内存量.
There are no explicit options for prompt memory reclamation in these versions but you can make the GC more aggressive in general by setting -XX:GCTimeRatio=19 -XX:MinHeapFreeRatio=20 -XX:MaxHeapFreeRatio=30 which will allow it to spend more CPU time on collecting and constrain the amount of allocated-but-unused heap memory after a GC cycle.
如果您使用并发收集器，您还可以将 -XX:InitiatingHeapOccupancyPercent=N 设置为一些较低的值，让 GC 几乎连续运行并发收集，这将消耗更多 CPU循环但更快地缩小堆.这通常不是一个好主意，但在某些类型的机器上有很多备用 CPU 内核但内存不足，这是有道理的.
If you're using a concurrent collector you can also set -XX:InitiatingHeapOccupancyPercent=N with N to some low value to let the GC run concurrent collections almost continuously, which will consume even more CPU cycles but shrink the heap sooner. This generally is not a good idea, but on some types of machines with lots of spare CPU cores but short on memory it can make sense.
如果您使用 G1GC，请注意它仅获得了回收未使用的块的能力在使用 jdk8u20 的堆中间，早期版本只能返回堆末尾的块，这对可以回收的数量有很大限制.
If you're using G1GC note that it only gained the ability to yield back unused chunks in the middle of the heap with jdk8u20, earlier versions were only able to return chunks at the end of the heap which put significant limits on how much could be reclaimed.
如果您使用具有默认暂停时间目标(例如 CMS 或 G1)的收集器，您也可以放宽该目标以减少对收集器的限制，或者您可以切换并行收集器以优先考虑占用空间而不是暂停时间.
If you're using a collector with a default pause time goal (e.g. CMS or G1) you can also relax that goal to place fewer constraints on the collector, or you can switch go the parallel collector to prioritize footprint over pause times.
要验证收缩是否发生或诊断 GC 决定不收缩的原因，您可以使用带有 -XX:+PrintAdaptiveSizePolicy 的 GC 日志记录也可以提供洞察力，例如当 JVM 尝试为年轻代使用更多内存以满足某些目标时.
To verify that shrinking occurs or to diagnose why a GC decides not to shrink you can use GC Logging with -XX:+PrintAdaptiveSizePolicy may also provide insight, e.g. when the JVM tries to use more memory for the young generation to meet some goals.
添加了 -XX:-ShrinkHeapInSteps 选项，可用于更积极地应用由上一节中提到的选项引起的收缩.相关 OpenJDK 错误.
Added the -XX:-ShrinkHeapInSteps option which can be be used to apply the shrinking caused by the options mentioned in the previous section more aggressively. Relevant OpenJDK bug.
用于日志记录 -XX:+PrintAdaptiveSizePolicy 已替换为 -Xlog:gc+ergo
For logging -XX:+PrintAdaptiveSizePolicy has been replaced with -Xlog:gc+ergo
引入了通过 G1PeriodicGCInterval (JEP346)，同样以增加一些 CPU 为代价.JEP 还在 Shenandoah 和 OpenJ9 VM.
Introduced the option to enable prompt memory release for G1GC via the G1PeriodicGCInterval (JEP 346), again at the expense of some additional CPU. The JEP also mentions similar features in Shenandoah and the OpenJ9 VM.
Adds similar behavior for ZGC, in this case it is enabled by default.
这篇关于GC 是否将内存释放回操作系统?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
