Windows XP 上的 Java 最大内存

Java maximum memory on Windows XP

提问by Steve Kuo

I've always been able to allocate 1400 megabytes for Java SE running on 32-bit Windows XP (Java 1.4, 1.5 and 1.6).

我总是能够为在 32 位 Windows XP（Java 1.4、1.5 和 1.6）上运行的 Java SE 分配 1400 MB。

java -Xmx1400m ...

Today I tried the same option on a new Windows XP machine using Java 1.5_16 and 1.6.0_07 and got the error:

今天，我在使用 Java 1.5_16 和 1.6.0_07 的新 Windows XP 机器上尝试了相同的选项，但出现错误：

Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.

Through trial and error it seems 1200 megabytes is the most I can allocate on this machine.

通过反复试验，似乎 1200 兆字节是我可以在这台机器上分配的最大容量。

Any ideas why one machine would allow 1400 and another only 1200?

为什么一台机器允许 1400 而另一台只允许 1200 的任何想法？

Edit: The machine has 4GB of RAM with about 3.5GB that Windows can recognize.

编辑：该机器有 4GB 的 RAM，Windows 可以识别大约 3.5GB。

采纳答案by Christopher Smith

Keep in mind that Windows has virtual memory management and the JVM only needs memory that is contiguous in its address space. So, other programs running on the system shouldn't necessarily impact your heap size. What will get in your way are DLL's that get loaded in to your address space. Unfortunately optimizations in Windows that minimize the relocation of DLL's during linking make it more likely you'll have a fragmented address space. Things that are likely to cut in to your address space aside from the usual stuff include security software, CBT software, spyware and other forms of malware. Likely causes of the variances are different security patches, C runtime versions, etc. Device drivers and other kernel bits have their own address space (the other 2GB of the 4GB 32-bit space).

请记住，Windows 具有虚拟内存管理，而 JVM 只需要在其地址空间中连续的内存。因此，系统上运行的其他程序不一定会影响您的堆大小。会妨碍您的是加载到您的地址空间中的 DLL。不幸的是，Windows 中在链接期间最小化 DLL 重定位的优化使您更有可能拥有碎片化的地址空间。除了通常的东西之外，可能会切入您的地址空间的东西包括安全软件、CBT 软件、间谍软件和其他形式的恶意软件。差异的可能原因是不同的安全补丁、C 运行时版本等。设备驱动程序和其他内核位有自己的地址空间（4GB 32 位空间中的其他 2GB）。

You couldtry going through your DLL bindings in your JVM process and look at trying to rebase your DLL's in to a more compact address space. Not fun, but if you are desperate...

您可以尝试在 JVM 进程中检查 DLL 绑定，并尝试将 DLL 重新定位到更紧凑的地址空间。不好玩，但如果你绝望了……

Alternatively, you can just switch to 64-bit Windows and a 64-bit JVM. Despite what others have suggested, while it will chew up more RAM, you will have muchmore contiguous virtual address space, and allocating 2GB contiguously would be trivial.

或者，您可以只切换到 64 位 Windows 和 64 位 JVM。不管别人怎么建议，同时将咀嚼更多的内存，您将有很多更连续虚拟地址空间，并分配2GB连续将是微不足道的。

回答by James A. N. Stauffer

The JVM needs contiguous memory and depending on what else is running, what was running before, and how windows has managed memory you may be able to get up to 1.4GB of contiguous memory. I think 64bit Windows will allow larger heaps.

JVM 需要连续内存，根据其他正在运行的内容、之前运行的内容以及 Windows 管理内存的方式，您最多可以获得 1.4GB 的连续内存。我认为 64 位 Windows 将允许更大的堆。

回答by anjanb

sun's JDK/JRE needs a contiguous amount of memory if you allocate a huge block.

如果您分配一个巨大的块，sun 的 JDK/JRE 需要连续的内存量。

The OS and initial apps tend to allocate bits and pieces during loading which fragments the available RAM. If a contiguous block is NOT available, the SUN JDK cannot use it. JRockit from Bea(acquired by Oracle) can allocate memory from pieces.

操作系统和初始应用程序倾向于在加载过程中分配一些零碎的东西，从而将可用 RAM 碎片化。如果连续块不可用，则 SUN JDK 无法使用它。Bea 的 JRockit（被 Oracle 收购）可以从碎片中分配内存。

回答by Steve Kuo

I think it has more to do with how Windows is configured as hinted by this response: Java -Xmx Option

我认为这与此响应所暗示的 Windows 配置方式有更多关系： Java -Xmx Option

Some more testing: I was able to allocate 1300MB on an old Windows XP machine with only 768MB physical RAM (plus virtual memory). On my 2GB RAM machine I can only get 1220MB. On various other corporate machines (with older Windows XP) I was able to get 1400MB. The machine with a 1220MB limit is pretty new (just purchased from Dell), so maybe it has newer (and more bloated) Windows and DLLs (it's running Window XP Pro Version 2002 SP2).

更多测试：我能够在只有 768MB 物理 RAM（加上虚拟内存）的旧 Windows XP 机器上分配 1300MB。在我的 2GB RAM 机器上，我只能获得 1220MB。在其他各种公司机器（使用较旧的 Windows XP）上，我能够获得 1400MB。具有 1220MB 限制的机器是相当新的（刚从戴尔购买），因此它可能具有更新（并且更加臃肿）的 Windows 和 DLL（它运行的是 Window XP Pro Version 2002 SP2）。

回答by the.duckman

Sun's JVM needs contiguous memory. So the maximal amount of available memory is dictated by memory fragmentation. Especially driver's dlls tend to fragment the memory, when loading into some predefined base address. So your hardware and its drivers determine how much memory you can get.

Sun 的 JVM 需要连续的内存。因此，可用内存的最大数量由内存碎片决定。尤其是驱动程序的 dll 在加载到某个预定义的基地址时往往会导致内存碎片化。因此，您的硬件及其驱动程序决定了您可以获得多少内存。

Two sources for this with statements from Sun engineers: forumblog

来自 Sun 工程师的声明的两个来源：论坛博客

Maybe another JVM? Have you tried Harmony? I think they planned to allow non-continuous memory.

也许另一个JVM？你试过和谐吗？我认为他们计划允许非连续内存。

回答by Uri

This has to do with contiguous memory.

这与连续内存有关。

Here's some info I found onlinefor somebody asking that before, supposedly from a "VM god":

这是我在网上找到的一些信息，之前有人问过这个问题，据说来自“VM 大神”：

The reason we need a contiguous memory region for the heap is that we have a bunch of side data structures that are indexed by (scaled) offsets from the start of the heap. For example, we track object reference updates with a "card mark array" that has one byte for each 512 bytes of heap. When we store a reference in the heap we have to mark the corresponding byte in the card mark array. We right shift the destination address of the store and use that to index the card mark array. Fun addressing arithmetic games you can't do in Java that you get to (have to :-) play in C++.

Usually we don't have trouble getting modest contiguous regions (up to about 1.5GB on Windohs, up to about 3.8GB on Solaris. YMMV.). On Windohs, the problem is mostly that there are some libraries that get loaded before the JVM starts up that break up the address space. Using the /3GB switch won't rebase those libraries, so they are still a problem for us.

We know how to make chunked heaps, but there would be some overhead to using them. We have more requests for faster storage management than we do for larger heaps in the 32-bit JVM. If you really want large heaps, switch to the 64-bit JVM. We still need contiguous memory, but it's much easier to get in a 64-bit address space.

我们需要一个连续的堆内存区域的原因是我们有一堆侧面数据结构，这些数据结构由从堆开始的（缩放的）偏移量索引。例如，我们使用“卡片标记数组”跟踪对象引用更新，该数组每 512 字节堆有一个字节。当我们在堆中存储一个引用时，我们必须在卡片标记数组中标记相应的字节。我们右移商店的目标地址并使用它来索引卡片标记数组。有趣的算术游戏，你不能用 Java 做，但你可以（必须:-) 用 C++ 玩。

通常我们在获取适度的连续区域时没有问题（在 Windows 上最多约 1.5GB，在 Solaris 上最多约 3.8GB。YMMV。）。在 Windohs 上，问题主要是在 JVM 启动之前加载了一些库，这些库破坏了地址空间。使用 /3GB 开关不会改变这些库的基础，所以它们对我们来说仍然是一个问题。

我们知道如何制作分块堆，但使用它们会有一些开销。与 32 位 JVM 中更大的堆相比，我们对更快的存储管理的请求更多。如果您真的想要大堆，请切换到 64 位 JVM。我们仍然需要连续的内存，但进入 64 位地址空间要容易得多。

回答by MicSim

The Java heap size limits for Windows are:

Windows 的 Java 堆大小限制是：

• maximumpossible heap size on 32-bit Java: 1.8 GB
• recommendedheap size limit on 32-bit Java: 1.5 GB(or 1.8 GBwith /3GB option)

• 32 位 Java 上的最大可能堆大小：1.8 GB
• 32 位 Java 上的推荐堆大小限制：1.5 GB（或1.8 GB，带 /3GB 选项）

This doesn't help you getting a bigger Java heap, but now you know you can't go beyond these values.

这不会帮助您获得更大的 Java 堆，但现在您知道您无法超越这些值。

回答by Kire Haglin

Oracle JRockit, which can handle a non-contiguous heap, can have a Java heap size of 2.85 GB on Windows 2003/XP with the /3GB switch. It seems that fragmentation can have quite an impact on how large a Java heap can be.

Oracle JRockit可以处理非连续堆，在 Windows 2003/XP 上使用 /3GB 开关可以拥有 2.85 GB 的 Java 堆大小。似乎碎片可以对 Java 堆的大小产生相当大的影响。

回答by user17544

First, using a page-file when you have 4 GB of RAM is useless. Windows can't access more than 4GB (actually, less because of memory holes) so the page file is not used.

首先，当您有 4 GB 的 RAM 时使用页面文件是没有用的。Windows 无法访问超过 4GB（实际上，由于内存漏洞而减少），因此不使用页面文件。

Second, the address space is split in 2, half for kernel, half for user mode. If you need more RAM for your applications use the /3GB option in boot.ini (make sure java.exe is marked as "large address aware" (google for more info).

其次，地址空间被分成2部分，一半用于内核，一半用于用户模式。如果您的应用程序需要更多 RAM，请使用 boot.ini 中的 /3GB 选项（确保 java.exe 被标记为“大地址识别”（谷歌了解更多信息）。

Third, I think you can't allocate the full 2 GB of address space because java wastes some memory internally (for threads, JIT compiler, VM initialization, etc). Use the /3GB switch for more.

第三，我认为您不能分配完整的 2 GB 地址空间，因为 java 在内部浪费了一些内存（对于线程、JIT 编译器、VM 初始化等）。使用 /3GB 开关获取更多信息。

回答by William Denniss

I got this error message when running a java program from a (limited memory) virtuozzo VPS. I had not specified any memory arguments, and found I had to explicitly set a smallamount as the default must have been too high. E.g. -Xmx32m (obviously needs to be tuned depending on the program you run).

从（有限内存）virtuozzo VPS 运行 java 程序时，我收到此错误消息。我没有指定任何内存参数，发现我必须显式设置一个小数量，因为默认值一定太高了。例如 -Xmx32m（显然需要根据您运行的程序进行调整）。

Just putting this here in case anyone else gets the above error message without specifying a large amount of memory like the questioner did.

只需将其放在这里，以防其他人收到上述错误消息，而没有像提问者那样指定大量内存。