64 位操作系统上 32 位 JVM 的最大 Java 堆大小

Maximum Java heap size of a 32-bit JVM on a 64-bit OS

提问by Vineet Reynolds

The question is not about the maximum heap size on a 32-bit OS, given that 32-bit OSes have a maximum addressable memory size of 4GB, and that the JVM's max heap size depends on how much contiguous free memory can be reserved.

问题不在于 32 位操作系统上的最大堆大小，因为 32 位操作系统的最大可寻址内存大小为 4GB，并且 JVM 的最大堆大小取决于可以保留多少连续空闲内存。

I'm more interested in knowing the maximum (both theoretical and practically achievable) heap size for a 32-bit JVM running in a 64-bit OS. Basically, I'm looking at answers similar to the figures in a related question on SO.

我更想知道在 64 位操作系统中运行的 32 位 JVM 的最大（理论和实际可实现的）堆大小。基本上，我正在查看与 SO 相关问题中的数字类似的答案。

As to why a 32-bit JVM is used instead of a 64-bit one, the reason is not technical but rather administrative/bureaucratic - it is probably too late to install a 64-bit JVM in the production environment.

至于为什么使用 32 位 JVM 而不是 64 位 JVM，原因不是技术而是管理/官僚主义 - 在生产环境中安装 64 位 JVM 可能为时已晚。

采纳答案by Thorbj?rn Ravn Andersen

32-bit JVMs which expect to have a single large chunk of memory and use raw pointers cannot use more than 4 Gb (since that is the 32 bit limit which also applies to pointers). This includes Sun and - I'm pretty sure - also IBM implementations. I do not know if e.g. JRockit or others have a large memory option with their 32-bit implementations.

32 位 JVM 期望拥有单个大内存块并使用原始指针，不能使用超过 4 Gb（因为 32 位限制也适用于指针）。这包括 Sun 和 - 我很确定 - 还有 IBM 实现。我不知道例如 JRockit 或其他人是否在他们的 32 位实现中有一个大内存选项。

If you expect to be hitting this limit you should strongly consider starting a parallel track validating a 64-bit JVM for your production environment so you have that ready for when the 32-bit environment breaks down. Otherwise you will have to do that work under pressure, which is never nice.

如果您希望达到此限制，您应该强烈考虑启动一个并行跟踪，为您的生产环境验证 64 位 JVM，以便在 32 位环境崩溃时做好准备。否则，您将不得不在压力下完成这项工作，这绝不是好事。

---

---

Edit 2014-05-15: Oracle FAQ:

编辑 2014-05-15：Oracle 常见问题解答：

The maximum theoretical heap limit for the 32-bit JVM is 4G. Due to various additional constraints such as available swap, kernel address space usage, memory fragmentation, and VM overhead, in practice the limit can be much lower. On most modern 32-bit Windows systems the maximum heap size will range from 1.4G to 1.6G. On 32-bit Solaris kernels the address space is limited to 2G. On 64-bit operating systems running the 32-bit VM, the max heap size can be higher, approaching 4G on many Solaris systems.

32 位 JVM 的最大理论堆限制为 4G。由于可用交换、内核地址空间使用、内存碎片和 VM 开销等各种附加限制，实际上限制可能要低得多。在大多数现代 32 位 Windows 系统上，最大堆大小范围为 1.4G 到 1.6G。在 32 位 Solaris 内核上，地址空间限制为 2G。在运行 32 位 VM 的 64 位操作系统上，最大堆大小可以更高，在许多 Solaris 系统上接近 4G。

(http://www.oracle.com/technetwork/java/hotspotfaq-138619.html#gc_heap_32bit)

( http://www.oracle.com/technetwork/java/hotspotfaq-138619.html#gc_heap_32bit)

回答by Laurence Gonsalves

The limitations of a 32-bit JVM on a 64-bit OS will be exactly the same as the limitations of a 32-bit JVM on a 32-bit OS. After all, the 32-bit JVM will be running In a 32-bit virtual machine (in the virtualization sense) so it won't know that it's running on a 64-bit OS/machine.

32 位 JVM 在 64 位操作系统上的限制与 32 位 JVM 在 32 位操作系统上的限制完全相同。毕竟，32 位 JVM 将在 32 位虚拟机中运行（在虚拟化意义上），因此它不会知道它正在 64 位操作系统/机器上运行。

The one advantage to running a 32-bit JVM on a 64-bit OS versus a 32-bit OS is that you can have more physical memory, and therefore will encounter swapping/paging less frequently. This advantage is only really fully realized when you have multiple processes, however.

与 32 位操作系统相比，在 64 位操作系统上运行 32 位 JVM 的一个优势是您可以拥有更多的物理内存，因此不会经常遇到交换/分页。然而，只有当您有多个进程时，才能真正充分实现这一优势。

回答by Fortyrunner

You don't specify whichOS.

您没有指定哪个操作系统。

Under Windows (for my application - a long running risk management application) we observed that we could go no further than 1280MB on Windows 32bit. I doubt that running a 32bit JVM under 64bit would make any difference.

在 Windows 下（对于我的应用程序 - 一个长期运行的风险管理应用程序），我们观察到在 Windows 32 位上我们不能超过 1280MB。我怀疑在 64 位下运行 32 位 JVM 会有什么不同。

We ported the app to Linux and we are running a 32bit JVM on 64bit hardware and have had a 2.2GB VM running pretty easily.

我们将应用程序移植到 Linux，我们在 64 位硬件上运行 32 位 JVM，并且有一个 2.2GB 的 VM 很容易运行。

The biggest problem you may have is GC depending on what you are using memory for.

您可能遇到的最大问题是 GC，具体取决于您使用内存的目的。

回答by DigitalRoss

Should be a lot better

应该会好很多

For a 32-bit JVM running on a 64-bit host, I imagine what's left over for the heap will be whatever unfragmented virtual space is available after the JVM, it's own DLL's, and any OS 32-bit compatibility stuff has been loaded. As a wild guess I would think 3GB should be possible, but how much better that is depends on how well you are doing in 32-bit-host-land.

对于在 64 位主机上运行的 32 位 JVM，我想堆剩下的将是 JVM 之后可用的任何未碎片化的虚拟空间、它自己的 DLL 以及任何 OS 32 位兼容性内容已加载。作为一个疯狂的猜测，我认为 3GB 应该是可能的，但是这有多好取决于您在 32 位主机领域的表现如何。

Also, even if you could make a giant 3GB heap, you might not want to, as this will cause GC pauses to become potentially troublesome. Some people just run more JVM's to use the extra memory rather than one giant one. I imagine they are tuning the JVM's right now to work better with giant heaps.

此外，即使您可以制作一个巨大的 3GB 堆，您也可能不想这样做，因为这会导致 GC 暂停变得潜在的麻烦。有些人只是运行更多的 JVM 来使用额外的内存而不是一个巨大的内存。我想他们现在正在调整 JVM 以更好地处理巨大的堆。

It's a little hard to know exactly how much better you can do. I guess your 32-bit situation can be easily determined by experiment. It's certainly hard to predict abstractly, as a lot of things factor into it, particularly because the virtual space available on 32-bit hosts is rather constrained.. The heap does need to exist in contiguous virtual memory, so fragmentation of the address space for dll's and internal use of the address space by the OS kernel will determine the range of possible allocations.

确切地知道你能做得多好有点困难。我想您的 32 位情况可以通过实验轻松确定。当然很难抽象地预测，因为有很多因素会影响到它，特别是因为 32 位主机上可用的虚拟空间相当有限......堆确实需要存在于连续的虚拟内存中，因此地址空间的碎片化dll 和 OS 内核对地址空间的内部使用将决定可能的分配范围。

The OS will be using some of the address space for mapping HW devices and it's own dynamic allocations. While this memory is not mapped into the java process address space, the OS kernel can't access it and your address space at the same time, so it will limit the size of any program's virtual space.

操作系统将使用一些地址空间来映射硬件设备及其自己的动态分配。虽然这个内存没有映射到 java 进程地址空间，但操作系统内核不能同时访问它和你的地址空间，所以它会限制任何程序的虚拟空间的大小。

Loading DLL's depends on the implementation and the release of the JVM. Loading the OS kernel depends on a huge number of things, the release, the HW, how many things it has mapped so far since the last reboot, who knows...

加载 DLL 取决于 JVM 的实现和版本。加载操作系统内核取决于很多事情，版本，硬件，自上次重启以来它映射了多少东西，谁知道......

In summary

总之

I bet you get 1-2 GB in 32-bit-land, and about 3 in 64-bit, so an overall improvement of about 2x.

我敢打赌，您在 32 位域中获得 1-2 GB，在 64 位中获得大约 3 GB，因此总体改进约为2倍。

回答by Priya

I have tried setting the heap size upto 2200M on 32bit Linux machine and JVM worked fine. The JVM didnt start when I set it to 2300M.

我尝试在 32 位 Linux 机器上将堆大小设置为 2200M，JVM 运行良好。当我将其设置为 2300M 时，JVM 没有启动。

回答by djangofan

From 4.1.2 Heap Sizing:

从4.1.2 堆大小：

"For a 32-bit process model, the maximum virtual address size of the process is typically 4 GB, though some operating systems limit this to 2 GB or 3 GB. The maximum heap size is typically -Xmx3800m (1600m) for 2 GB limits), though the actual limitation is application dependent. For 64-bit process models, the maximum is essentially unlimited."

“对于 32 位进程模型，进程的最大虚拟地址大小通常为 4 GB，尽管某些操作系统将其限制为 2 GB 或 3 GB。对于 2 GB 限制，最大堆大小通常为 -Xmx3800m (1600m) )，尽管实际限制取决于应用程序。对于 64 位进程模型，最大值基本上是无限的。”

Found a pretty good answer here: Java maximum memory on Windows XP.

在这里找到了一个很好的答案：Windows XP 上的 Java 最大内存。

回答by Peter Lawrey

On Solaris the limit has been about 3.5 GB since Solaris 2.5. (about 10 years ago)

在 Solaris 上，自 Solaris 2.5 以来，限制约为 3.5 GB。（大约 10 年前）

回答by chinto

We recently had some experience with this. We have ported from Solaris (x86-64 Version 5.10) to Linux (RedHat x86-64) recently and have realized that we have less memory available for a 32 bit JVM process on Linux than Solaris.

我们最近在这方面有一些经验。我们最近已从 Solaris（x86-64 版本 5.10）移植到 Linux（RedHat x86-64），并意识到 Linux 上的 32 位 JVM 进程可用内存少于 Solaris。

For Solaris this almost comes around to 4GB (http://www.oracle.com/technetwork/java/hotspotfaq-138619.html#gc_heap_32bit).

对于 Solaris，这几乎达到 4GB (http://www.oracle.com/technetwork/java/hotspotfaq-138619.html#gc_heap_32bit)。

We ran our app with -Xms2560m -Xmx2560m -XX:MaxPermSize=512m -XX:PermSize=512mwith no issues on Solaris for past couple of years. Tried to move it to linux and we had issues with random out of memory errors on start up. We could only get it to consistently start up on -Xms2300 -Xmx2300. Then we were advised of this by support.

我们使用-Xms2560m -Xmx2560m -XX:MaxPermSize=512m -XX:PermSize=512m运行我们的应用程序，过去几年在 Solaris 上没有问题。试图将其移至 linux，但我们在启动时遇到了随机内存不足错误的问题。我们只能让它在-Xms2300 -Xmx2300上持续启动。然后我们被支持者告知了这一点。

A 32 bit process on Linux has a maximum addressable address space of 3gb (3072mb) whereas on Solaris it is the full 4gb (4096mb).

Linux 上的 32 位进程的最大可寻址地址空间为 3gb (3072mb)，而在 Solaris 上它是完整的 4gb (4096mb)。

回答by mike

You can ask the Java Runtime:

您可以询问 Java 运行时：

public class MaxMemory {
    public static void main(String[] args) {
        Runtime rt = Runtime.getRuntime();
        long totalMem = rt.totalMemory();
        long maxMem = rt.maxMemory();
        long freeMem = rt.freeMemory();
        double megs = 1048576.0;

        System.out.println ("Total Memory: " + totalMem + " (" + (totalMem/megs) + " MiB)");
        System.out.println ("Max Memory:   " + maxMem + " (" + (maxMem/megs) + " MiB)");
        System.out.println ("Free Memory:  " + freeMem + " (" + (freeMem/megs) + " MiB)");
    }
}

This will report the "Max Memory" based upon default heap allocation. So you still would need to play with -Xmx(on HotSpot). I found that running on Windows 7 Enterprise 64-bit, my 32-bitHotSpot JVM can allocate up to 1577MiB:

这将报告基于默认堆分配的“最大内存”。所以你仍然需要玩-Xmx（在HotSpot 上）。我发现在 64 位 Windows 7 Enterprise 上运行时，我的32 位HotSpot JVM 最多可以分配 1577MiB：

[C:scratch]> java -Xmx1600M MaxMemory
Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.
[C:scratch]> java -Xmx1590M MaxMemory
Total Memory: 2031616 (1.9375 MiB)
Max Memory:   1654456320 (1577.8125 MiB)
Free Memory:  1840872 (1.75559234619 MiB)
[C:scratch]>

Whereas with a 64-bitJVM on the same OS, of course it's much higher (about 3TiB)

而在同一操作系统上使用64 位JVM，当然要高得多（大约 3TiB）

[C:scratch]> java -Xmx3560G MaxMemory
Error occurred during initialization of VM
Could not reserve enough space for object heap
[C:scratch]> java -Xmx3550G MaxMemory
Total Memory: 94240768 (89.875 MiB)
Max Memory:   3388252028928 (3184151.84297 MiB)
Free Memory:  93747752 (89.4048233032 MiB)
[C:scratch]>

As others have already mentioned, it depends on the OS.

正如其他人已经提到的，这取决于操作系统。

• For 32-bit Windows: it'll be <2GB (Windows internals booksays 2GB for user processes)
• For 32-bit BSD / Linux: <3GB (from the Devil Book)
• For 32-bit MacOS X: <4GB (from Mac OS X internalsbook)
• Not sure about 32-bit Solaris, try the above code and let us know.

• 对于 32 位 Windows：它将小于 2GB（Windows 内部手册说 2GB 用于用户进程）
• 对于 32 位 BSD/Linux：<3GB（来自魔鬼书）
• 对于 32 位 MacOS X：<4GB（来自Mac OS X 内部手册）
• 不确定 32 位 Solaris，试试上面的代码，让我们知道。

For a 64-bit host OS, if the JVM is 32-bit, it'll still depend, most likely like above as demonstrated.

对于 64 位主机操作系统，如果 JVM 是 32 位，它仍然会依赖，很可能像上面演示的那样。

-- UPDATE 20110905: I just wanted to point out some other observations / details:

-- UPDATE 20110905：我只是想指出一些其他的观察/细节：

• The hardware that I ran this on was 64-bit with 6GB of actual RAM installed. The operating system was Windows 7 Enterprise, 64-bit
• The actual amount of Runtime.MaxMemorythat can be allocated also depends on the operating system's working set. I once ran this while I also had VirtualBox running and found I could notsuccessfully start the HotSpot JVM with -Xmx1590Mand had to go smaller. This also implies that you may get more than 1590M depending upon your working set size at the time (though I still maintain it'll be under 2GiB for 32-bit because of Windows' design)

• 我运行它的硬件是 64 位的，安装了 6GB 的实际 RAM。操作系统为 Windows 7 Enterprise，64 位
• Runtime.MaxMemory可以分配的实际数量还取决于操作系统的工作集。我曾经运行过这个，同时我也运行了 VirtualBox，发现我无法成功启动 HotSpot JVM，不得不变-Xmx1590M小。这也意味着您可能会获得超过 1590M 的空间，具体取决于您当时的工作集大小（尽管我仍然认为 32 位由于 Windows 的设计，它会低于 2GiB）

回答by Dale

The JROCKIT JVM currently owned by Oracle supports non-contiguous heap usage, thus allowing the 32 bit JVM to access more then 3.8 GB of memory when the JVM is running on a 64 bit windows OS. (2.8 GB when running on a 32 bit OS).

Oracle 当前拥有的 JROCKIT JVM 支持非连续堆使用，因此当 JVM 在 64 位 Windows 操作系统上运行时，允许 32 位 JVM 访问超过 3.8 GB 的内存。（在 32 位操作系统上运行时为 2.8 GB）。

http://blogs.oracle.com/jrockit/entry/how_to_get_almost_3_gb_heap_on_windows

http://blogs.oracle.com/jrockit/entry/how_to_get_almost_3_gb_heap_on_windows

The JVM can be freely downloaded (registration required) at

JVM 可以在以下网址免费下载（需要注册）

http://www.oracle.com/technetwork/middleware/jrockit/downloads/index.html

http://www.oracle.com/technetwork/middleware/jrockit/downloads/index.html