对于任务关键型工作负载，64 位 JVM 与 32 位一样好吗？
我以不同的方式问了同样的问题，问题已结束： https://stackoverflow .com/questions/7231460/java-64-bit-or-32-bit
这是我第二次尝试获得客观答案。
对于那些正在突破 Solaris (SPARC) 和 Linux (RHEL 5.x) 上 32 位服务器 JVM 界限的客户，我们正在考虑将我们的产品迁移到 64 位 Java。我们的主管问：“几年前，64 位还没有出现。现在呢？”
对于那些未突破 4 GB 界限的客户，使用 64 位 JVM 会对性能产生不利影响吗？如果是的话，多少钱？我们创建了很多对象。 （我们不想同时支持 32 位和 64 位 JVM。最好是非此即彼的情况）。
对于那些突破 4 GB 边界的人，我们是否可以期望 JVM 与 32 位 JVM 一样稳定？
- 性能会成为问题吗？如果是的话，多少钱？我们创建了很多对象。
- 有哪些新的 GC 调优技术？
- 分析器：它们是否适合分析 64 位 JVM 应用？
更新：对于那些评论者和那些结束我之前问题的人，我相信我现在理解你的焦虑。与此同时，我相信你们中的一些人做出了一些（不真实的）假设，认为我很懒，或者是一个毫无头绪的人。我将在调查后发布我的发现。感谢所有给我真正指点的人。
I asked the same question in a different way and the question was closed : https://stackoverflow.com/questions/7231460/java-64-bit-or-32-bit
This is my 2nd try at getting an objective answer(s).
We were contemplating moving our product to 64-bit Java for those customers who are pushing the boundaries of the 32-bit server JVM on Solaris (SPARC) and Linux (RHEL 5.x). Our director asked "some years ago, 64-bit wasn't quite there. How about now?"
For those customers not pushing the 4 GB boundary, will using 64-bit JVM have adverse effects in terms of performance? If yes, how much? We create a lot of objects. (we don't want to support 32-bit and 64-bit JVMs at the same time. It's a either or situation, preferably).
For those pushing the 4 GB boundary, can we expect the JVM to be as stable as the 32-bit one?
- 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?
UPDATE : To those commenters and those who closed my earlier question, I believe I NOW understand your angst. At the same time, I believe some of you made some (untrue) assumptions that I was lazy or a suit who has no clue. I'll post my findings after my investigations. Thanks to all those who gave me real pointers.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
由于您几乎可以自己进行测试，因此我假设您期待关于使用 32/64 位 JVM 的体验的“现实生活”答案。
我是为银行创建金融应用程序的团队的一员。我们使用 32 位 JVM 在 Windows 上进行开发，几乎所有我们的服务器应用程序都在运行 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 对于现代服务器应用程序来说是相当有限的（至少在我们的领域）。
Since you can pretty much do the testing yourself, I'm assuming you are expecting "real life" answers as to the experience of using a 32/64 bit JVM.
I'm part of a team which creates financial application for banks. We use 32 bit JVM's for development on Windows and almost all our server applications run on RHEL which runs a 64 bit JVM. Performance was never a problem for us since we use decent machines (our regular server machine use a 32 core AMD box with at least 32 GiB RAM).
As expected, the heap size would go up due to the difference in pointer sizes but since now the limit is raised from 4GiB, it again doesn't bother us. Our application also creates a lot of objects. We have no problem debugging our application with either VisualVM or command line tools. Regarding GC settings, we use the default settings and try to change only when we measure that it's actually the GC creating problems. Allocate a heap size which is much more than your application would use (8GiB) is common for us and you would see a single big GC sweep around once a day which is pretty good.
I've heard that the JDK 7 has a new GC algorithm called G1 garbage collector which is more suited for server applications so you should totally give it a try.
All that being said, your best bet would be to measure as much as possible (using 32 v/s 64 bit on 32 and 64 bit machines respectively) and then decide. FYI, our organization is totally pushing forward with the 64 bit JVM's given that most stock server hardware these days is 64 bits and 4GiB is pretty restrictive for a modern server application (at least in our domain).
Sun 开发 64 位系统的时间比 Windows 长得多。 Solaris 2.5（1995 年，Windows 95 发布的同一年）在 64 位环境中的可靠性并不高。许多仍在使用 SunOS（32 位）的人没有意识到这一点，而且很少有机器拥有足够的内存。 Solaris 2.6 (1997) 首次实现了向 64 位平台的重大迁移。直到 1999 年（在 Solaris 上）我才认真使用 Java，那时 64 位已经在我的脑海中确立了。
64 位 JVM 的寄存器大小和数量是原来的两倍。如果您经常使用
long，您会看到显着的改进，但是对于典型的应用程序，无论哪种方式，差异都是 5-10%。恕我直言，如果这对您来说不是一个问题，那么性能对您来说并不是什么大问题。使用任何分析器都会有两个报告 CPU 和内存使用情况。通常检查内存配置文件会带来更多的性能差异。 （见下文）
自 1999 年以来一直使用 64 位版本，我不记得使用 32 位版本会使事情变得更好（由于内存有限，只会变得更糟）
如果性能是一个问题，请丢弃更少的对象。
您可以将最大内存大小设置得更高。就是这样。只要低于 32 GB，内存使用量就不会明显增加，因为它使用 32 位引用。
我做的一件事是将新应用程序的 Eden 大小设置为 8 GB，如果不需要则减少它。这可以显着减少 GC 时间。 （低至每天一次；）对于 32 位 JVM，这不是一个选项。
VisualVM 是纯 Java 的，据我所知，其工作原理完全相同。 YourKit 使用本机库，可能需要确保您使用正确的版本（它通常会为您设置此版本，但如果您弄乱了环境，您可能需要知道代理有两个版本）
如果您担心性能，不要创建那么多对象。您可能会惊讶地发现，在现实世界的应用程序中，自由创建对象的速度要慢得多。它可以使应用程序速度减慢 2 倍到 10 倍或更多。当我优化代码时，我做的第一件事就是减少对象的丢弃，我期望性能至少提高三倍。
相比之下，使用 64 位与 32 位可能存在 5%-10% 的差异。它可以更快或更慢，并且两者都有可能。就内存膨胀而言，使用最新的 JVM，这不太可能被注意到。这是因为当您使用的内存小于 32 GB 时，64 位 JVM 默认使用 32 位引用。当
-XX:+UseCompressedOops启用时（最新版本的默认设置），标头开销仍然稍高，但 64 位中的对象并没有太大。Java：关于 64 位编程的一切
使用 32 位与 64 位 JVM 测试常见对象的大小 Java：获取对象的大小
一个极端的例子做同样的事情创建大量对象和反射与不创建任何对象和使用动态生成的代码。性能提升 1000 倍。 避免 Java 序列化以提高性能
使用更少的堆内存可以大大减少 GC 时间。 包含数百万元素的集合库
使用更少的堆内存可以让您的应用程序使用更多内存，而不是将数据传递到另一个应用程序服务器应用程序是否应该将自身限制为 4 GB？
Sun have been doing 64-bit for much longer than Windows. Solaris 2.5 (1995 the same year Windows 95 was released) wasn't as reliable in 64-bit as it could have been. Many people still on SunOS (32-bit) didn't see the point and few machine has enough memory to matter. Solaris 2.6 (1997) saw the first significant migration to the 64-bit platform. I didn't use Java seriously until 1999 (on Solaris) and at that point 64-bit what already established in my mind.
The 64-bit JVM has registers twice the size and twice as many. If you use
longalot you can see a dramatic improvement, however for typical applications the difference is 5-10% either way.IMHO Performance hasn't been much of an issue for you if this isn't recognised as a problem for you. Use any profiler and there are two reports CPU and Memory usage. Often examining the memory profile makes more of a performance difference. (See below)
Having used the 64-bit version since 1999 I can't remember an occasion where using the 32-bit would have made things better (only worse due to limited memory)
If performance is an issue, discard less objects.
You can set the maximum memory size higher. That's about it. As long as you are below 32 GB there won't be a noticable increase in memory usage as it uses 32-bit references.
One thing I do is set the Eden size to 8 GB for a new application and reduce it if its not needed. This can dramatically reduce GC times. (To as low as once per day ;) This wouldn't be an option with a 32-bit JVM.
The VisualVM is pure Java and AFAIK works exactly the same. YourKit uses a native library and might need to ensure you are using the right version (it normally sets this up for you, but if you mess with your environment you might need to know there are two versions of the agent)
If you are worried about performance, don't create so many objects. You might be surprised how much slower creating objects freely makes in real world applications. It can slow an application by 2x to 10x or more. When I optimise code the first thing I do is reduce the discarding of object and I expect at least a three fold performance improvement.
By comparison using 64-bit vs 32-bit is likely to be 5%-10% difference. It can be faster or slower and both are just as likely. In terms of bloating your memory, use the latest JVMs and that is unlikely to be noticeable. This is because the 64-bit JVM uses 32-bit references by default when you use less than 32 GB of memory. The header overhead is still slightly higher but objects are not much bigger in 64-bit when
-XX:+UseCompressedOopsis on (the default for the latest releases).Java: All about 64-bit programming
Test the size of common objects using 32-bit vs 64-bit JVMs Java: Getting the size of an Object
A extreme example of doing the same thing creating lots of objects and reflection vs not creating any and using dynamically generated code. 1000x performance improvement. Avoiding Java Serialization to increase performance
Using heap less memory can massively reduce your GC times. Collections Library for millions of elements
Using heap less memory can allow your application to use much more memory instead of passing data to another application Should server applications limit themselves to 4 GB?
您的问题的很多方面都取决于您的应用程序，因此其他人的应用程序的“现实世界”经验不太可能以任何程度的确定性告诉您任何有价值的信息。
我的建议是，不要再浪费你（和我们）的时间来询问可能会发生什么，而是看看当你使用 64 位 JVM 而不是 32 位 JVM 时会发生什么。无论如何，你都必须进行测试......
There are so many aspects of your question that are dependent on your application that "real world" experiences with other peoples' applications are unlikely to tell you anything worthwhile with any degree of certainty.
My advice would be to stop wasting your time (and ours) asking what MIGHT happen, and just see what DOES happen when you use a 64-bit JVM instead of a 32-bit one. You are going to have to do the testing anyway ...