32GB是CompressedOops的硬分界点，由对象8字节对齐导致地址末3位恒为0、32位偏移上限2³²×8=32GiB决定；超此值指针退为8字节，引发对象头膨胀、引用翻倍及GC效率下降。

32GB 不是 JVM 随意定的数字，而是由地址对齐和位运算共同决定的硬性边界。JVM 利用 Java 对象天然 8 字节对齐的特性，把 64 位地址末尾固定的 3 个零截掉，只存高 32 位——寻址时左移 3 位还原。这样 4 字节就能覆盖 2³² × 8 = 32 GiB 的堆地址空间。

为什么是 32GiB，而不是 32GB？

这里的 32 是精确的二进制计算结果：2³² 个偏移单元 × 每单元 8 字节 = 34,359,738,368 字节 = 32 GiB（不是十进制的 32,000,000,000 字节）。JVM 实际判断依据是堆顶地址是否落在这个可寻址窗口内，而非你写的 -Xmx 数值本身。

• 设 -Xmx32768m（即 32×1024 MB），理论刚好卡在上限，但因元空间、直接内存、堆预留区等额外占用，常导致实际地址溢出
• 设 -Xmx32769m，几乎必然触发 CompressedOops 禁用
• 实践中更稳妥的是 -Xmx31g，留出约 1GiB 缓冲，大幅降低 fallback 风险

启用与失效的真实判断标准

别信配置参数值，要看运行时实际生效状态。-XX:+PrintFlagsFinal 显示 UseCompressedOops = true，不代表真启用；它只说明参数被识别了。

• 必须加诊断参数启动：-XX:+UnlockDiagnosticVMOptions -XX:+PrintCompressedOopsMode
• 输出含 “Compressed Oops mode: Zero based” → 安全启用，无额外开销
• 输出含 “Non-zero based” → 启用但需每次地址计算加一个 base 偏移，有微小解码成本
• 完全没这行，或显示 “Compressed Oops is disabled” → 已退回到 8 字节原生指针

临界点前后内存占用的实际差异

差别远不止“每个引用多占 4 字节”。对象头、数组起始地址、静态字段、类元数据指针等全部膨胀，引发连锁放大效应。

• 典型 DTO 类（含 2 个对象引用 + 1 个集合）在 31g 堆下对象头约 16 字节，引用字段共占 12 字节，总实例大小约 32 字节
• 同代码在 33g 堆下，对象头涨到 24 字节，所有引用翻倍，总大小跃升至 48–56 字节
• 亿级缓存场景下，单对象多占 16+ 字节 → 整体堆多压 1.6–2.2 GB，Young GC 频次上升 15% 左右

影响启用的隐藏因素

即使堆 ≤ 31g，也不保证一定启用。以下情况会导致 JVM 主动放弃压缩：

• 宿主机开启 vm.mmap_min_addr（如某些安全加固系统设为 65536），挤压低地址可用空间
• 旧版 Docker（cgroup v1）默认占用 0x0000000000010000 起始的地址段
• Linux 内核加载模块或 ASLR 随机化使 JVM 无法分配到零基地址
• 同一进程内已加载大量共享库，抬高了堆基址起始位置