Java 64位JVM默认启用指针压缩（-XX:+UseCompressedOops），堆≤32GB时自动生效，将对象引用、Klass Pointer等8字节指针压缩为4字节，利用对象8字节对齐特性截去地址末3位0实现，超32GB则强制禁用。
Java 在 64 位 JVM 上默认启用指针压缩（-XX:+UseCompressedOops），它不是“需要手动加参数才生效”，而是从 JDK 6u23 起默认开启，只要堆内存 ≤ 32GB 就自动生效。它的核心目标是把原本 8 字节的对象引用（OOP）压缩成 4 字节，从而显著降低对象内存开销。
哪些指针会被压缩？
压缩的不是所有地址，而是 JVM 内部用于寻址的“普通对象指针”（Ordinary Object Pointers，即 oop），主要包括：
- 对象实例中的引用字段（如
String s;、List<?> list;等） - 对象头里的 Klass Pointer（指向方法区中类元数据的指针）
- 数组对象的元素引用（如
Object[] arr;中每个 slot 的引用） - 静态变量表（Constant Pool 中的类、字段、方法符号引用）中的部分指针
注意：基本类型（int、long）、原始数组（int[]、byte[]）不涉及指针压缩；线程栈、本地方法栈、JIT 编译代码等 native 区域的指针也不压缩。
压缩是怎么实现的？
关键前提是：Java 堆内存按 8 字节对齐（即每个对象起始地址必为 8 的倍数）。这意味着真实地址低 3 位恒为 0（如 0x12345678 → 二进制末尾三位是 000）。JVM 利用这一点，只存储地址的高 32 位（去掉末尾三个 0），存入 4 字节空间；使用时左移 3 位还原。
立即学习“Java免费学习笔记（深入）”；
例如：
真实地址 0x0000000123456000（十六进制）→ 二进制末尾三位为 0 → 截取高 32 位 → 存为 0x0000000123456000 >> 3 = 0x0000000012345600（4 字节）
加载时再左移： 0x0000000012345600
因此，32 位压缩地址能表示 2³² × 8 = 32 GB 的堆空间上限 —— 这就是为什么堆超过 32GB 时压缩自动失效。
什么时候会失效？如何确认？
当初始堆（-Xms）或最大堆（-Xmx）设置超过 32GB，JVM 会自动关闭压缩指针（即使你显式写了 -XX:+UseCompressedOops）。你可以通过以下方式验证：
- 启动时加
-XX:+PrintFlagsFinal，搜索UseCompressedOops，看是否为true - 观察 GC 日志中的对象大小：开启压缩后，对象头从 16 字节降至 12 字节（64 位未压缩对象头为 16 字节：8 字节 Mark Word + 8 字节 Klass Pointer；压缩后为 8 + 4，再对齐补至 12）
- 用 JOL（Java Object Layout）工具打印对象内存布局，对比引用字段占用字节数
压缩带来的实际收益与代价
收益明显：
- 单个对象节省 4 字节引用空间，大量小对象（如 POJO、集合节点）累积下来可减少 20%~30% 堆内存占用
- 更小的对象提升 CPU 缓存行（Cache Line）利用率，间接加快访问速度
- 降低 GC 扫描和移动对象的数据量，减轻 GC 压力
代价有限但需注意：
- 每次读写引用需一次位移运算（>3），但现代 CPU 指令极快，几乎无感
- 堆 >32GB 时自动关闭，若强行用
-XX:+UseCompressedOops会报错或被忽略 - 某些特殊场景（如堆接近 32GB 且动态扩容）可能触发临界切换，建议明确设定
-Xms和-Xmx相同值以避免运行时关闭
