zgc通过四种机制主动触发回收：堆使用率达30%、定时检查、分配失败或显式system.gc()（需启用），全程几乎全并发执行，无长停顿。
ZGC 的触发和执行完全围绕“低延迟”设计，不依赖传统分代逻辑，也不靠堆空间是否“填满”来决定何时启动。它的触发机制是主动、多源、可配置的，整个执行过程几乎全部并发，应用线程基本不停顿。
ZGC 的四种触发机制
ZGC 不是被动等待内存耗尽才回收，而是由以下四类条件之一满足时主动发起收集：
-
基于堆内存使用率触发：默认当已用堆内存达到总堆的 30%（可通过
-XX:ZCollectionInterval调整阈值）时触发一次 GC。这是最常见、最基础的触发方式。 -
基于时间间隔触发：即使内存没涨到阈值，只要距离上次 GC 已过去指定秒数（如
-XX:ZCollectionInterval=5表示每 5 秒强制检查一次），ZGC 就会评估是否需要收集。 - 分配失败触发（Allocation Stall）：当线程尝试分配对象但找不到足够连续空闲 Region（尤其是 Large Region）时，ZGC 会立即启动一次 GC 来腾出空间。这种触发会导致短暂的线程阻塞（微秒级），但不会全局停顿。
-
显式 System.gc() 触发（仅限启用时）：默认情况下 ZGC 忽略
System.gc()；若启动参数中添加-XX:+ExplicitGCInvokesConcurrent，则该调用会转为一次并发 ZGC 周期。
ZGC 的执行阶段全并发
ZGC 没有传统意义上的“Stop-The-World”长停顿。它把整个 GC 流程拆成多个细粒度阶段，绝大多数都在应用线程运行的同时完成：
- 初始标记（Initial Mark）：极短暂停（通常
- 并发标记（Concurrent Mark）：与应用并发执行，遍历对象图并标记所有存活对象；借助读屏障（Read Barrier）捕获并发修改，保证快照一致性。
- 再标记（Remark）：一次非常短暂的 STW（通常
- 并发转移准备 & 转移（Relocation Set Selection + Concurrent Relocate）：选择待整理的 Region，然后将存活对象复制到新 Region；转移过程全程并发，靠染色指针 + 负载屏障实现旧地址透明重映射。
- 并发引用处理 & 清理：更新软/弱/虚引用，回收已确认死亡的 Region，全部异步完成。
关键执行特征说明
ZGC 的执行不是“一次做完”，而是一个持续流动的过程：
- 每次 GC 周期只处理一部分 Region（称为 Relocation Set），避免单次工作量过大；后续周期继续推进，形成滚动式整理。
- 没有新生代/老年代区分，所有 Region 统一参与标记与转移，天然避免跨代引用开销。
- Region 大小动态分三档（2MB / 32MB / ≥4MB），大对象直接独占 Large Region，不拆分、不复制，降低转移成本。
- 全程依赖染色指针（64 位指针中嵌入元数据位）和负载屏障，在对象被访问瞬间完成重映射或状态校验，无需额外同步。
ZGC 的设计目标就是让 GC 变成后台“隐形服务”——你几乎感知不到它的存在，但它始终在高效维持堆健康。
