接受的答案是推测(但部分正确)。这是真正的答案。
首先,对于@ U2EF1的荣誉,8字节边界的好处之一是8字节是大多数处理器的最佳访问。但是,这个决定还有更多。
如果您有32位引用,则可以寻址最多2^32或4 GB的内存(实际上,尽管您获得的更少,但更像3.5 GB)。如果您有64位引用,则可以寻址2^64,即内存为terrabytes。但是,对于64位引用,一切都趋于放缓并占用更多空间。这是由于处理64位的32位处理器的开销,以及由于更少的空间和更多垃圾收集而导致所有处理器上的GC循环更多。
因此,创作者采取了一个中间立场,并决定使用35位参考,这样可以达到2^35或32 GB的内存,占用更少的空间,从而获得与32位参考相同的性能优势。这是通过读取一个32位参考并在读取时将其左移3位来完成的,并且在存储参考时将其右移3位。这意味着所有对象必须在2^3边界(8字节)上对齐。这些被称为压缩的普通对象指针或压缩的oops。
为什么不用36位引用来访问64 GB内存?那么,这是一个折衷。您需要大量浪费空间来处理16字节的对齐,并且据我所知,绝大多数处理器不会从16字节对齐中获得速度优势,而不是8字节对齐。
请注意,JVM不会打扰使用压缩的oops,除非最大内存设置为4 GB以上,而默认情况下它不是。实际上,您可以使用-XX:+UsedCompressedOops标志启用它们。
这是在32位虚拟机当天重新提供64位系统上的额外可用内存。据我所知,64位虚拟机没有限制。 Java性能:权威指南,第8章
来源:Java性能:权威指南,第8章