我已经使用Java一段时间了，我设置新开发机器的典型仪式需要从Oracle的网站下载和安装最新的JDK。
这在今天引发了一个不寻常的问题，does it matter if I use the 32bit or 64bit JRE bundle?
回想起来，我之前已经安装了两个版本，我的普通工具链插件很高兴地插入（Eclipse）。在我的日常编程中，我不记得曾经因为使用64位JRE（或针对64位JRE）而不得不改变某些东西或以不同的方式思考某些事情。
根据我对64位与32位的理解 - 它实际上归结为数字如何存储在盖子下面......我确实知道这是一个32位，是64位...与32位和64位相同 - 那么Java是否已经抽象出这种微妙之处，并且可能一直“64位兼容”？intlongfloatdouble
我确信除了无法在32位系统上安装64位JRE之外，我在这里还缺少一些东西。
64 位与 32 位实际上归结为对象引用的大小，而不是数字的大小。
在 32 位模式下，引用为 4 个字节，允许 JVM 对 2^32 字节的内存进行唯一寻址。这就是 32 位 JVM 被限制为最大堆大小为 4GB 的原因（实际上，由于其他 JVM 和操作系统开销，限制较小，并且因操作系统而异）。
在64位模式下，引用是（令人惊讶的）八个字节，允许JVM唯一地寻址2 ^ 64字节的内存，这对任何人来说都应该足够了。64 位模式下的 JVM 堆大小（指定为 ）可能很大。-Xmx
但 64 位模式需要付出代价：引用的大小是原来的两倍，增加了内存消耗。这就是Oracle推出“压缩oops”的原因。启用压缩 oops（我相信现在是默认设置）后，对象引用将缩小到四个字节，但需要注意的是，堆限制为四十亿个对象（和 32GB Xmx）。压缩的oops不是免费的：实现内存消耗的大幅减少需要很小的计算成本。
作为个人偏好，我总是在家里运行64位JVM。CPU支持x64，操作系统也是如此，所以我喜欢JVM在64位模式下运行。
如您所见，Java 中的基元数字类型是明确定义的。
但是，如果您的 Java 应用程序使用的是本机代码库，则在 32 位和 64 位 JVM 之间进行选择可能很重要，这些代码库可能是为在 32 位应用程序和/或 64 位应用程序中使用而构建的。
如果您有仅支持 32 位应用程序的本机库，则需要使用 32 位 JVM，或者构建 64 位版本的库。
