ZGC的核心特性是几乎全程不暂停应用线程，通过并发标记、并发重分配和并发重映射实现GC工作与Java线程同时运行，仅需三次极短STW阶段。
ZGC 的并行与并发回收特性，核心在于“几乎全程不暂停应用线程”，这是它区别于 G1、CMS 甚至 Parallel 等传统收集器的关键。它不是靠减少停顿次数或缩短单次停顿时间来优化，而是把绝大多数 GC 工作（标记、整理、引用更新）都设计为与 Java 应用线程同时运行。
并发执行是 ZGC 的默认工作方式
ZGC 没有“Stop-The-World”主导阶段，所有重量级操作均并发进行：
- 并发标记：从 GC Roots 开始遍历对象图时，应用线程持续运行；依赖读屏障（Read Barrier）捕获指针访问，配合染色指针记录状态变化，无需暂停即可完成可达性分析。
- 并发重分配（Relocation）：存活对象复制到新内存区域的过程完全并发；ZGC 利用转发表（Forward Table）和指针“自愈”能力，让应用线程在访问旧地址时自动跳转并修正引用，全程无感知。
- 并发重映射（Remap）：虽需修正堆中所有指向旧地址的引用，但因读屏障已实现“访问即修正”，该阶段更多是收尾清理，压力极小且仍可并发。
并行仅用于内部任务调度，不等于 STW
ZGC 内部会启用多个 GC 线程协同工作，但这属于“并行”层面的优化，而非传统意义上的并行收集器（如 Parallel GC）：
- 多个 GC 线程共同扫描 region、处理转发表、执行内存复制——提升吞吐效率，但不导致应用线程暂停。
- 真正需要 STW 的阶段极少且极短：初始标记（STW1）、再标记（STW2）、初始转移（STW3），三者合计通常
- 这些短暂停顿只做元数据快照或全局一致性校验，不涉及对象遍历或移动，因此开销可控。
对比 G1 和 CMS 理解“并发”的深度差异
很多收集器标榜“并发”，但实际仍有较重 STW 阶段：
- G1 的初始标记、最终标记、筛选回收均为 STW；并发标记阶段虽并发，但需配合写屏障，且最终仍要停顿做精确标记修正。
- CMS 的初始标记、重新标记是 STW；并发清除虽并发，但无法整理内存，易产生碎片，间接引发 Full GC 停顿。
- ZGC 不仅标记和清除（整理）并发，还通过染色指针 + 多重映射 + 读屏障，把对象移动这一最易引发停顿的操作也彻底并发化。
硬件与运行时支持是并发落地的前提
ZGC 的并发能力不是纯软件调度的结果，依赖底层机制协同：
- 染色指针（Colored Pointer）：将元信息（标记状态、是否重分配）直接编码进 64 位指针低几位，避免额外内存结构开销，使每次对象访问都能快速判断状态。
- 内存多重映射（Multi-Mapping）：同一物理内存页映射为 Marked0 / Marked1 / Remapped 三个虚拟视图，通过切换页表实现原子状态迁移，支撑无锁并发访问。
- 读屏障（Read Barrier）：在每次对象引用读取时插入轻量检查逻辑，触发自愈、转发或状态更新，是并发安全的核心守门人。
