ZGC并发重定位阶段需启用专用日志参数（如gc+reloc=debug）并结合perf、vmstat等系统工具交叉验证，以精准分析CPU占用、内存带宽压力和重定位抖动性三类物理开销。
ZGC 的“并发重定位”（Concurrent Relocation）是其低延迟特性的核心阶段，不涉及 STW，但会持续占用 CPU 和内存带宽。要深度复盘该阶段的物理开销，关键不是靠通用 GC 日志参数，而是精准启用 ZGC 专属日志标记 + 结合系统级观测工具交叉验证。
必须开启的 ZGC 日志参数组合
仅用 -Xlog:gc* 不够，需显式指定 ZGC 子系统和详细级别：
-
-Xlog:gc+phases=debug,gc+reloc=debug,gc+heap=trace - 补充时间与上下文：
time,uptime,pid,tags,level - 输出到轮转文件：
-Xlog:gc*:file=zc.log:uptime,time,pid,tags,level:filecount=5,filesize=50M
这样可捕获：
-
Relocation Start/Relocation End时间戳（毫秒级） - 每次重定位的页数（
relocating <n> pages）、总字节数（relocating <x> bytes） - 是否触发了
Relocation Stall（因内存分配竞争导致暂停） -
Relocation Worker线程数及各线程处理页数（反映并行度是否饱和）
从日志中提取物理开销的三类硬指标
-
CPU 占用强度：看
Relocation Worker日志中单次任务耗时（如worker 3: relocating 128 pages in 4.2ms）。若多 worker 持续 >3ms/批，说明 CPU 密集或缓存未预热。 -
内存带宽压力：计算单位时间重定位字节数。例如 1 秒内日志显示
relocating 256MB，即需约 256 MB/s 带宽——接近 DDR4 单通道理论峰值的 30%，需检查是否与其他业务争抢内存控制器。 -
重定位抖动性：统计连续 10 次
Relocation Start → End的间隔标准差。若 >15ms，说明后台重定位节奏受应用分配波动干扰严重（常见于突发大对象分配场景）。
必须同步采集的系统级佐证数据
ZGC 并发阶段不 STW，但会真实消耗资源，单看日志易误判：
-
perf record -e cycles,instructions,mem-loads,mem-stores -p <pid>抓取 30 秒，用perf report查看ZRelocate相关函数的 CPI 和内存访存占比 -
vmstat 1观察si/so（swap in/out）是否突增——重定位大量移动对象可能触发页表更新风暴，间接增加 TLB miss -
cat /proc/<pid>/status | grep -E "VmRSS|VmData"对比重定位高峰期前后 RSS 变化，确认是否因重定位暂存结构（如 forwarding table）导致 RSS 异常上涨
复盘时重点交叉验证的异常模式
- 日志显示
Relocation频繁但ZGC Cycles周期拉长 → 实际是 CPU 被抢占，需查top -H -p <pid>看ZRelocate线程的%CPU是否被业务线程压制 -
relocating <n> pages数值稳定，但单次耗时逐轮上升 → 内存碎片化加剧（ZGC 依赖大块连续虚拟地址），检查mmap区域是否被 JNI 或堆外缓存碎片化 - 出现
Relocation Stall且伴随dmesg | grep -i "thp"提示 THP 折叠失败 → 容器环境未关闭透明大页（echo never > /sys/kernel/mm/transparent_hugepage/enabled）导致重定位页对齐失败
不复杂但容易忽略
