zgc并发线程数需权衡：过少拖慢标记，过多引发cpu争抢与上下文切换；建议从cpu核心数一半起步，结合vmstat的cs值调优，并注意与虚拟线程共享平台线程资源带来的隐性冲突。
ZGC在并发标记和转移阶段尽量避免“Stop-The-World”，但它仍依赖多线程协作，这些线程的调度会引入上下文切换开销——尤其当并发线程数配置不当或与业务线程争抢CPU时，切换频次上升，反而抵消低延迟优势。
ZGC并发线程数不是越多越好
ZGC默认使用固定数量的并发标记/转移线程（通常为`min(32, CPU核心数)`），这个值可调但需谨慎：
- 设得过低：标记进度慢，可能拖长GC周期，增加内存压力；
- 设得过高（如设为CPU核心数的2倍）：多个ZGC工作线程频繁争抢CPU，与应用线程混跑，触发大量非自愿切换；
- 实测建议：从`Runtime.getRuntime().availableProcessors() / 2`起步，在高负载场景下观察vmstat 1中的cs列是否持续高于15000；若偏高，应下调ZGC线程数（通过`-XX:ZCollectionInterval`或`-XX:ZWorkers`微调）。
与虚拟线程共存时的隐性冲突
Project Loom的虚拟线程虽不直接触发OS级上下文切换，但ZGC的并发阶段仍运行在平台线程（即OS线程）上。当大量虚拟线程阻塞于I/O或锁时，JVM后台仍需调度ZGC工作线程：
- 若平台线程池被业务占满（如`ForkJoinPool.commonPool()`饱和），ZGC线程可能排队等待CPU，导致标记延迟；
- 此时即使虚拟线程数量达百万，ZGC本身仍受限于可用OS线程数——本质是两类线程共享同一组CPU资源；
- 缓解方式：为ZGC预留专用平台线程（如用`-XX:+UseZGC -XX:ZWorkers=4`锁定关键线程数），并确保业务侧虚拟线程不长期阻塞在synchronized或传统BIO上。
上下文切换如何放大ZGC的缓存压力
ZGC强调低延迟，而低延迟依赖CPU缓存局部性。频繁的上下文切换会加剧缓存失效：
- ZGC并发标记线程扫描对象图时，访问内存模式具有空间局部性；一旦被切换出去，L1/L2缓存中预热的数据大概率被新线程冲刷；
- 恢复执行后需重新加载相同对象引用，引发更多内存延迟（尤其是大堆跨NUMA节点时）；
- 验证方法：用perf record -e cache-misses,instructions对比ZGC标记阶段的cache miss ratio，若切换密集时该比值升高20%以上，说明缓存友好性已被破坏。
ZGC的并发设计本意是把停顿拆解为可容忍的小片段，但线程调度失控会让这些片段叠加成隐性延迟。控制好ZGC线程规模、隔离其CPU资源、避开缓存敏感路径的干扰，才能真正兑现毫秒级GC承诺。
