ZGC能将停顿压至10ms以内，但需正确配置、合理堆结构及达标运行环境；其最大停顿与堆大小无关，仅取决于GC Roots数量和系统调度延迟。
ZGC到底能不能把停顿压到10ms以内
能，但前提是配置正确、堆结构合理、运行环境达标。ZGC的最大停顿时间与堆大小无关不是宣传话术，而是设计硬约束——它只取决于GC Roots数量和系统调度延迟。实测中，在256GB堆、活跃对象40GB的金融网关服务上，ZGC的STW峰值稳定在1.3ms；但若用错JDK版本或忽略NUMA拓扑，反而可能比G1更抖。
- JDK 15+ 才是生产可用起点（JDK 11–14为
-XX:+UnlockExperimentalVMOptions -XX:+UseZGC实验模式，不建议上线） - 必须运行在64位Linux（内核≥4.1），Windows/macOS支持滞后且默认禁用大页，延迟不可控
- 停顿敏感场景下，
-XX:+UseZGC要搭配-XX:+ZUncommitDelay=300（避免内存过早释放引发重分配抖动）
为什么ZGC不用分代却不怕小对象爆炸
它根本不管“年轻代”这回事，而是靠Region粒度+对象尺寸分级硬扛。ZGC把堆切成三类Region：Small（2MB）、Medium（32MB）、Large（≥4MB，单对象独占），小对象全扔进Small Region，回收时直接整页丢弃——没有Minor GC概念，但效果类似。
- 小对象（Small Region，分配快、回收快，无标记开销
- 大对象（≥4MB）进
Large Region，不参与转移（复制代价太高），靠并发整理+指针染色规避访问失效 - 别强行用
-XX:NewRatio或-XX:SurvivorRatio——ZGC会忽略这些参数，设了白设
读屏障和染色指针不是炫技，是并发安全的底线
ZGC能在应用线程跑着的时候移动对象，靠的不是魔法，是每次load操作前插入的读屏障（Load Barrier），以及把标记状态塞进64位指针高4位的染色指针（Colored Pointer）。这意味着：所有对象访问都要过一道检查，有开销，但可控。
- 开启ZGC后，JIT编译器会自动插入屏障代码，无需改业务逻辑
- 但若大量使用
Unsafe.getXXX或JNI直接读内存，会绕过屏障——对象可能被移走而指针未更新，导致Segmentation fault或静默数据错乱 -
-XX:+ZVerifyReads可开启读屏障校验（仅调试用，性能损30%+）
线上切ZGC最容易翻车的三个地方
不是调参问题，而是环境认知偏差。很多团队在压测时一切正常，上线后突发毛刺，根源往往藏在底层设施里。
立即学习“Java免费学习笔记（深入）”；
- 容器内存限制没对齐：Kubernetes里设
limits.memory=32Gi，但ZGC实际需要额外约5%元数据空间，若cgroup硬限死，会触发OutOfMemoryError: Compressed class space - NUMA绑定失效：多路CPU服务器上，若Java进程没绑核绑内存（
numactl --cpunodebind=0 --membind=0），ZGC的NUMA感知会退化，跨节点访问延迟飙升 - Linux透明大页（THP）冲突：ZGC自己管理大页映射，若系统开启
always模式的THP，会导致mmap失败并回退到普通页，吞吐骤降20%+
ZGC真正的复杂点不在怎么开，而在怎么让它和你的硬件、OS、容器 runtime 真正咬合。少一个numactl，多一行/sys/kernel/mm/transparent_hugepage/enabled的配置，就可能让亚毫秒承诺落空。
