ZGC实现毫秒级停顿，核心是并发执行+染色指针+读屏障协同：染色指针将标记状态编码入指针高位，避免额外内存访问；读屏障在引用加载时自动更新重定位中的对象引用；仅初始标记和最终重映射需极短STW。
ZGC 实现毫秒级（甚至亚毫秒级）停顿，核心不靠“少做事”，而是靠“并发做几乎所有事”+“染色指针”+“读屏障”三者协同，把原本必须 STW（Stop-The-World）的重活全部搬进应用线程运行时并发执行。
染色指针（Colored Pointers）：元数据藏进指针本身
ZGC 把对象标记状态（如是否已标记、是否在重定位中）直接编码进 64 位指针的高几位（Linux/x64 默认用 4 位），比如：
- 0001 表示该对象已标记（marked0）
- 0010 表示已标记（marked1），用于标记周期翻转
- 1000 表示正在重定位（remapped）
- 0100 表示是 bad 指针（仅调试用）
这样，ZGC 不需要单独维护 bitmap 或 mark word，标记、重定位、引用更新等操作都可直接通过指针值判断状态，避免访问额外内存结构带来的缓存抖动和同步开销。
读屏障（Load Barrier）：在每次对象引用加载时“悄悄干活”
ZGC 在每次 Java 代码读取对象引用（如 obj.field）时，插入一小段轻量级读屏障逻辑。它不是拦截所有读，而只在指针处于特定染色状态（如 remapped）时触发处理：
立即学习“Java免费学习笔记（深入）”；
- 若发现指针指向旧地址但对象已被重定位，就立即更新该引用为新地址（自愈式更新），并返回新对象
- 若指针未染色或已是新地址，则零开销直通
- 整个过程在用户线程内完成，无需全局暂停，也不依赖写屏障
这使得标记和重定位阶段完全并发——GC 线程在后台移动对象，应用线程通过读屏障自动“跟上节奏”，引用始终保持有效。
全并发工作流：STW 仅剩初始标记与最终重映射
ZGC 的 GC 周期中，真正需要 STW 的阶段极短：
- 初始标记（Initial Mark）：仅需扫描 GC Roots（线程栈、寄存器、全局 JNI 引用等），耗时通常
- 最终重映射（Final Relocation）：仅需修正极少数尚未被读屏障更新的“漏网”引用（如部分栈帧或 CPU 寄存器中的旧指针），也控制在毫秒内
中间所有步骤——并发标记、并发重定位、并发处理引用队列、并发清理——全部与 Java 应用线程并行执行。ZGC 甚至将堆划分为 page（默认 2MB），按需分片回收，进一步降低单次操作压力。
硬件与系统协同：大内存 + 免锁设计
ZGC 针对现代服务器优化：
- 依赖 64 位地址空间，支持 TB 级堆（如 16TB），避免因堆过大导致单次 GC 压力集中
- 所有并发阶段使用无锁数据结构（如并发链表、原子操作），消除线程竞争瓶颈
- 重定位采用“复制+原地更新”策略，不依赖内存碎片整理，避免传统 CMS/G1 的复杂空闲链表管理
因此，ZGC 停顿时间基本与堆大小无关，而主要取决于活跃对象数量和 CPU 资源争用程度——只要机器有足够核数，10GB 和 1TB 堆的停顿差异微乎其微。
