Java 64位JVM上对象引用的内存要求

在32位JVM（至少在热点上）上对对象的引用占用4字节

64位热点JVM需要8字节吗？还是正在进行一些巧妙的压缩？ 如果不是，每个

对象[]

将需要两倍的堆内存，我认为（希望、期望）并非如此

更新/额外问题：这真的很重要吗，或者这是一个可以忽略不计的增加，因为大多数引用指向的对象都比几个字节大得多（而有人可能会认为这些对象反过来又主要由对其他对象的引用组成）？

根据它，没有严格定义，但在64位系统上通常为8字节：

引用的大小没有很好的定义，但在32位系统上通常是4字节，在64位系统上是8字节

---

在64位系统中，对象引用通常为8字节长。但是，在Sun/Oracle最近推出的JVM中，您可以启用它，它将引用大小减少到4字节，但代价是堆大小限制更小。

那么Hotspot如何处理这个问题呢？如果每个引用都是8个字节，那就意味着堆的要求要高得多。我没想过。不过，这不是微不足道的吗？通常，每个对象存储的内容大部分时间都超过这8个字节。当然，对于小型对象，我可以看出这可能是一个问题，但在这种情况下，使用原语可能会更好。本书（在同一页上）有一个测量对象大小的部分，描述了如何测量对象的大小。也许你可以尝试一下，然后报告回来。嗯，我的对象存储的大多数东西都是指向其他对象的指针，所以它们也会加倍。唯一没有增长的是原语和字符串（基本上是一个char[]）之类的东西。你可能会发现这一点很有帮助——这一点：只是给一个数据点，当我们将webapp从32位JVM切换到64位JVM时，堆使用率增加了约30%。您的里程数可能会有所不同，但这至少给了您一个大概的估计。我认为默认情况下，java 7或>java 6 u23会启用它，对吗？“压缩oops在java SE 6u23和更高版本中默认支持和启用。”请参阅：但是：“在JavaSE7中，当未指定-Xmx时，对于64位JVM进程，以及对于小于32GB的-Xmx值，默认使用压缩oops。对于6u23发行版之前的JDK 6，在java命令中使用-XX:+UseCompressedOops标志来启用该功能。“请参阅@gpeche you writed”，您可以启用压缩的OOP，这将引用大小减少到4字节，但代价是堆大小限制较小。" . 为什么压缩OOP会对堆大小造成更小的限制？@Geek，因为使用32位地址比使用64位地址可以寻址更少的内存。