特别是在Windows上，原因是hotspot（sun/oracle JVM）的实现和Windows dll的组合。
32-位代码可以访问4GB的虚拟地址空间（有扩展允许更多，但我不会进入这些）。
在32位窗口上，此虚拟地址空间的上2GB保留供操作系统使用（某些版本的操作系统接受/3GB标志作为 Boot 参数，以允许3GB的用户可访问空间）。
此外，您使用的任何库（*. dll）都Map到该地址空间的一部分。默认情况下，Windows基本 *.dll文件加载到~ 1. 6 GB标记处（因操作系统版本和补丁程序级别而稍有不同）
除此之外，hotspot JVM只支持分配一个连续的内存块作为堆空间。
因此，如果您尝试在脑海中想象一下，您将看到有大约2GB的空闲区域，其中加载了大约1.6GB的windows *. dll“墙”。这就是该图背后的逻辑。这还意味着，即使您提供了/3GB标志，sun/oracle JVM也无法使用它。其他一些虚拟机更擅长处理碎片堆-如jrockit VM
您也可以尝试rebasing windows dlls，这样它们就可以加载到更高的内存地址中，从而压缩更多的可用堆空间，但是这个过程是脆弱的。
还要注意的是，在特定机器上加载的驱动程序/应用程序（如反病毒软件）很可能会将它们自己的 *. dll注入到Java进程中，并且这些dll可以在更低的内存地址上加载，从而进一步缩小可用的堆空间。
在64位版本的Windows上，可寻址容量限制为8- 128 TB，物理容量限制为64 TB

2^32 = 4GB是您可以使用32位寻址的最大总内存。
JVM在32位机器上只能获得1.4-1.6GB，因为您仍然必须适应操作系统。
2^64 =（2^32）^2是您可以使用64位寻址的最大总内存。正如您所看到的，这是一个 * 大 * 得多的数字。

jvm和操作系统使用分页内存管理系统，为用户获得4G虚拟内存
32位操作系统
但如果你有8G内存，你必须使用64位版本的操作系统，以获得最大的操作系统性能

这取决于您的操作系统，32位版本的MacOS X和Linux可以访问内核中超过4GB的内存，但仍将进程限制为4GB。其他操作系统可能会进一步限制进程内存，因为它们需要4GB的一部分。通常，您希望避免将JVM交换到VM，因此您需要知道系统有多少可用内存。