JRE 32 位与 64 位

Question

我已经使用 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 之外，我确定我在这里遗漏了一些东西。

Answer 1

64 位与 32 位真正归结为对象引用的大小，而不是数字的大小。

在 32 位模式下，引用是四个字节，允许 JVM 唯一寻址 2^32 个字节的内存。 这就是 32 位 JVM 的最大堆大小限制为 4GB 的原因（实际上，由于其他 JVM 和操作系统开销，限制较小，并且因操作系统而异）。

在 64 位模式下，引用是（令人惊讶的）8 个字节，允许 JVM 唯一寻址 2^64 个字节的内存，这对任何人来说都足够了。 64 位模式下的 JVM 堆大小（用-Xmx指定）可能很大。

但是 64 位模式是有代价的：引用的大小增加了一倍，增加了内存消耗。 这就是 Oracle 引入“压缩 oops”的原因。 启用压缩 oops（我认为现在是默认设置）后，对象引用缩小到 4 个字节，但需要注意的是，堆限制为 40 亿个对象（和 32GB Xmx）。 压缩 oops 不是免费的：实现内存消耗的大幅减少需要很小的计算成本。

作为个人偏好，我总是在家里运行 64 位 JVM。 CPU 支持 x64，操作系统也是如此，所以我也喜欢 JVM 以 64 位模式运行。

Answer 2

正如您所注意到的，Java 中的原始数字类型是明确定义的。

然而，32位和64位JVM之间的选择可能，如果你的Java应用程序使用本机代码库，它可以在32位应用程序，64位应用程序，或两者使用内置无所谓。

如果您有仅支持 32 位应用程序的本机库，则需要使用 32 位 JVM，或者构建 64 位版本的库。

Answer 3

根据上下文，对于本地开发，我将始终使用 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 标志和堆的大小。 与 32 位标头上的 8 个字节和引用上的 4 个字节相比，这肯定会增加一些开销。 您还可以深入研究我们之前的一篇文章，了解有关计算对象内存消耗的更多信息。

问题 2：更长的垃圾收集暂停。 建立更多的堆意味着在从未使用的对象中清除它的同时，GC 需要做更多的工作。 这意味着在现实生活中，构建大于 12-16GB 的堆时必须格外小心。 无需微调和测量，您就可以轻松引入跨越几分钟的完整 GC 暂停。 在延迟并不重要并且您可以优化吞吐量的应用程序中，这可能没问题，但在大多数情况下，这可能会成为一个阻碍。

为了限制您对 Java EE 环境的影响，将其中的一部分卸载到其他微服务，例如用于搜索的 ElasticSearch、用于缓存的 Hazelcast、用于数据存储的数据库，并让您的 Java EE 服务器托管您的应用程序核心本身，而不是在内部运行服务它。

Answer 4

我认为有两个主要差异需要考虑。 这里提到了一个，但没有提到另一个。

一方面，正如其他人提到的，内存和数据类型。 32 位和 64 位 JVM 使用不同的本机数据类型大小和内存地址空间。

• 64 位 JVM 可以分配（可以使用）比 32 位 JVM 更多的内存。
• 64 位使用容量更大但占用更多空间的本机数据类型。 因为那样，同一个对象也可能占用更多空间。
• 对于垃圾收集器 (GC) 冻结机器的 JVM，64 位版本可能会更慢，因为 GC 必须检查更大的堆/对象并且需要更多时间。
• 有一个IBM 演示文稿解释了这些差异。

另一方面，支持的本机库. 使用 JNI 访问本机库的 Java 程序需要不同的版本，具体取决于 JVM 的类型。

• 32 位 JVM 使用 32 位本机库，64 位 JVM 使用 64 位库。
• 这意味着，如果您的程序使用依赖于本机代码的库，例如 SWT，您将需要它们的不同版本。 请注意，在SWT 下载页面 中，Linux/Windows 32 位和 64 位有不同的版本。 请注意，对于 32 位和 64 位，有不同版本的 Eclipse （每个版本都有不同版本的 SWT）。
• 某些应用程序（例如 Alloy）与 32 位本机库一起打包。 它们在 64 位 JVM 上失败。 您只需下载相应的 64 位本机库并适当配置 JNI 即可解决这些问题。

Answer 5

我需要了解 32 位 JVM 和 64 位 JVM 之间的区别吗？

如果您不构建性能关键的应用程序，则不必了解其中的区别。 32 位 JVM 和 64 位 JVM 之间的细微差别不会对您的应用程序产生太大影响。 你可以跳过阅读进一步

64 位 JVM 是否比 32 位 JVM 性能更好？

我们大多数人都认为 64 位大于 32 位，因此 64 位 JVM 性能会优于 32 位 JVM 性能。 不幸的是，事实并非如此。 64 位 JVM 的性能下降可能比 32 位 JVM 小。 以下是 Oracle JDK 文档中关于 64 位 JVM 性能的摘录：

“通常，与在 32 位虚拟机上运行相同的应用程序相比，能够处理大量内存的好处是在 64 位虚拟机中性能损失很小。

当您迁移到 64 位虚拟机时，在 64 位平台上运行的应用程序与在 SPARC 上运行的 32 位平台的性能差异大约会降低 10-20%。 在 AMD64 和 EM64T 平台上，此差异范围为 0-15%，具体取决于访问应用程序执行的指针数量。”

32 位 JVM 还是 64 位 JVM 不再重要了。

从 32 位 JVM 迁移到 64 位 JVM 时需要考虑哪些事项？ 一种。 GC 暂停次数

从 32 位 JVM 迁移到 64 位 JVM 的主要原因是获得大堆大小（即 -Xmx）。 当你增加堆大小时，你的 GC 暂停时间会自动开始变高，因为现在内存中有更多的垃圾需要清理。 在进行迁移之前，您需要进行适当的 GC 调整，否则您的应用程序可能会遇到几秒钟到几分钟的暂停时间。

湾本地库

如果您的应用程序使用 Java 本机接口 (JNI) 来访问本机库，那么您还需要升级本机库。 因为 32 位 JVM 只能使用 32 位本机库。 同样，64 位 JVM 只能使用 64 位本机库。