安全点停顿耗时≈初始标记开销，因其核心是线程进入安全点并扫描根对象，不遍历对象图；真实开销取决于线程响应延迟（sync time）、jvm清理耗时（cleanup time）及应用运行时间，需通过-xx:+printsafepointstats等参数采集验证。
直接看安全点停顿耗时，就能反映可达性分析第一阶段（即根节点枚举）的真实物理开销。ZGC在标记开始前必须执行一次极短的初始标记（Initial Mark），这个阶段虽属STW，但核心动作就是让所有应用线程进入安全点，然后快速扫描根对象（如栈帧本地变量、静态字段、JNI引用等）。它不涉及对象图遍历，纯属“找起点”，所以耗时几乎全部落在安全点进入与清理上。
为什么安全点耗时 ≈ 初始标记开销
初始标记本身逻辑轻量，真正拖慢它的，是线程抵达安全点的过程：
- 线程正在执行长循环、大段 JNI 调用或处于阻塞态（如 sleep、wait），无法及时响应 safepoint 请求
- OopMap 更新未就绪，或某些 native 代码未设置 safepoint poll
- 大量线程竞争进入同一轮 safepoint，导致排队等待
关键监控指标必须采集
仅靠 GC 日志中的 “Pause Initial Mark” 时间不可靠，它只记录 JVM 主动发起标记到结束的时间窗，掩盖了线程挂起延迟。你需要的是底层 safepoint 统计：
- Safepoint sync time：从触发 safepoint 到最后一个线程挂起的耗时（反映线程响应延迟）
- Safepoint cleanup time：所有线程挂起后，JVM 执行清理动作（如更新 OopMap、处理 pending 状态）的耗时
- Application time (non-safepoint)：两次 safepoint 之间应用实际运行时间，用于反推停顿占比
如何配置并验证
必须启用以下 JVM 参数，否则日志里看不到这些细节：
- -XX:+PrintSafepointStats：输出每次 safepoint 的分项耗时
- -XX:PrintSafepointStatisticsCount=1：确保每轮都打印，不聚合
- -XX:+UnlockExperimentalVMOptions -XX:+UseZGC：启用 ZGC 基础能力
- -Xlog:safepoint*:stdout:time,uptime,level,tags（JDK 10+）：更细粒度日志格式
典型问题定位路径
当发现接口 P99 RT 突增，但 GC 日志显示 Initial Mark 仅 0.2ms，别急着排除 GC：
- 查 safepoint log，若 sync time 持续 >5ms，说明线程卡在 JNI 或长循环中
- 若 cleanup time 高，关注是否频繁类加载、反射调用或大量 finalizer 对象待处理
- 对比 safepoint 触发频率与业务请求节奏——若每次大促流量高峰都同步触发 safepoint，说明根枚举成了性能瓶颈放大器
