32 位操作系统上的 JVM 堆大小
我使用的是 32 位 win.7 并使用 Eclipse。还有 4GB 内存。
我想为我的 java 应用程序分配大约 3 GB 的最大堆大小，但我可以通过 VM 参数 -Xmx1056m 分配最大 1.5GB。
我应该怎么办？如果我安装64位win.7。那么它能够为我的应用程序分配 3GB 堆大小吗？
I am using 32 bit win.7 and using Eclipse. Also having 4GB RAM.
I want to allocate my java application a maximum heapsize of around 3 GB, but I am able to allocate maximum 1.5GB through VM arguments -Xmx1056m.
What should I do? If I Install a 64 bit win.7. it would be able then to allocate 3GB heapsize to my app?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
即使您有更多可用内存，常规 32 位 Windows 进程也只能寻址 2GB 内存。您可以在此处找到不同 Windows 版本的内存限制。
由于虚拟机需要的内存不仅仅是堆，因此最大堆大小将略小于进程可用的最大内存。通常，您可以将 32 位 Windows VM 的堆调整到 1.6GB 左右。
A regular 32-bit Windows process can only address 2GB of memory, even if you have more memory available. You can find the memory limits for different Windows versions here.
Since the VM need memory for more things than just the heap, the max heap size will be slightly less than the maxmimum memory available to the process. Usually, you can tweak the heap up to around 1.6GB for a 32-bit Windows VM.
您需要 64 位操作系统和 64 位 VM 来分配这么多 RAM。
You need a 64bit OS and 64bit VM to allocate this much RAM.
我现在没有描述 JVM 内存管理过程的链接。您偶然发现的限制是 Java 执行垃圾收集方式的限制。 Java 内存堆必须是连续的块。垃圾收集算法针对此设计限制进行了优化，因此可以高效执行。在 32 位操作系统中，您无法控制设备驱动程序加载到的内存地址。在 Windows 上，如果 DLL 中存储的设备驱动程序基地址与已加载的代码冲突，操作系统只会重新分配它。其他操作系统可能会在加载时重新分配所有设备驱动程序，以便它们位于内核附近的连续块中。
基本上，64 位和 32 位操作系统的限制是相同的。只是在 64 位操作系统上还有几个地址范围可供选择。确保您使用 64 位 JVM 来匹配操作系统。这就是为什么 64 位操作系统能够比 32 位操作系统找到更大的连续内存地址块。
编辑：此外，32 位 JVM 的最大堆大小限制为 2GB。
参考：
http://publib.boulder.ibm.com/infocenter/javasdk/tools/index.jsp?topic=/com.ibm.java.doc.igaa/_1vg00014884d287 -11c3fb28dae-7ff6_1001.html
Windows XP 上的 Java 最大内存
http://forums.sun.com/thread.jspa?messageID=2715152# 2715152
I don't have the link right now that describes the JVM memory management process. The limitation you have stumbled upon is a limitation of how Java performs garbage collection. The Java memory heap must be a contigious block. The garbage collection algorithms were optimized for this design limitation so they can perform efficiently. In a 32bit operating system, you are not in control of what memory addresses device drivers are loaded into. On Windows, the OS will only reallocate the device driver base address stored in the DLL if it conflicts with an already loaded code. Other operating systems may reallocate all device drivers on load so they live in a contiguous block near the kernel.
Basically, the limitation is the same for 64bit and 32bit operating systems. It's just on a 64bit OS there are several more address ranges to choose from. Make sure you use a 64bit JVM to match the OS. That's why the 64bit OS is able to find a larger contigious block of memory addresses than the 32bit OS.
EDIT: Additionally the 32bit JVM has a max heap size limit of 2GB.
REFERENCE:
http://publib.boulder.ibm.com/infocenter/javasdk/tools/index.jsp?topic=/com.ibm.java.doc.igaa/_1vg00014884d287-11c3fb28dae-7ff6_1001.html
Java maximum memory on Windows XP
http://forums.sun.com/thread.jspa?messageID=2715152#2715152
您需要的不仅是 64 位操作系统和 64 位虚拟机，还需要更多内存。
在 32 位 Windows 系统上，虚拟地址空间分为 2 GB 用于内核操作和 2 GB 用于用户应用程序。所以你完蛋了。
有一种可能但不太可能的解决方法：您可以启用 /3GB 开关提高此限制，让系统为内核操作分配 1GB 虚拟地址空间，为用户应用程序分配 3GB 虚拟地址空间（如果它们是 /LARGEADDRESSPACEAWARE)。
不幸的是，32 位 Sun/Oracle HotSpot JVM 不是 LARGEADDRESSAWARE（据我所知），其他 32 位 JVM 可能也不是。
但想一想：即使您能够做到这一点，您也会使用系统可用的所有内存。为 JVM 分配 3GB 堆后，不会再为其他程序留下任何内容。您的系统将一直交换到磁盘。它将无法使用。
只需购买具有更多 RAM 的 64bis 操作系统即可。这就是您的全部内容，缺少找到让您的程序使用更少内存的方法。
What you will need is not only a 64bit OS and a 64bit VM, but also more memory.
On a 32bits Windows system the virtual address space is split with 2 GB for kernel operations and 2 GB for user applications. So you're screwed.
There's one possible but very unlikely workaround: you can enable the /3GB switch to raise this limitation and have the system allocate 1GB of virtual address space for for kernel operations and 3GB for user applications (if they are /LARGEADDRESSPACEAWARE).
Unfortunately, the 32bits Sun/Oracle HotSpot JVM isn't LARGEADDRESSAWARE (that I know of), and other 32bits JVM likely aren't either.
But think about it: even if you were able to do that, you would use all the memory available for you system. Nothing would be left for other programs after you've allocated your 3GB of heap for your JVM. Your system would be swapping to disk all the time. It would be unusable.
Just get a 64bis OS with more RAM. That's all there is for you, short of finding ways to have your program use less memory.