JRE 32位对比64位
我一直在使用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。
64位与32位实际上归结为对象引用的大小，而不是数字的大小。
在32位模式下，引用是四个字节，允许JVM唯一地寻址2 ^ 32字节的内存。 这就是32位JVM限制为4GB的最大堆大小的原因（实际上，由于其他JVM和OS开销，限制较小，并且根据操作系统而不同）。
在64位模式下，引用是（惊讶）8个字节，允许JVM唯一地寻址2 ^ 64字节的内存，这对任何人来说应该足够了。 64位模式下的JVM堆大小（使用-Xmx指定）可能很大。
但是64位模式带来了成本：引用的大小增加了一倍，增加了内存消耗。 这就是Oracle推出“压缩oops”的原因 。 启用压缩oops（我相信现在是默认值），对象引用缩小到四个字节，但需要注意的是堆限制为40亿个对象（以及32GB Xmx）。 压缩的oops不是免费的：实现内存消耗的大幅减少需要很小的计算成本。
作为个人喜好，我总是在家里运行64位JVM。 CPU支持x64，操作系统也是如此，所以我也喜欢JVM在64位模式下运行。
如您所知，Java中的原始数字类型是明确定义的。
但是，如果您的Java应用程序使用本机代码库，则可以选择32位和64位JVM，这些库可以构建用于32位应用程序，64位应用程序或两者。
如果您具有仅支持32位应用程序的本机库，则需要使用32位JVM，或者构建64位版本的库。
我认为有两个主要差异需要考虑。 这里提到的是一个而不是另一个。
一方面，正如其他提到的， 内存和数据类型 。 32位和64位JVM使用不同的本机数据类型大小和内存地址空间。
- 64位JVM可以分配（可以使用）比32位更多的内存。
- 64位使用具有更多容量的本机数据类型但占用更多空间。 因为这样，同一个Object也可能占用更多空间。
- 对于垃圾收集器（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即可解决这些问题。
根据上下文，对于本地开发，我将始终使用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 for search），Hazelcast缓存，数据存储数据库以及保持Java EE服务器托管应用程序核心本身而不是运行内部服务它。