Java 如果有的话，-d64开关对Sun JVM驻留内存的使用有什么影响？

我有一个需要调整内存的Web应用程序。虽然我已经对应用程序本身进行了分析并进行了精简，但在我们最繁忙的实例中，JVM本身似乎过于臃肿。（低卷实例没有此问题。）详细信息：

• 站台：
  • RHEL4 64位（

    Linux 2.6.9-78.0.5.ELsmp#1 SMP x86_64

    ）
  • Sun Java 6（

    Java HotSpot（TM）64位服务器虚拟机（构建10.0-b23，混合模式）

    ）
  • 在

    startup.sh

• 我的webapp目前有一些代码，在生产中需要运行64位的好处
• 我观察到，经过一段时间（一周）之后，JVM驻留内存大小（如上图所示）是my-Xmx设置大小的三倍
• 非堆内存大小等都相对较小，仅占堆大小的一位数
• 只有一段代码需要64位地址空间

如果我可以重构出对64位JVM的需求，并去掉

-d64

开关，那么JVM的驻留内存占用会更小吗？换句话说

---

如果有的话，

-d64

开关对Sun JVM驻留内存的使用有什么影响？使用d64开关使JVM进入64位模式。从技术上讲，在Solaris/Linux和大多数Unix上，JVM进程将在LP64模型中执行

与32位模型（ILP32）不同的是，指针恰好是64位宽，而不是32位指针。对于JVM，这允许更大的内存寻址能力，但也意味着仅对象引用占用的大小就翻了一番。因此，在32位JVM和64位JVM中，相同数量的对象在给定时间会出现更大的膨胀

另一件经常被遗忘的事情是指令本身的大小。在64位JVM上，指令的大小将占用本机寄存器的大小

但是，如果在64位环境中使用，JVM将尽可能对堆大小大于4 GB的指针进行编码和解码。简单地说，当您使用压缩指针时，JVM会尽可能多地使用32位宽的值

提示：打开UseCompressedOops标志，使用-XX:+UseCompressedOops去除一些膨胀。YMMV，但是

编辑

---

.

回答得太好了。您说服我重构代码，并删除-d64。我会回来评论事情的进展。我还将在JVM更新中工作，以便可以尝试-XX:+UseCompressedOops。谢谢2009年9月，你获得了斯图大学世界著名的“每月最棒的程序员”奖！哇，我从来都不知道谷歌fu会解释这样的反应。谢谢，我对你的回答感到惊讶！顺便说一句，如果您设法使堆小于4GB，那么64位JVM的行为将类似于32位JVM；但不确定是否会对性能产生影响。比Google fo更重要！！！我环顾了一下自己，认为这是值得的……但是有太多的JVM开关和值，如果是的话，还有cases和gotchyas。这可能是压倒性的，我需要的是一个“做它”/“不要麻烦”的回答，并伴有相关的填鸭式喂养。再次感谢。旁注：不是我的堆超过了4GB，而是我对MappedBytebyBuffers的使用超过了4GB的地址空间。这在当时似乎是个好主意…关于UseCompressedOops标志：“Java SE 6u23及更高版本默认支持并启用压缩oops。在JavaSE7中，当未指定-Xmx并且-Xmx的值小于32GB时，64位JVM进程默认使用压缩oops。对于6u23发行版之前的JDK 6，请在java命令中使用-XX:+UseCompressedOops标志来启用该功能。”