即使Xms=Xmx，G1GC是否也会将内存释放回操作系统？

Question

在阅读了一些像这样的答案和JEP-346之后，我意识到G1确实会将内存释放回操作系统。

然而，它是否将内存释放回操作系统，即使当前内存使用可能低于初始堆内存（即在此JEP之前，在我的案例中为JDK11）？

假设我有一个Java11 VM，运行Xms和Xmx设置为5GB，在8GBRAM上，但是我只消耗大约1GB。G1会释放足够的内存回操作系统吗？

我在任何地方都没有找到任何文档说明G1仅限于在发布时考虑Xms阈值。

我在生产过程中观察到了这一点，MemAvailable不断减少，直到达到一个点，然后在GC之后，在8GB的机箱上，它会跳到接近30-35%。所以我假设它正在释放内存，这就是MemAvailable正在跳回的原因。

另外，向操作系统释放内存到底意味着什么，是调用空闲/取消映射吗？

Answer 1

注意：我已经删除了之前的答案，并研究了源代码（还构建了我自己的JVM，只是为了找出这一特定时刻），下面是答案。

简短的回答

JVM 11版本（目前），在使堆变小时不会低于Xms。

冗长的答案

源代码是绝对正确的。下面是是否缩小堆的决定。在下面几行中，您可以看到，如果我们输入该if，将出现一条log语句：

尝试堆收缩（容量高于完全GC后的最大所需容量）。

所以从本质上讲，如果我们能理解两个参数：capacity_after_gc和maximum_desired_capacity-我们就可以解开这个谜团。总的来说，capacity_after_gc不是一个容易掌握的东西；主要是因为它取决于有多少垃圾以及当前GC可以回收多少垃圾。为了简单起见，我准备写一些不产生任何垃圾的代码，这样这个值就是恒定的。

在这种情况下，我们只需要了解maximum_desired_capacity。

在上面的几行中，您可以看到这是计算为：

maximum_desired_capacity =  MAX2(maximum_desired_capacity, min_heap_size);

不幸的是，这就是它变得棘手的地方，因为要真正了解这些人体工程学是如何设置的，需要遵循和理解很多代码；尤其是因为它们依赖于JVM开始时使用的各种参数。

例如，最小堆大小设置为：

// If the minimum heap size has not been set (via -Xms),
// synchronize with InitialHeapSize to avoid errors with the default value.

请注意，它们甚至至少引用了Xms；虽然文件上说这是最初的。您还可以注意到，它还取决于另外两个属性：

 reasonable_minimum , InitialHeapSize

这将很难进一步解释；这就是为什么我不会。相反，我将向您展示一些简单的证明（我确实阅读了大部分代码…）

假设您有以下非常简单的代码：

public class HeapShrinkExpand {

    public static void main(String[] args) throws InterruptedException {

        for (int i = 0; i < 10; i++) {
            Thread.sleep(500);
            System.gc();
        }
    }
}

我运行它时使用：

-Xmx22g 
-XX:InitialHeapSize=1g
"-Xlog:heap*=debug" 
"-Xlog:gc*=debug" 
"-Xlog:ergo*=debug" 

在日志中，我将看到：

[0.718s][debug][gc,ergo,heap   ] GC(0) Attempt heap shrinking (capacity higher than max desired capacity after Full GC). Capacity: 1073741824B occupancy: 8388608B live: 1018816B maximum_desired_capacity: 27962026B (70 %)
[0.719s][debug][gc,ergo,heap   ] GC(0) Shrink the heap. requested shrinking amount: 1045779798B aligned shrinking amount: 1044381696B attempted shrinking amount: 1044381696B

这告诉您一些关于所需收缩量、当前容量等的统计数据。下一行将显示堆实际上下降了多少：

[0.736s][debug][gc,ihop] GC(0) Target occupancy update: old: 1073741824B, new: 29360128B

堆确实缩小到了29MB左右。

如果我添加一个JVM启动标志：-Xms10g，那些负责显示堆收缩到多少的GC日志；将不再存在。

事实上，如果我运行自己的JMV（启用一些日志记录），这两个值：capacity\u after\u gc和maximum\u desired\u capacity总是具有相同的值；这意味着永远不会输入if语句，堆也永远不会低于Xms。

我已经使用JDK-13运行了相同的代码，当收缩日志存在时（当-Xms作为参数给出时），底层堆仍然停留在-Xms。我发现更有趣的是，在java-13下，尝试使用：

 -Xmx22g -Xms5g -XX:InitialHeapSize=1g

将正确错误：

指定的最小和初始堆大小不兼容