Java 32bit Xmx vs java 64bit Xmx [英] Java 32bit Xmx vs java 64bit Xmx

问题描述

我对此非常困惑。



Xmx根据java文档，是允许的最大堆大小。

Xms是最小所需的Java堆大小，并在JVM启动时分配。



在32位JVM（4GB ram）上，java -Xmx1536M HelloWorld给出了一个无法分配足够的内存错误。$
在64位JVM（4GB Ram）上，java -Xmx20G HelloWorld工作得很好。但是我甚至没有分配那么多的虚拟或物理内存。
b


因此，我得出结论，Java 32位在JVM启动时分配1536M，但是Java 64位不是。



为什么？一个简单的Hello World不需要运行1536M。我只是指定1536M是最大值，而不是它需要。



解释任何人？

I am really confused with this.

Xmx according to the java docs, is the maximum allowable heap size.
Xms is the minimum required java heap size, and is allocated at JVM start.

On a 32 bit JVM (4GB ram), java -Xmx1536M HelloWorld gives a cannot allocate enough memory error.
On a 64 bit JVM (4GB Ram), java -Xmx20G HelloWorld works just fine. But I don't even have that much virtual or physical memory allocated.

So from this, I conclude that Java 32 bit is allocating the 1536M at JVM startup, but Java 64 bit is not.

Why? A simple Hello World should not need 1536M to run. I am just specifying that 1536M is the maximum, not that it is needed.

Explanations anyone?

推荐答案

分配内存和分配地址空间之间存在区别。 Oracle JVM在启动时分配地址空间以确保堆是连续的。这允许对堆使用某些优化。

There is a distinction between allocating the memory and allocating the address space. The Oracle JVM is allocating the address space on startup to ensure the heap is contiguous. This allows for certain optimizations to be used with the heap.

如果分配失败，那么Java将无法启动......正如您所见。它不一定使用那么多内存，而是预先分配所需的地址空间。由于你传递了 -Xmx1536m ，它说好了，我需要分配它以防你需要它...因为它必须是连续的，所以它是预先做的所以它可以保证它（或尝试失败）。

If the allocation fails, then Java won't start... as you have seen. It isn't necessarily using that much memory, but it is allocating the required address space up-front. Since you are passing -Xmx1536m, it is saying ok, I need to allocate that in case you need it... and since it must be contiguous it does it up-front so it can guarantee it (or fails trying).

这种行为在32位和64位JVM上是相同的。您所看到的是32位进程的2GB每进程地址空间限制（至少，在Windows上这是限制 - 在其他平台上可能略大）导致此分配在32位上失败，其中64 -bit没有问题，因为它有更大的地址空间。但是，你说，1536米不到2GB，我应该好，对吧？不完全 - 堆不是在地址空间中分配的唯一东西，DLL和其他东西也分配在地址空间中......所以不幸的是，在32位上从2GB最大值获得连续的1536m块是不太可能的。我看到低于1000m的值在32位进程上失败，碎片特别糟糕，通常1200-1300m是你可以在32位上指定的最大堆。

This behavior is the same on both 32-bit and 64-bit JVMs. What you are seeing is the 2GB per-process address space limitation of 32-bit processes (at least, on Windows this is the limitation - it may be slightly larger on other platforms) causing this allocation to fail on 32-bit, where 64-bit has no issues since it has much larger address space. But, you say, 1536m is less than 2GB, I should be good, right? Not quite - the heap is not the only thing being allocated in the address space, DLLs and other stuff is also allocated in the address space...so getting a contiguous 1536m chunk out of 2GB max on 32-bit is unfortunately very unlikely. I've seen values below 1000m fail on 32-bit processes with particularly bad fragmentation, and usually 1200-1300m is the max heap you can specify on 32-bit.

在现代操作系统上， ASLR （地址空间布局随机化）使32位进程地址空间的碎片变得更糟。出于安全原因，它故意将DLL加载到随机地址中...使得它甚至不太可能在32位中获得大的连续堆。

On modern OSes, ASLR (Address Space Layout Randomization) makes fragmentation of 32-bit process address space worse. It intentionally loads DLLs into random addresses for security reasons... making it even less likely you can get a big, contiguous heap in 32-bit.

在64位中，地址空间非常大，碎片不再是问题，可以毫无问题地分配巨型堆。即使你在32位上有4GB的RAM，但每个进程2GB的地址空间限制（至少在Windows上）通常意味着最大堆通常只有1300m左右。

In 64-bit, the address space is so large that fragmentation is no longer a problem and giant heaps can be allocated without issues. Even if you have 4GB of RAM on 32-bit, though, the 2GB per process address space limitation (at least on Windows) usually means the max heap is usually only 1300m or so.

这篇关于Java 32bit Xmx vs java 64bit Xmx的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！