java – JRE 32位vs 64位

我一直在使用Java一段时间,而我设置新开发机器的典型仪式需要从Oracle网站下载和安装最新JDK的规范.

这引发了一个不寻常的问题,如果我使用32位或64位JRE捆绑包有什么关系吗？

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

根据我对64位与32位的理解 – 它实际上归结为数字如何存储在封面下…我知道int是32位而long是64位…同样浮点数为32位且double是64位 – 所以只是Java已经抽象出了这个微妙之处,并且可能一直都是“64位兼容”？

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

解决方法:

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位模式下运行.

标签：java,x86,x86-64,jvm-hotspot
来源： https://codeday.me/bug/20190926/1822085.html