在 64 位 JVM 中，对象引用默认是 64 位宽。CompressedOops 是 JVM 提供的一种指针压缩机制，它可以在堆内存不超过一定范围时，用 32 位来存储对象引用，从而大幅减少内存占用并提升缓存命中率。当堆内存接近并超过 32G 时，这种压缩往往会失效，引发明显的性能差异。
什么是 CompressedOops
CompressedOops 全称 Compressed Ordinary Object Pointers，即压缩普通对象指针。其原理是利用对象地址按 8 字节对齐的特性，将 64 位指针右移 3 位后存入 32 位整数中，访问时再左移还原。这样在 64 位机器上，32 位引用可寻址的最大空间为 2 的 35 次方，即 32G 左右。
开启与验证
在 HotSpot JVM 中，通常当最大堆小于 32G 时会默认开启，也可以通过参数显式控制：
# 查看当前 JVM 是否开启压缩指针 java -XX:+PrintFlagsFinal -version | grep CompressedOops # 显式开启 -XX:+UseCompressedOops # 显式关闭 -XX:-UseCompressedOops
为什么是 32G 临界点
由于压缩指针使用 32 位存储偏移量，并且假设对象 8 字节对齐，可表示的堆范围为：
4G * 8 = 32G
当堆小于该值时，JVM 可以用 32 位引用覆盖全部对象地址；一旦超过，就必须使用 64 位原生指针，否则无法寻址。此时每个对象引用从 4 字节变为 8 字节，造成以下影响：
- 对象头变大，相同数据占用更多内存
- GC 扫描和复制对象时搬运的引用数据量翻倍
- CPU 缓存可容纳的对象数量减少，命中率下降
性能差异示例对比
假设有一个简单的 Java 对象数组，对比开启与关闭压缩指针时的内存布局差异：
// 模拟大量对象引用场景
import java.util.ArrayList;
import java.util.List;
public class RefDemo {
public static void main(String[] args) {
List<Object> list = new ArrayList<>();
for (int i = 0; i < 10_000_000; i++) {
list.add(new Object());
}
System.out.println("引用数量: " + list.size());
}
}
在 32G 以内堆中运行，上述 list 中每个引用占 4 字节；若堆超过 32G 且压缩失效，则每个引用占 8 字节，仅引用就多出约 40MB 开销，且 GC 成本随之上升。
实际调优建议
| 堆大小 | 压缩指针 | 建议 |
|---|---|---|
| 小于 32G | 生效 | 默认即可，性价比最高 |
| 略超 32G | 失效 | 尽量避免，可回退到 31G |
| 远大于 32G | 失效 | 评估是否需拆分实例或增大缓存 |
常见误区
有人误以为堆越大越好，但在 32G 到 40G 这段区间，由于压缩失效却未带来相应吞吐提升，往往出现性能不升反降。因此生产环境常将 -Xmx 设为 31G 或 32G 以内。
合理理解 CompressedOops 与 32G 临界点的关系，是 JVM 内存规划的基础能力。
小结
通过 CompressedOops 技术，JVM 在 32G 以内用 32 位引用显著节省空间与带宽。一旦越过 32G 临界点，指针压缩关闭，引用膨胀为 64 位，带来更高的内存与 GC 负担。掌握这一机制可帮助我们在容量规划时做出更合理的决策。
CompressedOopsJVM指针压缩32G内存临界点修改时间：2026-07-30 23:42:26