JVM是32位还是64位？
在here上读这本书的时候
我可以看到下面的部分，上面写着：
32 OR 64 BIT? If you have a 32-bit operating system, then you must use a 32-bit version of the JVM. If you have a 64-bit operating system, then you can choose to use either the 32- or 64-bit version of Java. Don’t assume that just because you have a 64-bit operating system, you must also use a 64-bit version of Java.
If the size of your heap will be less than about 3 GB, the 32-bit version of Java will be faster and have a smaller footprint. This is because the memory references within the JVM will be only 32-bits, and manipulating those memory references is less expensive than manipulating 64-bit references (even if you have a 64-bit CPU). The 32-bit references also use less memory.
Chapter 8 discusses compressed oops, which is a way that the JVM can use 32-bit addresses even within the 64-bit JVM. However, even with that optimization, the 64-bit JVM will have a larger footprint because the native code it uses will still have 64-bit addresses.
The downside to the 32-bit JVM is that the total process size must be less than 4GB (3GB on some versions of Windows, and 3.5GB on some old versions of Linux). That includes the heap, permgen, and the native code and native memory the JVM uses. Programs that make extensive use of long or double variables will be slower on a 32-bit JVM because they cannot use the CPU’s 64-bit registers, though that is a very exceptional case.
Programs that fit within a 32-bit address space will run anywhere between 5% and 20% faster in a 32-bit JVM than a similarly-configured 64-bit JVM. The stock batching program discussed earlier in this chapter, for example, is 20% faster when run on a 32-bit JVM on my desktop.
该行表示，如果堆大小较小（小于3GB），32位将更快。如果这是真的，我想知道背后的原因，是什么让32位JVM更快
# 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上阅读更多关于这方面的信息
# 2 楼答案
32位内存地址更小。这本身就可能导致更好的缓存、引用的局部性等
# 3 楼答案
64位速度较慢的原因是垃圾收集暂停过大。建立更多的堆意味着GC在清理未使用对象时需要做更多的工作。在现实生活中，这意味着在构建大于12-16GB的堆时必须格外小心。如果不进行微调和测量，您很容易引入跨越几分钟的完整GC暂停
# 4 楼答案
如果您打算使用其中一个Oracle虚拟机，问题将更多地变成您是想使用客户机还是服务器JIT，因为Oracle还没有任何64位CPU可用的客户机JIT
服务器虚拟机可用于32位和64位CPU，x86/AMD64 CPU上的服务器虚拟机的性能差异非常小（根据我的经验，在Windows或Linux上的性能差异小于+/-5%），尽管64位虚拟机通常需要大约20%的内存
如果应用程序需要的堆内存大小超过约1.3GB，则必须使用64位服务器虚拟机，因为Oracle的32位虚拟机不会以大于该值的堆大小开始（在Linux上，限制略高）
客户机JIT的主要优点是它有更快的启动时间。使用这个虚拟机，您可以在不到100毫秒的时间内完成大量严肃的工作，而服务器虚拟机即使启用了分层编译，也只需要一秒钟以上的时间就可以开始。客户机虚拟机所需的内存也比服务器虚拟机少得多，而且可以在同一台计算机上的多个虚拟机实例之间形成class data sharing
另一方面，服务器虚拟机往往能够更快地执行计算密集型代码。实际的性能差异很大程度上取决于您执行的代码，但可能介于-10%和+200%之间。通常情况下，对于运行时间超过几百毫秒的任何东西，速度至少要快30%
您可以使用各种选项调整这两种JIT，使它们的行为更加相似，但仍然只有在客户端VM上才能获得快速启动时间，只有在服务器VM上才能获得最高执行速度
因此，我建议在内存充足且不关心启动时间损失的情况下，使用64位服务器虚拟机。32位客户机虚拟机对于较小的GUI应用程序非常有用，但对于平均执行时间不到一秒或可能需要在同一台计算机上同时运行多次的小型命令行工具来说尤其如此
# 5 楼答案
我怀疑作者的说法，即使用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
如果JVM的32位版本真的更好，我希望提交规范结果的人在调整工作负载时会选择它（但我可能错了）
我毫不怀疑，在某些工作负载中，32位版本的JVM将优于64位版本。正如其他人所指出的，它使用更多的内存来存储地址。然而，x86-64体系结构有更多可用寄存器，我怀疑64位操作模式是大多数优化工作的重点
系统性能有很多组成部分，我不认为32位版本的JVM一定会优于64位版本（其中一个原因是，这只会影响CPU受限的工作负载）。我想说的是，如果你在性能调整过程中达到了这一点，你会想检查你自己的工作负载，寻找两个不同的选项，并使用你自己的测试结果来做出决定，而不是假设使用32位比64位更好，因为根据经验，可以为地址节省内存空间，因为还有其他因素可能比这更重要
# 6 楼答案
这更像是一个整体表现的问题。如果您有一个最近的64位处理器和大量未使用的内存，那么使用JVM 32而不是JVM 64的唯一可能的好处是，一些循环可以完全适合32位地址的缓存，而不是64位地址的缓存，从而减少32位JVM的主内存访问。我真的无法评估收益，但除非在非常特殊的情况下，我怀疑它能达到5%到20%——注：我只怀疑，不确定
但是，如果你使用的是一个资源有限的系统，最终因为你想优化你的硬件并在其上运行许多虚拟机，32位JVM将比64位JVM使用少得多的内存。它将为其他应用程序和系统留下更多可用内存，从而避免交换，并允许系统更好地缓存磁盘IO
嗯，没有一般规则。我将使用以下经验法则：如果当JVM和所有其他应用程序运行时，系统仍然有足够的内存来缓存IO，我将使用64位JVM，在相反的情况下使用32位JVM
当然，只有当Java应用程序本身不需要大量内存来强制使用64位JVM时，上面提到的才有意义——如果有必要，最终会向系统添加更多内存，因为现在的内存并不那么昂贵