应该使用32位还是64位JVM

应用使用32位的JVM，还是应该使用64位的JVM，我自己以前还真没想过，大家都想过了吗？本文是 Plumbr 中的一篇 博文 ，为大家提了个醒。(2012.11.27最后更新)

    在我的企业级软件开发职业生涯中，我多次面对这个问题。每隔一段时间我不得不建议配置一个新的特定环境。而往往该问题部分与"我应该使用32位还是64位JVM？"这一问题有关。老实说，一开始我是靠掷硬币来解决的，而不是给出一个合理的答案。(抱歉，兄弟们！)但现在我对这个问题有了更多的领悟，并想与你们分享。
    第一步--越多越好，对吗？即如此，因为64>32，所以答案很简单：如果可能的话，应该总是选择64位？好吧，请耐心点儿。64位架构的坏处是，相同的数据结构会消耗更多的内存，甚至是多很多。我们的测评显示，根据不同的JVM版本和操作系统版本，以及相应的硬件架构，最终会用掉比32位架构多30-50%的堆内存。更大的堆也会造成更长的GC暂停，这会对应用程序造成潜在的影响--在4.5G的堆上执行完全GC肯定会比在3G的堆上执行花费更长的时间。所以，仅仅是因为64比32大就去赶64位JVM的时髦，肯定是错误的。
    但，什么时候才是使用64位JVM的好时机呢？多数情况下，要看堆的大小。在不同的平台下，你很快就得面对32位JVM堆内存的上限问题。下表列出了在不同平台下的这种限制：
Linux         2GB       特定内核，如hugemem，可以达到3G
Windows    1.5GB    使用"/3G"的启动参数并使用/LARGEADDRESSAWARE参数去编译JRE，则可提高到3G
Mac OS X   3.8GB    警告--未能找到老的Mac，所以没有对其进行测试

    那么，这有什么坏处？我打赌，你肯定见过在16G的RAM上运行32位的机器。问题就在于，在只有16G RAM的Windows系统中，JVM只能分配到少于10%的内存。
    主因--地址空间。在32位系统中，理论上可以为每个进程分配4G内存。而Windows系统对地址空间的处理使这一理论值无法达到。Windows将进程的地址空间砍掉了一半。一半留给了内核(用户进程无法使用它)，另一半则留给了用户。无论系统中有多大的RAM，32位进程只能使用到2G的RAM。更糟的是--地址空间必须是连续的，所以在实践中，Windows系统最多只为你剩下了1.5-1.8G的堆内存。
    有一个在32位Windows系统中减少内核空间并增加用户空间的窍门，即，可以在boot.ini系统使用/3GB参数。然而，为了能确保它有效，必须使用/LARGEADDRESSAWARE开关去编译或链接JVM。
    不幸地是，至少对于HotSpot JVM无法做到这一点。直到最新的JDK 1.7版本，HotSpot JVM仍未使用该选项进行编译。但又幸运地是，如果你运行2006年之后的JRockit版本，就能享用到2.8-2.9G的堆大小。
    那么，我们是否可以得出结论，如果你的应用要求大于2-3G的内存，你就总是应该运行64位的JVM？也许。但你也必须要清楚应用的场景。我们已经介绍了使用64位JVM的坏处--增加的堆消耗，以及更长的GC中断。让我们分析一下原因。
     问题1：64位JVM需要多出30-50%的内存。 为什么会如此呢？主要是因为内存是以64位架构进行部局。首先，在64位JVM中，对象头有12字节。其次，对象引用会占用4字节或8字节，实际值取决于JVM的参数与堆的大小。相较于32位JVM的8字节对象头和4字节对象引用，毫无疑问会增加一些开销。在我们 之前发布的博客 中你会找到更多关于如何计算对象内存的相关信息。
     问题2：更长的垃圾收集中断。 构建更大的堆意味着GC要做更多的工作去清理无用的对象。这意味着，在实际应用中构建大于12-16G的堆时，你必须要特别小心。没有很好的性能调优与测评，你很容易就会引起一个耗时数分钟的完全GC。在应用程序的非关键潜在危险场景中，通过对吞吐量的优化或许能解决这一问题，但在多数情况下，它会造成程序中断。
    当我需要更大的内存且又不希望引入由64位架构所造成的开销，那该怎么办呢？在我们 以前的一篇博文 中已经涉及了这个问题--通过对堆的分区，GC调优，构建不同的JVM，或对堆分配不同的内存，就可以避免这一问题。
    最后，让我们重申，你应该总是要意识到选择64位JVM的后果，但也不要惧怕这一选择。