<分区>
我以不同的方式问了同样的问题，问题被关闭了:https://stackoverflow.com/questions/7231460/java-64-bit-or-32-bit
这是我第二次尝试获得客观答案。
我们正在考虑将我们的产品迁移到 64 位 Java，以供那些在 Solaris (SPARC) 和 Linux (RHEL 5.x) 上突破 32 位服务器 JVM 界限的客户。我们的主管问道:“几年前，64 位还不存在。现在怎么样？”
对于那些没有突破 4 GB 边界的客户，使用 64 位 JVM 会对性能产生不利影响吗？如果有，多少钱？我们创建了很多对象。 (我们不想同时支持 32 位和 64 位 JVM。最好是非此即彼的情况)。
对于那些突破 4 GB 边界的人，我们能否期望 JVM 与 32 位的一样稳定？
- 性能会成为问题吗？如果有，多少钱？我们创建了很多对象。
- 哪些 GC 调优技术是新的？
- 分析器:它们是否适合分析 64 位 JVM 应用程序？
更新:对于那些评论者和那些关闭我之前的问题的人，我相信我现在理解你的焦虑。与此同时，我相信你们中的一些人做出了一些(不真实的)假设，认为我很懒惰或者是一个毫 headless 绪的西装。我会在调查后发布我的发现。感谢所有给我真正指点的人。
由于您几乎可以自己进行测试，因此我假设您期待关于使用 32/64 位 JVM 的体验的“现实生活”答案。
我所在的团队负责为银行创建财务应用程序。我们使用 32 位 JVM 在 Windows 上进行开发，几乎所有我们的服务器应用程序都在运行 64 位 JVM 的 RHEL 上运行。性能对我们来说从来都不是问题，因为我们使用了不错的机器(我们的常规服务器机器使用 32 核 AMD 机器，至少有 32 GiB RAM)。
正如预期的那样，由于指针大小的差异，堆大小会增加，但由于现在限制从 4GiB 提高了，所以它再次不会打扰我们。我们的应用程序还创建了很多 对象。我们可以使用 VisualVM 或命令行工具调试我们的应用程序。关于 GC 设置，我们使用默认设置并尝试更改仅当我们测量它实际上是 GC 造成问题时。分配一个比您的应用程序使用的堆大小 (8GiB) 大得多的堆大小对我们来说很常见，您会看到一个大的 GC 每天扫描一次，这非常好。
我听说 JDK 7 有一个新的 GC 算法叫做 G1 garbage collector哪个更适合服务器应用程序，因此您应该完全尝试一下。
综上所述，您最好的选择是尽可能多地测量(分别在 32 位和 64 位机器上使用 32 v/s 64 位)然后再决定。仅供引用，我们的组织正在完全推进 64 位 JVM，因为目前大多数库存服务器硬件都是 64 位的，而 4GiB 对于现代服务器应用程序(至少在我们的领域)是非常有限的。