为什么-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页的一本书;）
差异似乎是由垃圾收集器的幸存空间的大小来解释的。
如文档中所述， -Xmx标志控制内存分配池的最大大小。 内存分配池的堆部分分为Eden，Survivor和Tenured空间。 如本回答所述 ，有两个幸存者区域，其中只有一个可用于在任何给定时间点保存活动对象。 因此， 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 for 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，使用上述程序进行validation。 现在，您应该能够准确地预测Runtime针对给定的一组命令行参数报告的可用内存，这是您真正想要的，对吧？