Go runtime/metrics 怎么定位 GC 压力：采样指标、时间窗口与误判排除

线上 Go 服务出现一阵一阵的延迟抖动时，先别把所有慢请求都归到 GC。更可靠的做法是用 runtime/metrics 在同一个时间窗口采样回收周期、暂停时间、堆目标和对象分配，再把这些变化和请求延迟对齐。

先确认：慢的是回收，还是业务本身

一次排查中，P99 从 40ms 升到 180ms，但 CPU、数据库耗时和网络错误都没有同步变化。这个现象值得看 GC，却还不足以证明 GC 是原因。把“发生过回收”和“回收已经压住请求”分开，是后面所有判断的前提。

下面的采样器只读运行时指标，不改变 GC 参数。它每隔一段时间取一组快照，随后计算计数器增量；直方图则保留区间分布。

package main

import (
    "fmt"
    "runtime/metrics"
    "time"
)

func main() {
    samples := []metrics.Sample{
        {Name: "/gc/cycles/total:gc-cycles"},
        {Name: "/gc/heap/goal:bytes"},
        {Name: "/gc/pauses/total:seconds"},
    }
    metrics.Read(samples)
    for _, sample := range samples {
        fmt.Printf("%s = %v\n", sample.Name, sample.Value)
    }
}

如果某个指标在当前 Go 版本不存在，Value.Kind() 会暴露这一点。生产代码不要假设所有版本都有同一组名称，启动时可以先用 metrics.All() 建立可用指标表。

三个指标要放在同一条时间线上

/gc/cycles/total:gc-cycles 是累计计数，适合看单位时间增加了多少次；/gc/heap/goal:bytes 是当前堆目标，适合观察内存增长后运行时如何调整节奏；/gc/pauses/total:seconds 是暂停时间直方图，重点不是累计秒数，而是每个桶里的事件数量变化。

采样周期不宜和请求指标的聚合周期差太多。若接口延迟按 30 秒聚合，就先用 10 秒或 15 秒采一组运行时数据，然后把每组三十秒窗口内的 GC 增量与 P99 对齐。不要拿今天的累计暂停时间去解释刚刚五分钟的抖动。

用增量和分布排除第一种误判

累计指标只会增长，所以“数值很大”本身没有诊断意义。真正有用的是相邻快照的差值。例如两个十秒窗口分别增加 2 次和 3 次回收，暂停直方图也没有长尾变化，这更像正常工作负载，而不是 GC 压力突然失控。

可以把快照结构保留下来，再用差值输出一条紧凑记录。计数器和 gauge 的处理方式不同，直方图则应保留桶边界与计数，避免把分布压成一个平均值。

type Window struct {
    At       time.Time
    Cycles   uint64
    HeapGoal uint64
}

// 对两个窗口：Cycles 使用 after.Cycles - before.Cycles；
// HeapGoal 直接比较 after.HeapGoal 与 before.HeapGoal。
// 若要判断暂停尾部，读取 /gc/pauses/total:seconds 的直方图桶变化。

实践中最容易漏掉的是采样失败和单位。秒、字节、次数不能混在同一张图里；转换单位时把原始值和单位一起写入指标名，后面才不会出现“180”到底是 180ms 还是 180 秒的争论。

第二个窗口仍然异常，才进入 GC 压力判断

如果延迟抖动持续两个以上窗口，同时回收次数增量升高、暂停直方图右侧桶明显增加，且堆目标被频繁推高，才可以把 GC 作为主要嫌疑。此时再去看分配速率、临时对象、批量反序列化和缓存刷新，而不是先调大 GOGC。

分配高，不等于暂停一定长

短命对象很多，可能让回收更频繁，但如果每次暂停都很短，用户未必感知明显。相反，低频的大批量分配可能制造更长的尾部。把“频率”和“暂停分布”分开看，结论会比单看 GC 次数准确。

堆目标变大，也不等于故障

堆目标随活跃堆和 GOGC 计算变化。服务刚完成一次缓存预热时，目标上涨可能只是工作集变大。只有当它和持续延迟、回收长尾、内存水位一起恶化，才值得做配置或代码修复。

修复顺序：先减少分配，再调整节奏

确认 GC 压力后，先用 profile 或业务计数定位分配来源：重复的 JSON 中间对象、大 slice 扩容、每请求创建的大型临时缓冲区，通常比全局调参更值得先处理。修复后仍用同样的采样窗口复查，确保回收增量、暂停分布和接口 P99 一起改善。

只有在知道内存余量、延迟目标和吞吐变化后，才考虑调整 GOGC 或使用运行时调节接口。参数变化必须有回滚条件，不能用“GC 次数少了”作为唯一成功标准。

常见问题：runtime/metrics 采样怎么不误导自己

只读一次快照能判断 GC 压力吗？

不能。一次快照只能说明当前累计状态，至少需要两个带时间戳的快照，计数器看增量，直方图看桶变化。

GC 次数增加就一定是性能回归吗？

不一定。要同时看暂停时间分布、请求延迟和内存水位；短暂停顿增加可能只是吞吐上升。

应该先调大 GOGC 吗？

通常不应先调。先确认分配来源和业务内存余量，再用相同窗口做参数实验，并准备回滚。

把判断留在可复查的时间窗口里

runtime/metrics 的价值不在于提供一个“GC 正常/异常”开关，而在于让排查拥有可比较的证据：回收频率、堆目标、暂停分布和请求延迟是否在同一时间线上共同变化。保留原始快照、单位和采样间隔，下一次抖动时就能复用这套判断。