对于关键任务负载，64位JVM可以达到32位吗？

Question

我以不同的方式问了同样的问题，问题结束了：https://stackoverflow.com/questions/7231460/java-64-bit-or-32-bit

这是我第二次试图得到一个客观的答案。

我们正在考虑为那些在Solaris (SPARC)和Linux (RHEL5.x)上拓展32位服务器JVM边界的客户将我们的产品移动到64位Java。我们的导演问：“几年前，64位还没到，现在呢？”

1. 对于那些没有突破4GB边界的客户，使用64位JVM会不会对性能产生不利影响？如果是，多少钱？我们创造了很多物体。(我们不想同时支持32位和64位JVM。最好是两者兼而有之。
2. 对于那些推动4GB边界的人，我们能期望JVM像32位一样稳定吗？

- Will performance be an issue? If yes, how much? we create a lot of objects.
- What GC tuning techniques are new ?
- Profilers: are they quite there for profiling 64-bit JVM apps?

​

更新:对于那些评论和那些结束我之前的问题的人，我相信我现在理解了你的焦虑。同时，我相信你们中的一些人做了一些(不真实的)假设，认为我是懒惰的，或者是一套毫无头绪的西装。我会在调查结束后公布我的调查结果。感谢那些给我真正指点的人。

Answer 1

我们正在考虑为那些在Solaris(SPARC)和Linux(RHEL5.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)对于那些不突破4GB边界的客户，使用64位JVM会不会对性能产生不利影响？如果是，多少钱？

64位JVM拥有两倍大小和两倍数量的寄存器。如果您经常使用long，您可以看到一个巨大的改进，但是对于典型的应用程序，两者的差别都在5-10%之间。

我们创造了很多物体。

IMHO的表现对你来说并不是什么大问题，如果你不认为这是个问题的话。使用任何分析器，有两个报告CPU和内存使用情况。经常检查内存配置文件会产生更大的性能差异。(见下文)

(我们最好不要同时支持32位和64位JVM。这是一种或两种情况，最好是)不能说有多大的区别。你认为支持每个人的开销是什么？代码完全相同，从您的角度来看，它可能会稍微增加一些测试。它与支持两个版本的Java 6并没有太大的不同。 2)对于那些推动4GB边界的人，我们能期望JVM稳定到32位吗？

自从1999年开始使用64位版本后，我不记得有一次使用32位会让事情变得更好(只是由于内存有限而更糟)。

表演会是个问题吗？如果是，多少钱？我们创造了很多物体。

如果性能是问题，则丢弃较少的对象。

什么GC调优技术是新的？

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

我要做的一件事是为一个新的应用程序将Eden大小设置为8GB，如果不需要的话可以将它缩小。这可以极大地减少GC时间。(每天最低一次;)对于32位JVM来说，这不是一种选择。

分析器:它们很适合分析64位JVM应用程序吗？

VisualVM是纯Java的，AFAIK的工作原理完全相同。YourKit使用本机库，可能需要确保您使用的版本是正确的(它通常为您设置此版本，但如果您处理环境，您可能需要知道代理有两个版本)

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

比较使用64位和32位可能会有5%-10%的差异.它可以是更快或更慢，两者都是同样的可能性。在增加内存方面，使用最新的JVM，这是不太可能引起注意的。这是因为当您使用不足32 GB的内存时，64位JVM默认使用32位引用。头部开销仍然略高，但当-XX:+UseCompressedOops处于打开状态时，对象在64位中不会大得多(最新版本的默认设置)。

Java:所有关于64位编程的内容。

使用32位vs 64位JVM Java:获取对象的大小测试常见对象的大小。

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

使用较少的堆内存可以大大减少GC时间。数百万元素藏书库

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

Answer 2

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

我是一个为银行创建金融应用程序的团队的一员。我们使用32位JVM在Windows上进行开发，几乎所有的服务器应用程序都运行在运行64位JVM的RHEL上。性能从来不是我们的问题，因为我们使用体面的机器(我们的常规服务器机器使用32核心GiB盒至少32内存)。

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

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

尽管如此，您最好的选择是尽可能多地测量(分别在32位和64位机器上使用32 v/s 64位)，然后决定。FYI，我们的组织正在全力推进64位JVM，因为现在大多数库存服务器硬件都是64位，而4GiB对于现代服务器应用程序(至少在我们的领域)来说是相当有限的。

Answer 3

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

我的建议是停止浪费您的时间(和我们的时间)询问可能发生的事情，只需要看看当您使用64位JVM而不是32位JVM时会发生什么。你无论如何都得做测试.