JRE 32 位与 64 位 [英] JRE 32bit vs 64bit

问题描述

我已经使用 Java 有一段时间了，我设置新开发机器的典型习惯要求从 Oracle 的站点下载和安装最新的 JDK.

今天提出了一个不寻常的问题，我使用 32 位或 64 位 JRE 包有关系吗?

回想起来，我之前已经安装了这两个版本，并且我的普通工具链愉快地插入 (Eclipse).在我的日常编程中，我不记得曾经因为我使用 64 位 JRE(或在这方面针对 64 位 JRE)而不得不改变某些东西或以不同的方式思考某些东西.

根据我对 64 位与 32 位的理解 - 它实际上归结为数字如何存储在封面下......而且我确实知道 int 是 32 位和 long 是 64 位...与 float 是 32 位和 double 是 64 位一样——所以只是 Java 已经抽象了这种微妙之处，也许一直是64 位兼容"?

除了无法在 32 位系统上安装 64 位 JRE 之外，我确定我在这里遗漏了一些东西.

解决方案

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

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

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

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

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

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.

解决方案

64-bit vs. 32-bit really boils down to the size of object references, not the size of numbers.

In 32-bit mode, references are four bytes, allowing the JVM to uniquely address 2^32 bytes of memory. This is the reason 32-bit JVMs are limited to a maximum heap size of 4GB (in reality, the limit is smaller due to other JVM and OS overhead, and differs depending on the OS).

In 64-bit mode, references are (surprise) eight bytes, allowing the JVM to uniquely address 2^64 bytes of memory, which should be enough for anybody. JVM heap sizes (specified with -Xmx) in 64-bit mode can be huge.

But 64-bit mode comes with a cost: references are double the size, increasing memory consumption. This is why Oracle introduced "Compressed oops". With compressed oops enabled (which I believe is now the default), object references are shrunk to four bytes, with the caveat that the heap is limited to four billion objects (and 32GB Xmx). Compressed oops are not free: there is a small computational cost to achieve this big reduction in memory consumption.

As a personal preference, I always run the 64-bit JVM at home. The CPU is x64 capable, the OS is too, so I like the JVM to run in 64-bit mode as well.

这篇关于JRE 32 位与 64 位的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！