最大Java堆大小为32
问题不在于32位操作系统上的最大堆大小，因为32位操作系统的最大可寻址内存大小为4GB，并且JVM的最大堆大小取决于可以保留多少连续空闲内存。
我更感兴趣的是了解在64位操作系统中运行的32位JVM的最大（理论和实际可行）堆大小。 基本上，我正在寻找类似SO的相关问题中的数字的答案。
至于为什么使用32位JVM而不是64位JVM，原因不是技术性的，而是管理/官僚性 - 在生产环境中安装64位JVM可能已经太晚了。
希望有一大块内存并使用原始指针的32位JVM不能使用超过4 Gb（因为这是32位限制，这也适用于指针）。 这包括Sun和 - 我非常肯定 - 也是IBM的实施。 我不知道JRockit或其他公司是否有32位实现的大内存选项。
如果您希望达到此限制，则应该强烈考虑启动一条平行通道，为您的生产环境验证64位JVM，以便在32位环境发生故障时做好准备。 否则，你将不得不在压力下做这件事，这从来都不好。
编辑2014-05-15：Oracle常见问题解答：
32位JVM的最大理论堆限制是4G。 由于可用交换，内核地址空间使用，内存碎片和虚拟机开销等各种附加限制，实际上限制可能会低得多。 在大多数现代的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）
你可以问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)");
}
}
这将根据默认堆分配报告“最大内存”。 所以你仍然需要使用-Xmx （在HotSpot上）。 我发现在Windows 7 Enterprise 64位上运行，我的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]>
而在同一个操作系统上的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]>
正如其他人已经提到的那样，这取决于操作系统。
对于64位主机操作系统，如果JVM是32位，它仍然依赖，很可能像上面所示的那样。
- 更新20110905 ：我只想指出一些其他观察/细节：
Runtime.MaxMemory数量也取决于操作系统的工作集。 我曾经运行过这个程序，同时我还运行了VirtualBox，发现我无法使用-Xmx1590M成功启动HotSpot JVM，并且必须变小。 这也意味着你可能会获得超过1590M的时间，这取决于你当时的工作集规模（尽管我仍然保持它将在2GiB下32位，因为Windows的设计） 你不指定哪个操作系统。
在Windows下（对于我的应用程序 - 一个长期运行的风险管理应用程序），我们发现在Windows 32bit上我们可以超过1280MB。 我怀疑在64位下运行32位JVM会有什么不同。
我们将应用程序移植到Linux上，并且我们在64位硬件上运行32位JVM，并且有一个2.2GB的虚拟机运行非常容易。
您可能遇到的最大问题是GC取决于您使用的内存。
链接地址: http://www.djcxy.com/p/82889.html