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

标签 java memory garbage-collection jvm heap-memory

添加时

 -Xmx????m

对于命令行,JVM 为您提供了一个接近此值但最多可超出 14% 的堆。 JVM 可以为您提供更接近您想要的数字,但只能通过反复试验。

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

打印

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

我正在运行 HotSpot Java 8 更新 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

所以看起来它给我的内存比我在这种情况下所要求的少了 128 MB,参见 maxMemory()。


顺便说一句,128 是我最喜欢的数字。我今天在 128 街道号参加了一个 session ,演讲者引用了 128 页上的一本书;)

最佳答案

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

-Xmx 标志,如 docs 中所述,控制内存分配池的最大大小。 memory allocation pool 的堆部分分为 Eden、Survivor 和 Tenured 空间。如 this answer 中所述,有两个幸存者区域,其中只有一个可用于在任何给定时间点保存 Activity 对象。因此,Runtime.maxMemory() 报告的可用于分配对象的总表观空间必须从总堆内存池中减去幸存空间之一的大小。

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

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()));
    }
  }
}

java -Xmx1024m MemTest 在 OpenJDK 7 上的输出是:

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 之间观察到的差异可能是由于选择不同代的默认相对大小的不同启发式方法。如 this article 中所述(适用于 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 报告的给定命令行参数集的可用内存,这正是您真正想要的,对吧?

关于java - 为什么 -Xmx 和 Runtime.maxMemory 不一致,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/23701207/

相关文章:

php - PHP中有垃圾收集吗?

java - 如果我们发布代码中包含Javadoc的sources.jar,那么发布javadoc.jar不是重复的吗?

java - 电话号码状态比较不正确?

ios - 内存管理 iOS 开发应用程序在一些细节项目后不起作用

android - android函数内部泄漏 'setTextColor'

C# - 应用程序内存问题

java - 测量线程锁定监视器的时间

java - OnClick 后 Activity 关闭

java - 引用队列的含义

garbage-collection - 防止 CLR 中早期垃圾回收的最佳方法