jvm在64位系统下通过利用对象8字节对齐特性，隐去地址末3位实现32gb寻址；zero-based模式下直接左移3位复原地址；超32gb则关闭压缩指针。
JVM 在 64 位系统下实现 32GB 寻址空间，不是靠“多级指针压缩”，而是利用对象地址天然的 8 字节对齐 特性，做了一次轻量、高效的位移编码——本质是单级、无基址的偏移寻址优化。
为什么能省掉 3 位？因为地址末尾恒为 000
Java 对象在堆中强制按 8 字节边界对齐，意味着每个对象起始地址的二进制表示末三位一定是 000。例如地址 0x1000、0x1008、0x1010……它们除以 8 后都是整数。JVM 就把这固定的 3 个零“隐去”，只用剩余高位存储偏移量。
- 32 位压缩指针可表示 2³² 个不同值（0 到 4,294,967,295）
- 每个值代表一个 8 字节步长：实际地址 = 偏移量 × 8
- 最大可寻址 = 2³² × 8 = 34,359,738,368 字节 = 32GB
Zero-based 模式：不依赖基址，直接乘 8 复原
当整个堆内存布局落在低 32GB 地址空间内（即最高地址
- 压缩指针值直接作为偏移量（offset），无需额外基址（base）
- 真实内存地址 = offset
- 这种模式最简洁、无分支、CPU 友好，也是默认启用的主流场景
对齐不是代价，而是前提和红利
8 字节对齐不是为了压缩而设，而是 JVM 和现代 CPU 共同选择的性能最优布局策略：
- 处理器访问对齐地址更快（避免跨缓存行、减少总线周期）
- 对齐让“末三位为零”成为确定性事实，压缩才具备数学安全性
- 若强行改成 16 字节对齐（想支持 64GB），虽可省 4 位，但填充浪费陡增，净收益为负——所以没采用
超过 32GB 就失效，没有“升级版压缩”
一旦 -Xmx 设为 33G，堆顶地址必然 ≥ 0x800000000，此时 32 位 offset × 8 无法覆盖全部地址空间，JVM 会自动关闭 UseCompressedOops：
- 所有引用字段、Klass 指针、数组头指针回归 8 字节原生宽度
- 对象头从 12 字节（压缩）涨到 24 字节（非压缩）
- 字段排列因 8 字节对齐规则被连锁放大，比如 int + Object 组合多占 4 字节填充
