Go runtime/pprof读取阻塞 Profile 识别等待点的排查指南

我排查 Go 服务“CPU 不高但请求一直等”的问题时，先看的是 block Profile，而不是急着把 CPU Profile 当成答案。阻塞 Profile 记录 goroutine 在互斥锁、读写锁、WaitGroup、条件变量和 channel 操作上累计等待的时间；它指出的是等待发生的位置，不等于已经证明某一把锁就是根因。

先打开 block Profile，再决定采样窗口

Go 官方把 block Profile 定义为同步原语上的阻塞时间统计，采样对象包括 sync.Mutex、sync.RWMutex、sync.WaitGroup、sync.Cond 以及 channel 的发送、接收和 select。它默认关闭，所以只挂上 net/http/pprof 路径并不能自动得到有用的阻塞数据。

SetBlockProfileRate 的参数单位是纳秒级的目标采样间隔。传入 1 会尽量记录每次阻塞，适合短时间复现；线上长时间打开会增加额外开销。我更常用一个有限窗口，复现完成后恢复为 0，避免把排查开关变成常驻成本。

用 Lookup 和 WriteTo 保存可分析快照

如果不想依赖 HTTP 端点，可以在服务内部按需导出快照。下面的写法把文件创建、Profile 不存在和写入错误分开处理；debug=0 输出 pprof 使用的压缩协议数据，适合后续用 go tool pprof 打开。

package main

import (
    "fmt"
    "log"
    "os"
    "runtime"
    "runtime/pprof"
)

func saveBlockProfile(path string) error {
    // 1 表示尽量记录每次阻塞；短时排查后应恢复为 0。
    runtime.SetBlockProfileRate(1)
    defer runtime.SetBlockProfileRate(0)

    profile := pprof.Lookup("block")
    if profile == nil {
        return fmt.Errorf("block profile is unavailable")
    }

    file, err := os.Create(path)
    if err != nil {
        return fmt.Errorf("create profile: %w", err)
    }
    defer func() {
        // 关闭失败不能覆盖前面的采集错误，但要留下日志。
        if closeErr := file.Close(); closeErr != nil {
            log.Printf("close profile: %v", closeErr)
        }
    }()

    // debug=0 保留 pprof 可读取的快照格式。
    if err := profile.WriteTo(file, 0); err != nil {
        return fmt.Errorf("write block profile: %w", err)
    }
    return nil
}

如果使用 HTTP 方式，则可在已注册 net/http/pprof 的服务上读取 /debug/pprof/block，也可以给 block Profile 使用 seconds=N 获取一段时间的增量。无论哪种方式，都要把采样开关、复现窗口和快照文件对应起来，避免拿不同时间段的结果互相比较。

用 top、list 和调用图确认等待点

快照拿到后，不要直接凭第一行函数名改锁。先用 top 看哪些栈的累计等待时间最高，再用 list FunctionName 回到函数源码附近，最后用调用图检查是谁把大量 goroutine 带到了这个等待位置。

# 先按累计阻塞时间查看排名，避免只看调用次数。
go tool pprof ./service block.prof

# 在 pprof 交互界面中执行这些命令。
(pprof) top10
(pprof) list handleRequest
(pprof) web

这里的“等待点”通常是 Mutex.Lock、channel 接收或发送、WaitGroup.Wait 等真正发生阻塞的位置。根因可能在更早的调用路径：例如持锁范围过大、生产者没有及时发送、计数没有对应的 Done，或者采集窗口刚好落在一次初始化尖峰。block Profile 的累计值应该和请求日志、队列长度或 goroutine 数量交叉判断。

采样结果的参数与边界

分析结束后，先保存原始 Profile，再关闭额外采样；如果仍然无法解释，下一轮应缩小复现窗口并增加业务维度，而不是简单把采样率继续调高。官方诊断文档也提醒，阻塞 Profile 与其他诊断工具可能互相影响，排查时最好一次只关注一个主要问题。

相关问题

block Profile 和 mutex Profile 是一回事吗？

不是。block Profile 关注 goroutine 在同步原语上等待了多久；mutex Profile 关注互斥锁竞争以及持锁方造成的竞争时间，定位角度不同。

为什么读取到的 block Profile 很空？

最常见原因是没有调用 runtime.SetBlockProfileRate，或者采集窗口内没有发生被记录的阻塞。先确认采样开关和复现时段，再判断业务是否真的存在等待。

应该用 debug=0 还是 debug=1？

交给 go tool pprof 时优先用 debug=0；需要直接阅读旧式文本时才考虑 debug=1，两者用途不同。