GC是否将内存释放回OS？ [英] Does GC release back memory to OS?
问题描述
当垃圾收集器运行并释放内存时，该内存会返回到操作系统，还是作为进程的一部分保存。我有一种强烈的印象，即内存永远不会被释放回操作系统，而是作为内存区域/池的一部分被同一进程重用。
结果是进程的实际内存永远不会减少。 提醒我的文章是这样的，Java的运行时间是用C / C ++编写的，所以我猜这同样适用？
$ b 更新
My问题是关于Java。我提到了C / C ++，因为我假设Java的分配/释放是由JRE使用某种形式的malloc / delete来完成的。 HotSpot JVM 确实将内存释放回操作系统，但因为调整堆的大小，所以很不情愿。昂贵，并假设，如果你需要堆，一旦你需要再次。
您可以通过设置 -XX使其更具侵略性： GCTimeRatio = 19 -XX：MinHeapFreeRatio = 20 -XX：MaxHeapFreeRatio = 30 这将允许它在GC循环之后花更多的CPU时间来收集和约束分配但未使用的堆内存量。假设你使用并发收集器，你也可以设置 -XX：InitiatingHeapOccupancyPercent = N ，其中N为一些低的值让GC可以几乎连续地运行并发集合，这会消耗更多的CPU周期，但会更快地缩小堆。这通常不是一个好主意，但是在某些类型的机器上有很多空闲的CPU核心，但内存很短，这是合理的。
如果您使用具有默认暂停时间目标（CMS或G1）的收集器，则还可以放松该目标，以减少对收集器的约束，或者可以切换到并行收集器，以便在暂停时间内优先考虑足迹。
另外用Java 9 -XX：-ShrinkHeapInSteps 选项可以用来应用由前两个选项引起的收缩更积极。 相关的OpenJDK错误。
请注意，缩小能力和行为取决于所选垃圾收集器。例如，G1只获得了在堆中间返回未使用的块的能力 with jdk8u20。
因此，如果需要缩小堆，应该针对特定的JVM版本和GC配置进行测试。
使用 PrintAdaptiveSizePolicy 进行GC记录也可能提供见解，例如当JVM尝试为年轻一代使用更多内存来实现某些目标时。
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.
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?
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
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 again.
You can make it more aggressive 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.
Assuming 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.
If you're using a collector with a default pause time goal (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.
Additionally with Java 9 -XX:-ShrinkHeapInSteps option can be be used to apply the shrinking caused by the previous two options more aggressively. Relevant OpenJDK bug.
Do note that shrinking ability and behavior depends on the chosen garbage collector. For example G1 only gained the ability to yield back unused chunks in the middle of the heap with jdk8u20.
So if heap shrinking is needed it should be tested for a particular JVM version and GC configuration.
GC Logging with PrintAdaptiveSizePolicy may also provide insight, e.g. when the JVM tries to use more memory for the young generation to meet some goals.
这篇关于GC是否将内存释放回OS？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
