在阅读有关分析线程转储的文章后，我有一个困扰我的问题。有一段提到32位JVM中的逻辑最大堆大小是4GB。
This链接指出32位Windows计算机上的最大堆大小约为1.4 - 1.6 GB。
我的问题是，如果你有大约8GB的RAM，这是否意味着我只能使用1.4-1.6 GB，如果我是你的32位JVM？那么64位JVM允许的最大大小是多少？
感谢你对此的帮助，因为我对此感到困惑。
答案 0 :(得分：4)
专门针对Windows，原因是热点（sun / oracle JVM）和windows dll的实现组合。
32位代码可以访问4GB的虚拟地址空间（有扩展允许更多，但我不会进入那些）。
在32位窗口上，此虚拟地址空间的高2GB保留用于操作系统使用（某些版本的OS接受/3GB标志作为引导参数以允许3GB的用户可访问空间）
此外，您使用的任何库（* .dll）都会映射到此地址空间的一部分。默认情况下，windows base * .dll文件以~1.6 GB标记加载（根据操作系统版本和补丁级别略有不同）
除此之外，热点JVM仅支持分配单个连续的内存块以用作堆空间。
所以，如果你试着想象一下这个，你会看到你有一个约2GB的空白区域，其中有一个“墙”的windows * .dll加载到~1.6GB。这是这个数字背后的逻辑。它还意味着即使你提供/ 3GB标志，sun / oracle JVM也无法使用它。其他一些虚拟机更擅长处理碎片堆 - 比如jrockit VM
您也可以尝试rebasing windows dlls，以便加载到更高的内存地址并挤出更多可用的堆空间，但这个过程很脆弱。
还要注意，在特定计算机上加载的驱动程序/应用程序（如反病毒软件）很可能会将自己的* .dll注入到java进程中，这些dll可以在更低的内存地址加载，进一步缩小你可用的堆空间。
在64位版本的Windows the addressable limit is 8-128TB上，物理限制现在为64TB
答案 1 :(得分：1)
jvm和os也使用分页内存管理系统为我们获取4G虚拟内存
32位操作系统
但是如果你有8G ram，你必须使用64位版本的os来获得最高性能os
答案 2 :(得分：1)
这取决于您的操作系统，32位版本的MacOS X和Linux有一些能够在内核中访问超过4GB但仍将进程限制为4GB的能力。其他操作系统可能会进一步限制进程内存，因为它们本身需要4GB的一部分。通常，您希望避免将JVM交换到VM，因此您需要知道系统有多少可用内存。
答案 3 :(得分：1)
2 ^ 32 = 4GB是32位可以处理的最大总内存。
JVM仅在32位计算机上获得1.4-1.6GB，因为您仍然需要适应操作系统。
2 ^ 64 =（2 ^ 32）^ 2是您可以使用64位寻址的最大总内存。如您所见，这是一个多更大的数字。