在热点JVM不释放内存给操作系统，但不会因为调整堆所以勉强是昂贵的，它假定，如果你需要的堆一旦你会再次使用它。
你可以通过设置使其更具侵略性，-XX:GCTimeRatio=19 -XX:MinHeapFreeRatio=20 -XX:MaxHeapFreeRatio=30从而使其在GC周期后花费更多的cpu时间来收集和限制已分配但未使用的堆内存量。
假设你正在使用并发收集器，还可以将-XX:InitiatingHeapOccupancyPercent=NN 设置为一个较低的值，以使GC几乎连续运行并发收集，这将消耗更多的cpu周期，但会更快地缩小堆。通常这不是一个好主意，但是在某些类型的具有大量备用cpu内核但内存不足的机器上，这是有道理的。
如果你使用的收集器具有默认的暂停时间目标（CMS或G1），则你也可以放宽该目标，以在收集器上设置更少的约束，或者你可以切换并行收集器，以在暂停时间之前优先考虑占用空间。
此外，通过Java 9 -XX:-ShrinkHeapInSteps选项，可以更积极地应用由前两个选项引起的缩小。相关的OpenJDK错误。
请注意，收缩能力和行为取决于所选择的垃圾收集器。例如，G1仅使用jdk8u20 获得了在堆中间退回未使用的块的能力，而ZGC 使用jdk13进行了回收，而ε收集器则极有可能不会这样做。 因此，如果需要堆收缩，则应该针对特定的JVM版本和GC配置进行测试。
GC Logging with PrintAdaptiveSizePolicy也可能提供洞察力，例如，当JVM尝试为年轻一代使用更多内存以满足某些目标时。
OpenJDK 12中还包含JEP 346，该JEP引入了带有G1PeriodicGCInterval选件的G1GC的即时内存释放，但又以一些额外的cpu为代价。它还提到了Shenandoah和OpenJ9 VM中的类似功能。
602392714
清零编程群