-Xmx和Runtime.maxMemory为什么不一致

问题内容：

当您添加

 -Xmx????m

在命令行中，JVM给您提供了一个接近此值的堆，但最多可以出14％。JVM可以使您更接近所需的数字，但只能通过反复试验才能实现。

 System.out.println(Runtime.getRuntime().maxMemory());

版画

-Xmx1000m ->  932184064
-Xmx1024m -Xmx1g ->  954728448
-Xmx1072m ->  999292928
-Xmx1073m -> 1001390080

我正在运行HotSpot Java 8 Update 5。

显然，堆可以在上面，1000000000但是为什么要这样-Xmx1073m而不是说呢-Xmx1000m？

BTW 1g== 1024m表示1g应该为1024 ^ 3，比1000 ^ 3高7％，但您得到的东西比1000 ^ 3低7％。

太多的变化表明我缺少关于堆如何工作的一些基本知识。如果我要求-
Xmx1000m，而1001390080我不在乎，我会假设它需要遵守一些分配倍数，但是给你932184064建议我，堆比我想象的要复杂。

编辑我发现

-Xmx1152m gives 1073741824 which is exactly 1024^3

因此看来，这比我在maxMemory（）情况下所要求的要少128 MB。

BTW 128是我最喜欢的号码。我今天在街道号码的一次会议上，128演讲者引用了书中的一本书128;）

问题答案：

差异似乎是由垃圾收集器的幸存者空间的大小引起的。

如docs中-Xmx所述，该标志控制内存分配池的最大大小。内存分配池的堆部分分为Eden，Survivor和Tenured空间。正如描述的这个答案，有两个幸存者的区域，只有其中之一是可在任何给定时间点要hold住对象。因此，如报告的那样，可用于分配对象的总表观空间必须从总堆内存池中减去幸存者空间之一的大小。Runtime.maxMemory()

您可以使用MemoryMXBean和MemoryPoolMXBean类来获取有关内存分配的更多信息。这是我编写的一个简单程序：

import java.lang.management.ManagementFactory;
import java.lang.management.MemoryMXBean;
import java.lang.management.MemoryPoolMXBean;

public class MemTest {
  static String mb (long s) {
    return String.format("%d (%.2f M)", s, (double)s / (1024 * 1024));
  }

  public static void main(String[] args) {
    System.out.println("Runtime max: " + mb(Runtime.getRuntime().maxMemory()));
    MemoryMXBean m = ManagementFactory.getMemoryMXBean();

    System.out.println("Non-heap: " + mb(m.getNonHeapMemoryUsage().getMax()));
    System.out.println("Heap: " + mb(m.getHeapMemoryUsage().getMax()));

    for (MemoryPoolMXBean mp : ManagementFactory.getMemoryPoolMXBeans()) {
      System.out.println("Pool: " + mp.getName() + 
                         " (type " + mp.getType() + ")" +
                         " = " + mb(mp.getUsage().getMax()));
    }
  }
}

在OpenJDK 7上，此输出java -Xmx1024m MemTest为：

Runtime max: 1037959168 (989.88 M)
Non-heap: 224395264 (214.00 M)
Heap: 1037959168 (989.88 M)
Pool: Code Cache (type Non-heap memory) = 50331648 (48.00 M)
Pool: Eden Space (type Heap memory) = 286326784 (273.06 M)
Pool: Survivor Space (type Heap memory) = 35782656 (34.13 M)
Pool: Tenured Gen (type Heap memory) = 715849728 (682.69 M)
Pool: Perm Gen (type Non-heap memory) = 174063616 (166.00 M)

请注意，Eden + 2 * Survivor + Tenured = 1024M，这恰好是命令行上请求的堆空间量。非常感谢@ Absurd-
Mind指出这一点。

您在不同的JVM之间观察到的差异很可能是由于选择不同版本的默认相对大小的启发式方法不同。如本文所述（适用于Java
6，无法找到更新的版本），可以使用-XX:NewRatio和-XX:SurvivorRatio标志来显式控制这些设置。因此，运行命令：

java -Xmx1024m -XX:NewRatio=3 -XX:SurvivorRatio=6

您要告诉JVM：

Young:Tenured = (Eden + 2*Survivor):Tenured = 1:3 = 256m:768m
Survivor:Eden = 1:6 = 32m:192m

因此，使用这些参数，请求的-Xmx值与报告的可用内存之间的差Runtime.maxMemory()应为32m，可使用上述程序进行验证。现在，您应该能够准确地预测Runtime给定的命令行参数集报告的可用内存，这是您真正想要的，对吧？

-Xmx和Runtime.maxMemory为什么不一致

微信关注