java - 即使Xms = Xmx，G1GC也会向操作系统释放内存吗？

Question

在阅读了诸如this和JEP-346之类的答案之后，我意识到G1确实将内存释放回了操作系统。

但是，它是否将内存释放回操作系统，甚至导致当前的内存使用量可能降至初始堆内存以下(即，在此JEP之前，对于我而言为JDK11)？

假设我有一个Java 11 VM，在Xms RAM上运行了Xmx和5GB设置为8GB，但是我只在1GB周围使用。 G1是否将足够的内存释放回操作系统？

我在任何地方都找不到任何文档，其中说G1仅限于发布时要牢记Xms阈值。

我在生产中观察到这一点，MemAvailable一直下降到一个点，然后在GC之后，它在8GB的盒子上跳升到接近30-35％。因此，我假设它正在释放内存，这就是MemAvailable正在回跳的原因。

另外，释放内存到OS到底是什么意思，它是在调用free/unmap吗？

Answer 1

注意:我已经删除了之前的答案，并研究了源(也为发现这一刻而构建了自己的JVM)，这就是答案。

简短答案

当减小堆大小时，JVM 11 version(目前)不会低于Xms。

详细答案

绝对真理在源代码中。 here是决定是否缩小堆的决定。在下面的几行中，您可以看到，如果我们输入if，将会有一条日志语句:

Attempt heap shrinking (capacity higher than max desired capacity after Full GC).

因此，从本质上讲，如果我们能够理解两个参数: capacity_after_gc和 maximum_desired_capacity-我们可以解决这个奥秘。通常， capacity_after_gc并不容易掌握；主要是因为这取决于有多少垃圾以及当前GC可以回收多少垃圾。为简单起见，我将编写一些不会产生任何垃圾的代码，以便使该值恒定。

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

A few lines above，您可以看到它的计算公式为:

maximum_desired_capacity =  MAX2(maximum_desired_capacity, min_heap_size);

不幸的是，这很棘手，因为要真正了解这些人机工程学是如何设置的，需要遵循并理解很多代码。特别是因为它们取决于 JVM开头的各种参数。

例如 min_heap_size is set as:

// 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_after_gc和 maximum_desired_capacity将始终具有相同的值；这意味着 if statement将永远不会输入，并且堆永远不会低于 -Xms。

我已经用JDK-13运行了相同的代码，尽管那里有缩小的日志(当将 -Xms作为参数提供时)，但基础堆仍停留在 -Xms上。我发现更有趣的是在 java-13下尝试运行:

 -Xmx22g -Xms5g -XX:InitialHeapSize=1g

将正确错误出:

Incompatible minimum and initial heap sizes specified