什么是64位JVM最大的堆大小？
在32位系统中使用-Xmx设置的理论最大堆值当然是2^32字节，但通常（请参阅： 了解最大JVM堆大小 – 32位与64位 ）不能使用全部4GB。
对于在64位机器上运行在64位操作系统上的64位JVM，除了2^64字节或16 EB字节的理论极限之外是否还有其他限制？
我知道，由于各种原因（主要是垃圾收集），过大的堆可能不是明智的 ，但从阅读有RAM的服务器的angular度来看，我想知道什么是可能的 。
如果你想使用32位引用，你的堆被限制为32 GB。
但是，如果您愿意使用64位引用，则其大小可能会受到操作系统的限制，就像使用32位JVM一样。 例如在Windows 32位上，这是1.2到1.5 GB。
注意：你会希望你的JVM堆适合主内存，理想情况下在一个NUMA区域内。 在更大的机器上大概是1TB。 如果您的JVM跨越NUMA区域，特别是内存访问和GC将需要更长的时间。 如果您的JVM堆开始交换，则GC可能需要几个小时，甚至使您的计算机无法使用，因为它会使交换驱动器崩溃。
注意：即使您在堆中使用32位引用，也可以访问较大的直接内存和内存映射大小。 即使用远高于32 GB。
压缩的热点JVM中的哎呀
压缩的oops表示被pipe理的指针（在JVM中的很多但不是所有的地方）都是32位的值，必须按比例缩放8倍，并且添加到64位的基址中以find它们引用的对象。 这使得应用程序可以处理多达40亿个对象（不是字节），或者一个堆大小可达32Gb。 同时，数据结构的紧凑性与ILP32模式相竞争。
答案显然取决于JVM的实现。 Azul宣称他们的JVM
可以扩展到超过1/2太字节的内存
通过“可以规模”，他们似乎意味着“跑井”，而不是“跑”。
Windows为每个进程添加一个内存限制，您可以在这里看到每个版本的内容
看到：
User-mode virtual address space for each 64-bit process; With IMAGE_FILE_LARGE_ADDRESS_AWARE set (default): x64: 8 TB Intel IPF: 7 TB 2 GB with IMAGE_FILE_LARGE_ADDRESS_AWARE cleared
我试过-Xmx32255M被-Xmx32255M接受压缩的oops。
对于在64位机器上运行在64位操作系统上的64位JVM，除了2 ^ 64字节或16 EB字节的理论极限之外是否还有其他限制？
您还必须考虑硬件限制。 虽然指针可能是64位，但当前的CPU只能处理一个小于2 ^ 64字节的虚拟内存 。
使用未压缩的指针，热点JVM需要一个连续的虚拟地址空间来存储堆。 所以硬件之后的第二个障碍是提供如此大块的操作系统，并不是所有的操作系统都支持这一点。
第三个是实用性。 即使可以拥有那么多的虚拟内存，也不意味着CPU支持那么多的物理内存，并且没有物理内存，最终将会交换，这将对JVM的性能产生不利影响，因为GC通常需要大量的的堆。
正如其他答案提到的压缩oops：通过撞击高于8个字节的对象alignment，压缩oops的限制可以增加超过32GB
决定最大堆大小有很多variables。 而在我的头顶，我可以想到：
- 你使用的操作系统
- 您的机器的Ram大小
- 运行的应用程序，计算其他应用程序的RAM使用情况
所以我可以build议的是尽量find最大值。 堆大小您的Java应用程序需要在大多数时间运行。
不过，如果你需要find最大尺寸，这里是我已经听到或读过的事实
OS RAM大小要求的近似值
- XP使用1 GB的RAM
- Vista / Seven使用至less2-3 GB的stream畅运行
- 我认为Linux ram的大小是1-2 GB左右
现在，我们可以希望你的JAVA虚拟机不会全时运行。 所以我们可以暂时忽略系统中运行的其他软件。 所以你的(Physical RAM size - OS RAM size requirement)大小会给你最大的堆大小 。
因此，对于运行在win7上的8Gb机器，可以有（8Gb – 3Gb）= 5Gb Java堆大小。
编辑：最大堆大小的ibm链接
