我已经使用Java一段时间了，而我设置新开发机器的典型仪式需要从Oracle网站下载和安装最新JDK的规范。
今天提出了一个不寻常的问题does it matter if I use the 32bit or 64bit JRE bundle?
从回想起来，我之前已经安装了两个版本，我的正常工具链很快就插入（Eclipse）。在我的日常编程中，我不记得曾经因为我使用的是64位JRE（或针对这方面针对64位JRE）而不得不以不同的方式改变某些东西或思考某些东西。
根据我对64位与32位的理解 - 它实际上归结为数字如何存储在封面下...我知道int是32位而long是64位位...与float为32位且double为64位相同 - 所以它只是Java已经抽象出这个微妙之处，并且可能一直是“64位兼容”？
我确信我在这里缺少一些东西，除了无法在32位系统上安装64位JRE。
答案 0 :(得分：19)
64位与32位实际上归结为对象引用的大小，而不是数字的大小。
在32位模式下，引用是四个字节，允许JVM唯一地寻址2 ^ 32字节的内存。这就是32位JVM限制为最大堆大小为4GB的原因（实际上，由于其他JVM和操作系统开销，限制较小，并且因OS而异）。
在64位模式下，引用是（惊讶）8个字节，允许JVM唯一地寻址2 ^ 64字节的内存，这对任何人来说应该足够了。
，64位模式下的JVM堆大小（用-Xmx指定）可能很大。
但是64位模式带来了成本：引用的大小增加了一倍，增加了内存消耗。这就是Oracle引入"Compressed oops"的原因。启用压缩oops（我相信现在是默认值），对象引用缩小到四个字节，但需要注意的是堆限制为40亿个对象（和32GB Xmx）。压缩的oops不是免费的：实现内存消耗的大幅减少需要很小的计算成本。
作为个人喜好，我总是在家里运行64位JVM。 CPU支持x64，操作系统也是如此，所以我也喜欢JVM在64位模式下运行。
答案 1 :(得分：5)
正如您所注意到的，Java中的原始数字类型是明确定义的。
但是，如果您的Java应用程序使用本机代码库（可能是为在32位应用程序中使用而构建的），那么32位和64位JVM 之间的选择可能 64位应用程序，或两者兼而有之。
如果您的本机库仅支持32位应用程序，则需要使用32位JVM，或者构建64位版本的库。
答案 2 :(得分：2)
我认为有两个主要区别需要考虑。这里提到了一个而不是另一个。
一方面，正如其他提到的那样， 内存和数据类型 。 32位和64位JVM使用不同的本机数据类型大小和内存地址空间。
另一方面， 支持的本机库 。使用JNI访问本机库的Java程序需要不同的版本，具体取决于JVM的类型。
答案 3 :(得分：1)
根据上下文，对于本地开发，我将始终使用64位JDK。主要是因为我可能需要构建和IDE的整个内存空间。
如果说要集成到生产中，我建议使用32位，如果可能的话。为什么呢？
对于某些许可用于生产的Java EE服务器，它将取决于某些因素，例如哪些机器有多少核心等。具体而言，对于WebSphere Liberty Profile，您也限制为2GB。
64位JRE会占用更多的内存，如果你试图将它限制在2GB或更好的2x 1GB集群，那么你可以有更多的灵活空间来解决这个问题而无需花费一分钱。
来自https://plumbr.eu/blog/java/should-i-use-32-or-64-bit-jvm
问题1：64位需要30-50％的堆。为什么这样？主要 因为64位架构中的内存布局。首先 - 对象头在64位JVM上是12个字节。其次，对象引用 可以是4个字节或8个字节，具体取决于JVM标志和大小 的堆。与8相比，这肯定会增加一些开销 32位上的字节上的字节和引用上的4个字节。你也可以挖掘 进入我们之前的一篇帖子，了解有关计算的更多信息 对象的内存消耗。
问题2：更长时间的垃圾收集暂停。建立更多堆 意味着GC在清理时还有更多工作要做 未使用的物体现实生活中的意义在于你必须做到 构建大于12-16GB的堆时要格外小心。没有罚款 调整和测量您可以轻松地引入完整的GC暂停 几分钟。在延迟并不重要的应用程序中 可以优化吞吐量只有这可能没问题，但在大多数情况下 这可能会成为一个障碍。
要限制您对Java EE环境的影响，请将其部分卸载到其他微服务（如ElasticSearch for search），Hazelcast缓存，数据存储数据库以及让Java EE服务器托管您的应用程序核心而不是运行里面的服务。
答案 4 :(得分：1)
我是否需要了解32位JVM和64位JVM之间的区别？
如果您不构建性能关键型应用程序，则不必了解两者之间的区别。 32位JVM和64位JVM之间的细微差别不会对您的应用程序产生太大影响。您可以跳过进一步阅读
64位JVM的性能是否优于32位JVM？
我们大多数人认为64位大于32位，因此64位JVM性能将优于32位JVM性能。不幸的是，事实并非如此。与32位JVM相比，64位JVM的性能可能会有所下降。以下是Oracle JDK文档中有关64位JVM性能的摘录：
“通常，与在32位VM上运行相同的应用程序相比，能够处理大量内存的优势是64位VM的性能损失很小。
将运行在64位平台上的应用程序与SPARC上的32位平台上运行的应用程序进行比较时，性能差异在移至64位VM时降低了10-20％。在AMD64和EM64T平台上，此差异范围为0-15％，具体取决于访问应用程序所执行的指针的数量。”
Does 32 bit JVM or 64 bit JVM matter anymore.
从32位JVM迁移到64位JVM时要考虑什么？ 一种。 GC暂停时间
从32位JVM迁移到64位JVM的主要原因是要获得较大的堆大小（即-Xmx）。当增加堆大小时，GC暂停时间会自动开始变长，因为现在内存中有更多垃圾需要清除。在进行迁移之前，您需要进行适当的GC调整，否则您的应用程序可能会经历几秒钟到几分钟的暂停时间。您可以使用GCeasy之类的工具来为新增加的堆大小提供正确的GC设置。
b。原生库
如果您的应用程序正在使用Java本机接口（JNI）访问本机库，那么您还需要升级本机库。因为32位JVM只能使用32位本机库。同样，64位JVM只能使用64位本机库。