问题描述
我使用默认的垃圾收集器 (G1GC) 运行了一个 Java 应用程序。我不明白 G1CC 何时完全释放内存。在 htop 中，我看到应用程序使用了 700M。在我做了 jcmd <pid> GC.run 之后，它下降到了大约 250M。这是否意味着 GC 本身不会这样做？
解决方法
在优化应用程序的性能和可扩展性时，资源效率是一个主要问题。在 Java 世界中，通常支配资源问题的一个方面是内存使用 - 更具体地说，Java 堆的大小。
与 .NET 和 CLR 相比，JVM 以需要在启动时调整堆大小而闻名，而没有任何空间回收的机会，这将使资源可供其他进程使用。这在今天仍然适用吗？让我们来了解一下。
垃圾收集器负责管理堆和相关的操作系统分配。从 JDK 9 开始，G1 垃圾收集器一直是默认的 GC。一般来说，GC 会尽量避免释放堆空间（将内存还给操作系统），因为如果稍后需要该空间，这可能会导致性能下降。
堆收缩取决于收集周期，该周期由仅年轻和空间回收阶段组成。
如果最初分配新对象的相关 eden 空间耗尽，则会发生仅年轻阶段。可到达的物体被疏散（移动）到幸存者空间。如果 Survivor 空间耗尽，则可到达的对象将被疏散到另一个 Survivor 空间或老年代（如果对象可到达或“存活”了给定数量的集合）。
空间回收的发生取决于老年代的大小，由初始堆占用率 (IHOP) 控制。默认值 (-XX:InitiatingHeapOccupancyPercent) 为 45%，但 IHOP 由 GC 调整以优化收集间隔（称为“自适应 IHOP”）。这个阶段也处理年轻代，因此它被称为“混合收集”。
根据 G1 source in JDK 9，收缩仅在完整收集（显式收集与否）之后进行，并且仅在满足特定阈值的情况下进行。 G1CollectedHeap::do_full_collection 调用 G1CollectedHeap::resize_if_necessary_after_full_collection，它处理收缩过程并生成以下 GC 日志输出：
log_debug(gc,ergo,heap)(
"Shrink the heap. requested shrinking amount: "
SIZE_FORMAT "B aligned shrinking amount: "
SIZE_FORMAT "B attempted shrinking amount: "
SIZE_FORMAT "B",shrink_bytes,aligned_shrink_bytes,shrunk_bytes);
G1 GC 旨在
[...] 提供延迟和吞吐量之间的最佳平衡 [...]
G1 尝试尽可能长时间地推迟垃圾回收，并在一般情况下尽量避免完全垃圾回收。有关详情，请参阅Garbage Collection Cycle。
[...] 如果应用程序在收集活动信息时内存不足，G1 会像其他收集器一样执行就地停止世界全堆压缩（Full GC）[...]
除非手动触发（例如使用 java.lang.System.gc()），否则收集器仅在空间耗尽的情况下执行完整收集。这时候可能会发生堆收缩。
根据G1 source in JDK 15，对完整集合以及并发标记和清除集合进行闪烁。 G1FullCollector::complete_collection 调用 G1CollectedHeap::prepare_heap_for_mutators，后者又调用 G1CollectedHeap::resize_heap_if_necessary。实际收缩过程和日志消息与 JDK 9 相同。 与 JDK 9 相比，JDK 12 及更高版本也在所谓的重新标记阶段（G1ConcurrentMark::remark 调用 G1CollectedHeap::resize_heap_if_necessary）执行收缩，在正常收集周期的上下文。
更改是通过 08041b0d7c08 引入的。
一种直接的监控方式是-verbose:gc。使用-Xlog:gc=debug查看上面提到的log输出，以防缩小。
因此，尽管人们普遍认为，JVM 确实会将内存返回给操作系统。在 JDK 11 之前，堆收缩仅在完全收集后触发，因为更改足够重要以保证在不影响性能的情况下执行该操作。使用 JDK 12+（检查到 15），堆收缩也会在正常收集周期中触发，这使得通常不涉及完整收集的应用程序更有可能看到堆收缩。