指针压缩省的是Java对象引用、类元数据指针及数组元素起始地址等的内存，将8字节指针利用8字节对齐特性截去末3位0存为4字节，单对象可省8–12字节，亿级小对象可减少数GB堆内存。
指针压缩到底省了什么内存？
它把原本 8 字节的 Java 对象引用（Oop）和类元数据指针（Klass Pointer）压成 4 字节——不是靠算法“压缩”，而是利用对象必然 8 字节对齐这个事实，把地址末尾固定的 3 个 0 省掉，存的时候只记高位 32 位，用的时候左移 3 位补零还原。
实际效果很直观：一个含两个引用字段的 MyObject，未压缩时对象头+字段至少占 24 字节；启用后能缩到约 16 字节，单对象省 8–12 字节。亿级小对象场景下，堆直接少占几 GB。
- 省的是所有引用字段、对象头里的
Klass指针、数组长度之后的元素起始地址等 - 不压缩局部变量、栈帧中的临时引用，也不压缩 native 代码持有的指针
-
String、ArrayList、HashMap这类大量持有引用的容器受益最明显
什么时候自动开启？什么时候会失效？
JVM 不靠你手动加 -XX:+UseCompressedOops 来决定是否启用——它看最大堆大小（-Xmx）自动判断：
- 堆 ≤ 4GB：直接关掉压缩，用纯 32 位寻址，零开销
- 4GB ptr
- 堆 > 32GB：JVM 自动禁用
UseCompressedOops，除非你显式调大对齐（如-XX:ObjectAlignmentInBytes=16），但那样会浪费更多填充字节
注意：-XX:+UseCompressedOops 在 JDK 8u60+ 的 64 位 HotSpot 上默认开启，但如果你设了 -Xmx33g，哪怕加了这个参数，JVM 启动日志里也会打印 Compressed Oops is disabled。
立即学习“Java免费学习笔记（深入）”；
禁用或强制启用会出什么问题？
手动干预通常没必要，强行改反而容易踩坑：
- 设
-XX:-UseCompressedOops且堆 ≤ 32GB：内存多用 30%~50%，GC 更频繁，CPU 缓存行塞得更满，性能反降 - 设
-XX:+UseCompressedOops但堆 > 32GB：JVM 启动失败，报错Error: Could not create the Java Virtual Machine.或静默降级（取决于版本） - 某些 JNI 库（如旧版 Netty native transport、部分监控 agent）假设指针是 8 字节，若压缩开启又没适配，可能触发
AccessViolation或随机崩溃
真要禁用，只建议在明确需要对接非压缩 ABI 的 native 组件，且已验证兼容性时才做。
怎么确认当前 JVM 是否在用指针压缩？
别猜，看启动日志或运行时输出：
- 启动加
-XX:+PrintGCDetails -XX:+UnlockDiagnosticVMOptions -XX:+PrintCompressedOopsMode，会打出类似：heap address: 0x0000000700000000, size: 8192 MB, Compressed Oops mode: Zero based - 运行中用
jstat -gc <pid>看堆大小，再对照上面的区间判断 - JDK 9+ 可用
jcmd <pid> VM.native_memory summary查看指针宽度相关统计
真正容易被忽略的是：压缩是否生效，不取决于你写了什么参数，而取决于 -Xmx 实际值 + JVM 版本 + OS 内存布局三者共同作用的结果。调参前先看日志，比查文档更快。
