zgc染色指针将gc状态编码于64位指针高位空闲位，结合并发标记、并发转移与读屏障，实现亚毫秒级stw停顿；其强制依赖64位平台与虚拟地址多重映射，使停顿时间仅与roots数量相关，与堆大小无关。
ZGC 的染色指针不是给对象“上色”，而是把 GC 状态信息直接编码进 64 位指针的高位空闲位中，让每次对象访问都能在不锁线程、不读对象头的前提下，即时获知该指针当前所处的 GC 阶段（如是否已标记、是否已重定位）。这正是它实现亚毫秒级 STW 停顿的核心前提。
为什么必须用 64 位指针高位？
现代 x86_64 Linux 系统实际只使用低 42–48 位虚拟地址（对应 4TB–256TB 地址空间），高 16 位长期为 0。ZGC 拿其中连续 4 位（如第 42–45 位）作为元数据位，定义 Marked0、Marked1、Remapped、Finalizable 四种状态。这些位与地址本体共存于同一寄存器，解码只需位运算：
- 提取真实地址：用 ptr & ~0xF（屏蔽低 4 位），不能用 ptr >> 4 —— 后者可能引入非对齐访问或分支预测失败
- 判断是否 Remapped：检查 (ptr & Z_METADATA_MASK) == ZRemapped，JIT 编译后是一条 test + jz 指令，开销极小
- 该设计强制要求 64 位平台和操作系统支持虚拟地址多重映射（如 Linux mmap(MAP_FIXED)），32 位 JVM 或未启用大页的环境无法运行 ZGC
Metadata 如何嵌入并保持无锁？
染色位由 JVM 运行时通过原子汇编指令（如 mov + and + or）直接操作，全程不涉及内存屏障、不修改对象头、不依赖 CAS 循环。关键在于：
- 所有状态变更都发生在指针复制/加载路径上，比如 GC 线程将一个指针从 Marked0 改为 Remapped，本质是生成一个新值写入引用字段，而非更新原对象
- 应用线程读取指针时，看到的是某个确定快照；即使 GC 同时在改其他副本，也不会造成 ABA 问题——因为指针值本身是不可变语义的“标签+地址”组合
- 没有共享的全局标记位或 bitmap，也就没有跨核缓存同步压力，天然规避了传统 GC 中常见的 false sharing 和锁竞争
读屏障如何靠染色位实现“无锁拦截”？
读屏障不是函数调用，也不是代理层，而是 JIT 在每个 aload、getfield、aastore 等字节码生成的内联汇编片段。它只做一件事：检查加载出的指针是否带 Marked 或 Remapped 位，然后按需处理：
- 若指针含 Marked0/Marked1：触发并发标记逻辑（如将该对象加入本地标记栈），不阻塞线程
- 若指针含 Remapped：查转发表（Forwarding Table）拿到新地址，用原子写回指令（如 xchg）更新引用字段，并清除 Remapped 位，后续访问直接命中新地址
- 整个过程不申请锁、不进入 safepoint、不挂起线程；最差情况只是多一次 cache miss 和几条 CPU 指令延迟
- 注意：Unsafe.getLong(obj, offset)、JNI 中直接解引用 jobject 地址等绕过 Java 引用语义的操作，会跳过读屏障，必须禁用或重写
为什么能彻底摆脱对象头依赖？
传统 GC（如 G1、CMS）需读写对象头的 mark word 来记录标记状态，这就带来两个硬伤：一是每次标记都要访问对象内存，引发大量 cache miss；二是必须 STW 才能安全遍历，否则应用线程可能正在修改 mark word。
ZGC 把这个状态“上移”到指针本身：
- 初始标记阶段只需扫描 Roots（栈帧、寄存器、静态字段），停顿时间只与 Roots 数量相关，与堆大小完全无关
- 并发标记期间，应用线程访问任意对象，只要其引用指针被染色，读屏障就自动补标，无需暂停
- 对象转移后，旧地址仍可安全访问——读屏障透明完成重定向与引用更新，即所谓“自愈”
