
在java虚拟机(jvm)中,为了节省内存并提高缓存效率,引入了指针压缩(compressed pointers)机制。它主要分为两类:
压缩对象指针 (Compressed Ordinary Object Pointers, Compressed Oops): 当Java堆内存大小在一定范围内(通常是32GB以下)时,JVM可以将64位对象引用(8字节)压缩为32位(4字节)。这是通过将对象地址视为相对于堆基址的偏移量,并假设对象总是8字节对齐来实现的。这样,一个32位的偏移量可以表示高达2^35字节(32GB)的地址空间。当堆内存超过32GB时,Compressed Oops 通常会自动禁用,对象引用会恢复为8字节。
压缩类指针 (Compressed Class Pointers): 每个Java对象在内存中都包含一个指向其Class对象的指针。这个指针指向了该对象的类型信息,是对象头的一部分。与Compressed Oops类似,Compressed Class Pointers 机制旨在将这个Class指针从8字节压缩为4字节,从而进一步减少每个对象的内存开销。
用户可能会观察到,在Java 11中,当堆内存超过32GB时,对象的内存占用会显著增加,而在Java 19中,即使堆内存达到41GB,某些对象的内存占用却依然较低,这似乎与Compressed Oops的32GB限制相矛盾。这种差异的根源不在于对象引用(Oops)本身的压缩,而在于类指针(Class Pointer)的压缩行为。
在JDK 15之前,UseCompressedClassPointers 这个JVM选项与 UseCompressedOops 选项是紧密绑定的。这意味着:
因此,在JDK 11(早于JDK 15)中,当堆内存设置为41GB时,不仅对象引用会是8字节,每个对象的类指针也会是8字节,从而增加了对象的整体内存开销。
OpenJDK社区通过 JDK-8241825: Make compressed oops and compressed class pointers independent 这一改进,解决了上述绑定问题。自JDK 15起,UseCompressedClassPointers 选项变得独立于 UseCompressedOops。这意味着:
这个改变显著降低了每个Java对象的元数据开销,即使在无法压缩对象引用的大堆内存环境中,也能实现内存效率的提升。
为了直观地展示这一变化,我们可以使用 Java Object Layout (JOL) 工具来分析对象的内存布局。以下代码片段展示了如何打印一个 Object 数组的内存布局:
import org.openjdk.jol.info.ClassLayout;
public class ObjectMemoryLayout {
public static void main(String[] args) {
// 打印一个包含3个Object引用的数组的内存布局
System.out.println(ClassLayout.parseInstance(new Object[3]).toPrintable());
}
}使用上述代码,并在不同JDK版本和堆大小下运行,我们可以观察到以下差异:
1. JDK 11 (或更早版本,堆大小 41GB)
在JDK 11环境下,使用 -Xms41g -Xmx41g 运行,Object 数组的内存布局可能类似如下:
[Ljava.lang.Object; object internals: OFF SZ TYPE DESCRIPTION VALUE 0 8 (object header: mark) 0x0000000000000001 (non-biasable; age: 0) 8 8 (object header: class) 0x000001f54bec41e0 <-- 注意这里是8字节 16 4 (array length) 3 20 4 (alignment/padding gap) 24 24 java.lang.Object Object;.<elements> N/A Instance size: 48 bytes Space losses: 4 bytes internal + 0 bytes external = 4 bytes total
可以看到,object header: class 字段占用了8字节,导致整个 Object[3] 实例的大小为48字节。这是因为 UseCompressedClassPointers 随 UseCompressedOops 一同被禁用。
2. JDK 15 或更新版本 (例如 JDK 19,堆大小 41GB)
在JDK 15或更高版本(如JDK 19)环境下,使用 -Xms41g -Xmx41g 运行,Object 数组的内存布局可能类似如下:
[Ljava.lang.Object; object internals: OFF SZ TYPE DESCRIPTION VALUE 0 8 (object header: mark) 0x0000000000000001 (non-biasable; age: 0) 8 4 (object header: class) 0x000020fc <-- 注意这里是4字节 12 4 (array length) 3 16 24 java.lang.Object Object;.<elements> N/A Instance size: 40 bytes Space losses: 0 bytes internal + 0 bytes external = 0 bytes total
在此输出中,object header: class 字段仅占用4字节。由于类指针的压缩,以及相应的填充调整,整个 Object[3] 实例的大小减少到了40字节。值得注意的是,Object;.<elements> 部分(即数组中存储的3个 Object 引用)在两种情况下都占用了24字节(每个引用8字节,因为 UseCompressedOops 已禁用),这进一步证明了差异在于类指针,而非对象引用本身。
从JDK 15开始,Java虚拟机在处理大堆内存时,通过使压缩类指针独立于压缩对象指针,显著优化了对象的内存占用。这意味着即使您的应用程序需要超过32GB的堆内存,并且无法利用Compressed Oops来压缩对象引用,JVM仍然可以通过压缩类指针来减少每个对象的固定开销。
主要启示:
通过利用这些JVM内部的优化,开发者可以更好地管理和利用系统资源,尤其是在处理大规模数据和高并发场景下的Java应用程序时。
以上就是OpenJDK 15+ 内存优化:深入理解大堆场景下的压缩类指针的详细内容,更多请关注php中文网其它相关文章!
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移,垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是,许多工具可以让 Windows 保持平稳运行。
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号