理解 JVM 如何使用 Windows 和 Linux 上的本机内存（5）消除限制：更改为 64 位

look_w

使用 32 位 Java 运行时很容易遇到本机内存耗尽的情况，因为地址空间相对较小。32 位操作系统提供的 2 到 4GB 用户空间通常小于系统附带的物理内存量，而且现代的数据密集型应用程序很容易耗尽可用空间。
如果 32 位地址空间不够您的应用程序使用，您可以通过移动到 64 位 Java 运行时来获得更多用户空间。如果您运行的是 64 位操作系统，那么 64 位 Java 运行时将能够满足海量 Java 堆的需求，还会减少与地址空间相关的问题。表 2 列出了 64 位操作系统上目前可用的用户空间。
表 2. 64 位操作系统上的用户空间大小操作系统默认用户空间大小Windows x86-648192GBWindows Itanium7152GBLinux x86-64500GBLinux PPC641648GBLinux 390 644EB
然而，移动到 64 位并不是所有本机内存问题的通用解决方案，您仍然需要足够的物理内存来持有所有数据。如果物理内存不够 Java 运行时使用，运行时性能将变得非常糟，因为操作系统不得不在内存与交换空间之间来回复制 Java 运行时数据。出于相同原因，移动到 64 位也不是内存泄漏永恒的解决方案，您只是提供了更多空间来供泄漏，这只会延缓您不得不重启应用程序的时间。
无法在 64 位运行时中使用 32 位本机代码。任何本机代码（JNI 库、JVM Tool Interface [JVMTI]、JVM Profiling Interface [JVMPI] 以及 JVM Debug Interface [JVMDI] 代理）都必须编译为 64 位。64 位运行时的性能也可能比相同硬件上对应的 32 位运行时更慢。64 位运行时使用 64 位指针（本机地址引用），因此，64 位运行时上的 Java 对象会占用比 32 位运行时上包含相同数据的对象更多的空间。更大的对象意味着要使用更大的堆来持有相同的数据量，同时保持类似的 GC 性能，这使操作系统和硬件缓存效率更低。令人惊讶的是，更大的 Java 堆并不一定意味着更长的 GC 暂停时间，因为堆上的活动数据量可能不会增加，并且一些 GC 算法在使用更大的堆时效率更高。
一些现代 Java 运行时包含减轻 64 位 “对象膨胀” 和改善性能的技术。这些功能在 64 位运行时上使用更短的引用。这在 IBM 实现中称为压缩引用，而在 Sun 实现中称为压缩 oop。
对 Java 运行时性能的比较研究不属于本文讨论范围，但是如果您正在考虑移动到 64 位，尽早测试应用程序以理解其执行原理会很有帮助。由于更改地址大小会影响到 Java 堆，所以您将需要在新架构上重新调优您的 GC 设置，而不是仅仅移植现有设置。