5

我以不同的方式问了同样的问题，问题被关闭了：https
://stackoverflow.com/questions/7231460/java-64-bit-or-32-bit 这是我第二次尝试获得客观答案（s ）。

对于那些在 Solaris (SPARC) 和 Linux (RHEL 5.x) 上突破 32 位服务器 JVM 界限的客户，我们正在考虑将我们的产品迁移到 64 位 Java。我们的导演问“几年前，64 位还不存在。现在呢？”

  1. 对于那些没有突破 4 GB 界限的客户，使用 64 位 JVM 会不会在性能方面产生不利影响？如果是，多少钱？我们创建了很多对象。（我们不想同时支持 32 位和 64 位 JVM。最好是非此即彼的情况）。

  2. 对于那些突破 4 GB 边界的人，我们可以期望 JVM 和 32 位一样稳定吗？

    • 性能会成为问题吗？如果是，多少钱？我们创建了很多对象。
    • 哪些 GC 调优技术是新的？
    • 分析器：它们是否完全可以分析 64 位 JVM 应用程序？

更新：对于那些评论者和那些结束我之前的问题的人，我相信我现在明白你的焦虑了。同时，我相信你们中的一些人做出了一些（不真实的）假设，即我是懒惰的，或者是一无所知的西装。我会在调查后发布我的发现。感谢所有给我真正指点的人。

4

3 回答 3

5

由于您几乎可以自己进行测试，我假设您期待“现实生活”中关于使用 32/64 位 JVM 体验的答案。

我是为银行创建金融应用程序的团队的一员。我们在 Windows 上使用 32 位 JVM 进行开发，几乎我们所有的服务器应用程序都在运行 64 位 JVM 的 RHEL 上运行。性能对我们来说从来不是问题，因为我们使用了不错的机器（我们的常规服务器机器使用 32 核 AMD 机器，至少 32 GiB RAM）。

正如预期的那样，由于指针大小的差异，堆大小会增加，但由于现在限制从 4GiB 提高，它再次不会打扰我们。我们的应用程序还创建了很多对象。使用 VisualVM 或命令行工具调试我们的应用程序没有问题。关于 GC 设置，我们使用默认设置，只有在我们测量到实际上是 GC 造成问题时才尝试更改。分配一个比您的应用程序使用的堆大小（8GiB）大得多的堆大小对我们来说很常见，您会看到一天一次的大型 GC 扫描，这非常好。

我听说 JDK 7 有一个新的 GC 算法，称为G1 垃圾收集器，它更适合服务器应用程序，所以你应该完全尝试一下。

话虽如此，您最好的选择是尽可能多地测量（分别在 32 和 64 位机器上使用 32 v/s 64 位）然后再决定。仅供参考，我们的组织正在完全推进 64 位 JVM，因为如今大多数库存服务器硬件都是 64 位的，而 4GiB 对于现代服务器应用程序（至少在我们的域中）来说是非常有限的。

于 2011-08-30T05:39:09.283 回答
2

对于那些在 Solaris(SPARC) 和 Linux(RHEL 5.x) 上突破 32 位服务器 JVM 界限的客户，我们正在考虑将我们的产品迁移到 64 位 Java。我们的导演问：“几年前，64 位还不存在。现在呢？”

Sun 开发 64 位的时间比 Windows 长得多。Solaris 2.5（1995 年与 Windows 95 发布的同一年）在 64 位中并不像它本来可以做到的那样可靠。许多仍在使用 SunOS（32 位）的人没有明白这一点，而且很少有机器有足够的内存。Solaris 2.6 (1997) 见证了向 64 位平台的第一次重大迁移。直到 1999 年（在 Solaris 上）我才认真使用 Java，那时我已经建立了 64 位。

1) 对于那些没有突破 4 GB 边界的客户，使用 64 位 JVM 会不会在性能方面产生不利影响？如果是，多少钱？

64 位 JVM 具有两倍大小和两倍的寄存器。如果您经常使用long，您可以看到显着的改进，但是对于典型应用程序，两者的差异是 5-10%。

我们创建了很多对象。

恕我直言，如果您不认为这对您来说是一个问题，那么性能对您来说并不是什么大问题。使用任何分析器，有两个报告 CPU 和内存使用情况。通常检查内存配置文件会产生更多的性能差异。（见下文）

（我们最好不要同时支持 32 位和 64 位 JVM。这是一个非此即彼的情况，最好）不能说有太大的区别。你想象的是支持每个的开销。代码完全相同，从您的角度来看，它可能会稍微增加测试。支持两个版本的 Java 6 并没有太大区别。

2) 对于那些突破 4 GB 边界的人，我们可以期望 JVM 与 32 位一样稳定吗？

自 1999 年以来一直使用 64 位版本，我不记得使用 32 位版本会使事情变得更好（由于内存有限而更糟）

性能会成为问题吗？如果是，多少钱？我们创建了很多对象。

如果性能是一个问题，丢弃更少的对象。

哪些 GC 调优技术是新的？

您可以将最大内存大小设置得更高。就是这样。只要您低于 32 GB，内存使用量就不会显着增加，因为它使用 32 位引用。

我要做的一件事是将新应用程序的 Eden 大小设置为 8 GB，并在不需要时减小它。这可以显着减少 GC 时间。（低至每天一次；）这不是 32 位 JVM 的选项。

分析器：它们是否完全可以分析 64 位 JVM 应用程序？

VisualVM 是纯 Java 和 AFAIK 的工作方式完全相同。YourKit 使用本机库，可能需要确保您使用的是正确的版本（它通常会为您设置，但如果您弄乱了您的环境，您可能需要知道有两个版本的代理）

如果您担心性能，请不要创建这么多对象。您可能会惊讶于在现实世界的应用程序中自由创建对象的速度有多慢。它可以使应用程序减慢 2 倍到 10 倍或更多。当我优化代码时，我做的第一件事就是减少对象的丢弃，我期望性能至少提高三倍。

相比之下，使用 64 位和 32 位可能会有 5%-10% 的差异。它可以更快或更慢，两者都一样。就膨胀内存而言，请使用最新的 JVM，这不太可能引起注意。这是因为当您使用少于 32 GB 的内存时，64 位 JVM 默认使用 32 位引用。标头开销仍然略高，但对象在 64 位中并没有太大-XX:+UseCompressedOops（最新版本的默认值）。

Java：关于 64 位编程的一切

使用 32 位和 64 位 JVM 测试常见对象的大小Java：获取对象的大小

一个极端的例子是创建大量对象和反射而不是创建任何对象并使用动态生成的代码。1000 倍的性能提升。避免 Java 序列化以提高性能

使用堆更少的内存可以大大减少你的 GC 时间。数百万个元素的集合库

使用堆更少的内存可以让您的应用程序使用更多的内存，而不是将数据传递给另一个应用程序服务器应用程序是否应该将自己限制为 4 GB？

于 2011-08-30T06:49:13.210 回答
1

您的问题有很多方面取决于您的应用程序，以至于“真实世界”的其他人应用程序的经验不太可能以任何程度的确定性告诉您任何有价值的事情。

我的建议是不要再浪费您（和我们的）时间来询问可能发生的情况，看看当您使用 64 位 JVM 而不是 32 位 JVM 时会发生什么。无论如何，您将不得不进行测试...

于 2011-08-30T06:53:05.863 回答