32位和64位的JVM 我该选择哪个呢？

 

本文是作者Vladimir Šor的实际经验分享，他在创建企业级应用时，经常会遇到该如何选择JVM的问题，一开始他是通过抛硬币决定，后来他有了更加深入的思考。

在开发企业软件时，我曾经常遇到这个问题。每隔一段时间我就得去重新配置一下环境。通常问题都与“我到底应该使用32位JVM还是64位”有关。诚实讲，我一开始通过投硬币来决定，而不是给出一个具体的理由。但现在，我已经有了更多的思考和经验，下面就来分享给大家。

首先，是否是越大越好？64>32，所以答案就是选择64位吗？停，不要着急。在相同的数据结构下，64位JVM将会消耗更多的内存，甚至更多。我们的测量结果表明，根据不同的 JVM版本、操作系统以及硬件架构，64位要比32位多消耗30%-50%的堆空间。堆越大，GC的时间就会被延长，从而影响应用程序延迟——在4.5GB的堆上运行一个完整的GC所花费的时间肯定要比3GB的长。所以仅仅根据大小来判断是明显错误的。

但是，你该何时使用64位呢？大多数情况下是根据大型堆的大小（heap sizes）来决定的。在不同的架构上，32位的JVM可能会面临最大和最小堆限制，下面列出了不同平台上的限制数据：

现在你已经看到有多糟糕了吧？我打赌你肯定见过在16G以上的RAM上运行32位的机器并且运行的很好。可是JVM是怎么了？在16G RAM的Windows上，JVM只能分配不到10%的内存。

主要原因——地址空间。在一个32位系统上，理论上每个进程可以分配4GB。而实际上并未达到，Windows的进程处理空间被砍掉了一半，有一半是预留给内核（用户进程是不能使用的） ，另外一半则留给用户。与RAM无关，32位处理器留给RAM的容量只有2GB。更糟糕的是，这个地址空间必须是连续的，所以在实际应用中，Windows系统通常只剩下1.5—1.8GB的堆空间。

这里有一个技巧，可以在32位的Windows系统上减少内核但可以增加用户空间。你可以在boot.ini里使用3GB参数，然而要想在实际中有效，JVM必须使用LARGEADDRESSAWARE 开关（switch）去编译/链接。 

不幸并非如此，至少对于Hotspot JVM来说。直到最新的JDK 1.7版本，Hotspot JVM都没有使用这项进行编译。但如果你在jRockit版本上运行（2006以后的版本）就是很幸运的，你可以享受到2.8-2.9GB大小的堆空间。

所以，我们可以下这样的结论吗：如果应用程序需要大于2-3GB的内存时，你应该一直在64位的JVM上运行。也许是这样，但你必须要意识到一些问题，增加堆消耗和延长GC中断。下面让我们来分析一下具体原因。

问题1：64位将会多需要30%-50%的堆内存。为什么会这样？主要是因为64位架构的内存布局。首先，在64位JVM中，对象头（object headers）是12字节。其次，根据实际的JVM参数（JVM flags）和堆大小，对象引用可能是4字节或者是8字节。与32位相比，这明显增加了一些额外的开销。你也可以参考这篇文章，进去看看是如何计算对象内存消耗的。

问题2：GC中断时间更长。堆构建的越多，意味着GC需要清理更多未使用的对象。这就意味着在实际运用中，当构建超过12-16GB的堆空间时，你需要更加小心。没有调优和测量，你很容易引起一个耗时数分钟的完全GC中断。应用程序在哪里延迟并不是至关重要的，你可以通过优化吞吐量来解决，但是在大多数情况下，它会引起不必要的中断。

那么，当需要引入更大的堆，但是又不希望引入64位架构带来的这些影响时，我该怎么做呢？在这篇文章中提供了几个技巧——堆分区、GC调优、在不同的JVM上构建或者离堆分配内存。

重申一下，在选择64位的时候要意识到它所带来的影响。但是不要害怕去选择。