在here上阅读本书时。
我可以看到以下部分，其中说：
32 OR 64 BIT？如果您有32位操作系统，则必须使用 一个32位版本的JVM。如果您有64位操作系统， 然后您可以选择使用32位或64位版本的Java。 不要以为只是因为你有一个64位操作系统，你 还必须使用64位版本的Java。
如果堆的大小小于约3 GB，则为32位 Java版本将更快，占用空间更小。这是 因为JVM中的内存引用只有32位，而且 操纵那些内存引用要比它便宜 操作64位引用（即使您有64位CPU）。该 32位引用也使用较少的内存。
第8章讨论了压缩oops，这是JVM可以使用的方式 即使在64位JVM中也使用32位地址。然而，即使有 这种优化，64位JVM将占用更大的空间，因为 它使用的本机代码仍然具有64位地址。
32位JVM的缺点是总进程大小必须是 小于4GB（在某些版本的Windows上为3GB，在某些旧版本上为3.5GB） Linux版本）。这包括堆，permgen和本机 JVM使用的代码和本机内存。广泛使用的程序 在32位JVM上，长或双变量的速度会慢一些，因为 他们不能使用CPU的64位寄存器，尽管这是非常的 例外情况。
适合32位地址空间的程序可以在任何地方运行 32位JVM比同类配置快5％到20％之间 64位JVM。前面讨论过的库存批处理程序 例如，在我的32位JVM上运行时，章节速度提高了20％ 桌面。
这些行说明，对于较小的堆大小（小于3GB），32位会更快。如果这是真的，我想知道它背后的原因，是什么让32位JVM更快？
答案 0 :(得分：9)
我对作者声称使用32位版本的JVM可以提高5％到20％的性能持怀疑态度。但是，我没有太多使用Java，所以我不确定。但为了调查这一说法，我查看了SPEC的一些结果。
我搜索了SPECjEnterprise2010的结果，x86-64架构的最高分为an Oracle system that used a 64-bit version of the JVM。
我还查看了SPECjvm2008，以防这些较小的工作负载可能受益于32位架构。但是best performing x86-64 system, this time from Huawei,再次使用64位版本的JVM。
如果32位版本的JVM确实更好，我希望人们提交他们的SPEC结果会在调整他们的工作负载时选择（但我可能是错的）。
我不怀疑有一些工作负载，其中32位版本的JVM将胜过64位版本。正如其他人已经注意到它为地址使用更多内存。但是，x86-64架构有更多可用的寄存器，我怀疑64位操作模式是大多数优化工作的重点。
系统性能有很多组件，我不认为32位版本的JVM必然会胜过64位版本（对于这一点，这只会对CPU绑定工作负载产生影响）。我要说的是，如果你在性能调优过程中达到这一点，你会想要检查两个不同选项的自己的工作量，并使用你自己的测试结果做出决定而不是假设使用32位优于64位因为根据经验节省了地址的存储空间，因为还有其他因素可能比这更重要。
答案 1 :(得分：7)
这更多是一般表现的问题。如果你有一个最近的64位处理器和大量未使用的内存，使用JVM 32而不是JVM 64的唯一可能的增益是一些循环可以完全适合具有32位地址的高速缓存而不是64位那些导致较少的主存储器使用32位JVM访问。我真的无法评估增益，但除非在非常特殊的情况下我怀疑它达到5％到20％ - 请注意我只是怀疑，不确定......
但是如果您使用资源有限的系统，最终因为您想要优化硬件并在其上运行许多虚拟机，32位JVM将使用比64位JVM少得多的内存。它将为其他应用程序和系统留出更多可用内存，从而避免交换并允许系统更好地缓存磁盘IO。
恕我直言，没有一般规则。我只会使用以下经验法则：如果JVM 和所有其他应用程序正在运行，系统仍有足够的内存用于缓存IO，我会使用64位JVM和32位一个相反的情况。当然，只有Java应用程序本身不需要大量使用64位JVM的内存 - 并且最终在必要时向系统添加更多内存时才有意义，因为现在内存不是那么昂贵< / p>
答案 2 :(得分：2)
没有简单的答案，最好的办法就是针对您的具体应用进行尝试。但你应该记住，还有很多其他选择，例如关于JIT，垃圾收集算法，RAM限制，可能比建筑选择的影响更大，因此您必须将这些包含在测量中。
如果您曾经问过这个问题，换句话说就是选择，这意味着您已经在具有32位模式的64位系统上运行（具有可接受的性能，即没有软件仿真） ）最有可能是AMD64又名x86-64。
在这样的系统上，Oracle的JVM支持“压缩oops”，这意味着只要最大堆不超过32 GB，就可以在Java堆中使用32位引用（如果确实如此，我怀疑使用32位是一个有效的选择那个应用程序）。与32位JVM相比，它可能仍然消耗更多RAM，因为某些组件仍然需要使用64位指针，但这些通常不是应用程序的性能相关部分。
请注意，对于使用64位模式的AMD64 aka x86-64架构，不仅仅意味着更改指针大小。注意只允许它使用每个寄存器64位，它还有更多可用寄存器。它实际上是在同一芯片中实现的不同架构，并且取决于您的应用，使其可能是一个很大的改进。
但正如所说，用真实应用程序测试它是获得正确答案的唯一有效方法。
答案 3 :(得分：2)
如果您打算使用其中一个Oracle VM，那么问题就变成了您是否要使用客户端或服务器JIT，因为Oracle还没有可用于任何64位CPU的客户端JIT。
服务器虚拟机可用于32位和64位CPU，x86 / AMD64 CPU上服务器虚拟机的性能差异相当小（根据我的经验，它在Windows上不到+/- 5％或者Linux），虽然64位VM通常需要大约20％的内存。
如果您的应用程序需要大于1.3GB的堆内存大小，则必须使用64位服务器VM，因为来自Oracle的32位虚拟机不会以堆大于此值的方式启动（在Linux上限制略高）。
客户端JIT的主要优点是它具有更快的启动时间。使用此VM，您可以在不到100毫秒的时间内完成相当多的认真工作，而即使打开分层编译，服务器VM也只需要一秒钟即可开始。客户端VM还需要比服务器VM少得多的内存，并且可以在同一台计算机上的多个VM实例之间形成class data sharing。
另一方面，服务器VM往往能够以相当快的速度执行计算密集型代码。实际性能差异根据您执行的代码而有很大差异，但可能介于约-10％和+ 200％之间。对于运行时间超过几百毫秒的任何事情，它通常至少快30％。您可以使用各种选项调整两个JIT，使它们的行为更相似，但您仍然只能使用客户端VM获得快速启动时间，并且仅使用服务器VM获得最高执行速度。
因此，当您有足够的可用内存并且不关心启动时间损失时，我建议将64位服务器VM用于所有内容。 32位客户端虚拟机非常适合较小的GUI应用程序，但尤其适用于平均执行时间不到一秒的小型命令行工具，或者可能需要在同一台计算机上同时运行多次。
答案 4 :(得分：1)
32位内存地址较小。仅这一点可能会带来更好的缓存，参考位置等。
答案 5 :(得分：1)
32位地址更少的内存空间最大理论限制是4GB但实际上在Windows系统中它是1.3GB。您可以在Linux内核上解决更多（300到400 MB）的问题。有关详细信息，请使用http://www.oracle.com/technetwork/java/hotspotfaq-138619.html#gc_heap_32bit（堆空间内存）
64位使用更高的位来寻址。所以整体内存消耗也更高。可以选择使用压缩内存指针。在http://docs.oracle.com/javase/7/docs/technotes/guides/vm/performance-enhancements-7.html#compressedOop
了解更多相关信息答案 6 :(得分：1)
64位较慢的原因是垃圾收集暂停较多。构建更多堆意味着GC在从未使用的对象清理它时需要完成更多工作。在现实生活中它意味着在构建大于12-16GB的堆时必须格外小心。如果没有微调和测量，您可以轻松地引入几分钟的完整GC暂停。
答案 7 :(得分：0)
64位的一个论点是32位服务器硬件现在非常罕见。因此，在服务器上使用32位软件的人并不多。 32位jvms仍然存在的主要原因是支持32位客户端软件用于较旧的32位系统以及applet，这些小程序通过32位浏览器中的插件运行。
因此，如果32位版本中存在异乎寻常的漏洞，您可能是第一个发现的漏洞。这些将是在桌面系统上不太明显的错误类型，在长时间运行的服务器端软件中更明显。几周/几天后想想神秘的崩溃。内存泄漏等
所以，如果你在服务器上进行部署，除非你有充分的理由不这样做，否则几乎要去64位。在Java的内存使用和垃圾收集方面，有很多snakeoil解决方案。所以，除非你能用一些可靠的指标来支持它，否则我会谨慎地将其作为一种论证。根据我的经验，知道如何正确调整jvm的java工程师实际上非常罕见，并且大多数似乎只是在JVM_ARGS上随机复制粘贴内容，直到它有效。他们中的大多数人最终都会使用不是最佳的解决方案，不再适合他们使用的JVM，或者主动有害的解决方案。 Jvm调音是一种黑色艺术。除非你知道自己在做什么，否则最好不要乱用它。
对于客户端系统，如果需要支持applet或较旧的桌面系统，请转到32位。例如。 Windows直到最近才发布了32位版本的操作系统，Windows和osx上的许多应用仍然是32位。大多数情况下，您不必选择，在任何情况下都可以将此选择留给用户。
对于担心地址大小的人来说，64位版本可以对小于32GB的堆进行指针压缩。您需要（并且可能希望）在JVM args中启用它：-XX:+UseCompressedOops.。