我们公司计划迁移到64位JVM，以便远离2 GB的最大堆大小限制。 Google给出了关于64位JVM性能的非常好的结果。 有没有人尝试过64位Java并分享你的经验
答案 0 :(得分：9)
简而言之： 64位JVM将为对象引用和一些其他类型（通常不重要）消耗更多内存，每个线程消耗更多内存（通常在高容量站点上很重要）并使您拥有更大的堆（通常只有在有许多长寿命对象时才重要）
更长的答案/评论：
Java是32位的评论 设计具有误导性。 Java的 内存寻址是32或 64位，但VM规范确保 大多数领域（例如int，long，double， 等等。无论如何都是一样的。
此外 - GC调整评论时 可能与物体数量有关 不相关，GC可以快速开启 有大堆的JVM（我工作过 最高可达15GB，非常高 快速GC） - 它更多地取决于如何 你和世代一起玩 收藏家计划，你的 对象使用模式是。而在 过去人们花了很多精力 调整参数，这是非常大的工作量 依赖的和现代的（Java 5+）JVM 非常擅长自我调整 - 除非 你有更多的数据 可能伤害自己而不是帮助 具有强大的JVM调优功能。
正如x86架构中所提到的， 64位EMT64或x64处理器 还包括新的说明 做像原子写，或 其他可能也会影响的选择 高性能应用程序。
答案 1 :(得分：3)
适合我们。为什么不简单地尝试设置并在jvisualvm等分析器下运行负载测试套件？
答案 2 :(得分：3)
如果你需要更大的堆，那么性能问题就没有实际意义了，不是吗？或者您有横向缩放的计划吗？
我在64位应用程序中听到的主要问题是完整的垃圾收集可能需要很长时间（因为它基于活动对象的数量）。因此，您需要仔细调整GC参数以避免完整收集（我听说过一个有关64 Gb堆的公司的轶事，并调整了他们的GC以便他们永远不会使用完整的GC;他们只是关闭每周一次）。
除此之外，认识到Java是32位设计，所以你不可能看到一次64位移动数据会带来巨大的性能提升。而且你仍然只能使用32位数组索引。
答案 3 :(得分：1)
我们直接写到64位，我看不出任何不良行为......
答案 4 :(得分：1)
根据我的经验，天真地使用32位JVM工作负载并将它们置于64位上会产生性能和空间。
然而，大多数主要的JVM供应商现在已经实现了一种很好的技术，它基本上压缩了一些堆 - 它被称为压缩引用或64位JVM的压缩oops而不是“大”（即：在4-中） 30gb范围）。
这会产生很大的不同，应该会使32-> 64过渡的影响大大降低。
IBM JVM的参考：link text