14

I've been using Java for a while now, and my typical ritual of setting up a new dev machine requires the norm of downloading and installing the latest JDK from Oracle's site.

This prompted an unusual question today, does it matter if I use the 32bit or 64bit JRE bundle?

From thinking back on it, I've installed both versions before and my normal toolchain plugs happily in (Eclipse). In my day-to-day programming, I do not recall ever having to change something or think about something in a different way just because I was using the 64bit JRE (or targetting the 64bit JRE for that respect).

From my understanding of 64bit vs. 32bit - it really boils down to how the numbers are stored underneath the covers... and I do know that int is a 32 bits and long is 64 bits... same with float being 32 bits and double is 64 bits -- so is it just that Java has abstracted even this subtlety away, and perhaps has been "64 bit compatible" all along?

I'm sure I'm missing something here besides not being able to install a 64 bit JRE onto a 32 bit system.

4

5 回答 5

24

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

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

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

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

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

于 2013-06-25T00:26:42.047 回答
5

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

但是，如果您的 Java 应用程序使用的是本机代码库，那么在 32 位和 64 位 JVM 之间进行选择可能很重要，这些库可能是为在 32 位应用程序、64 位应用程序或两者中使用而构建的。

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

于 2013-06-24T22:10:29.323 回答
3

Depending on context, for local development I will always use a 64-bit JDK. Primarily because I would likely need the whole memory space for builds and the IDE.

That being said for integration to production, I would recommend 32-bit if it is possible. Why?

For some Java EE servers that are licensed for production use, it would depend on some factors like which machine how many cores etc. For WebSphere Liberty Profile specifically, you are also limited to 2GB.

64-bit JREs would take up slightly more memory and if you're trying to constrain it to something like 2GB or better yet 2x 1GB cluster you would have more flex space to work around in without paying a cent.

From https://plumbr.eu/blog/java/should-i-use-32-or-64-bit-jvm

Problem 1: 30-50% of more heap is required on 64-bit. Why so? Mainly because of the memory layout in 64-bit architecture. First of all – object headers are 12 bytes on 64-bit JVM. Secondly, object references can be either 4 bytes or 8 bytes, depending on JVM flags and the size of the heap. This definitely adds some overhead compared to the 8 bytes on headers on 32-bit and 4 bytes on references. You can also dig into one of our earlier posts for more information about calculating the memory consumption of an object.

Problem 2: Longer garbage collection pauses. Building up more heap means there is more work to be done by GC while cleaning it up from unused objects. What it means in real life is that you have to be extra cautious when building heaps larger than 12-16GB. Without fine tuning and measuring you can easily introduce full GC pauses spanning several minutes. In applications where latency is not crucial and you can optimize for throughput only this might be OK, but on most cases this might become a showstopper.

To limit your impact for your Java EE environment, offload parts of it to other microservices such as ElasticSearch for search, Hazelcast for caching, your database for data storage and keep your Java EE server to host your application core itself rather than running the services inside it.

于 2017-06-01T17:06:21.303 回答
2

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

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

  • 64 位 JVM 可以分配（可以使用）比 32 位更多的内存。
  • 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 即可解决这些问题。
于 2017-07-29T03:52:20.473 回答
2

我需要了解 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 位 VM 时，比较在 64 位平台上运行的应用程序与在 SPARC 上运行的 32 位平台的性能差异大约为 10-20%。在 AMD64 和 EM64T 平台上，这种差异范围为 0-15%，具体取决于访问应用程序执行的指针数量。”</p>

32 位 JVM 或 64 位 JVM 不再重要。

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

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

湾。本机库

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

于 2019-06-18T01:02:45.347 回答