Go runtime.SetBlockProfileRate 怎样调整阻塞采样率

先说结论：runtime.SetBlockProfileRate 的参数不是“每隔几次采样”，而是阻塞时间预算，单位是纳秒。rate=1 目标是把每次 goroutine 阻塞事件都纳入阻塞 profile；rate 关闭阻塞剖析；较大的正数则降低采样密度。服务出现“CPU 不高但请求在等待”时，先看 block profile，再决定 rate，而不是直接把问题当成 CPU 热点。

官方文档：https://pkg.go.dev/runtime#SetBlockProfileRate

这次排查最容易走偏的地方，是把“开启采样”和“导出 profile”当成一件事。前者由 runtime 控制，后者通常交给 runtime/pprof 或标准 HTTP pprof 入口。

服务变慢但 CPU 不高，先看是不是在等待

如果请求耗时上升、CPU 使用率却没有同步升高，常见线索不是算力不足，而是 goroutine 在 channel、锁、网络读写或其他同步点等待。CPU profile 适合回答“时间花在了哪些正在运行的函数上”，block profile 则更适合回答“goroutine 因为什么等待而停住”。

因此排查顺序应先确定问题类型：如果热点集中在计算函数，继续看 CPU profile；如果大量时间消耗在等待，才需要打开阻塞采样。这样既能减少无关数据，也不会用错误的 profile 解释现象。

SetBlockProfileRate 的 rate 到底表示什么

官方定义是：采样器希望平均每经过 rate 纳秒的阻塞时间，记录一个阻塞事件。它不是固定的事件计数，也不是“每 N 个 goroutine 取一个”。阻塞时间越长，越容易达到采样预算；rate 越大，记录越稀疏。

这里的“目标”很重要：采样 profile 是观察工具，不应把 rate=1 当成线上永久配置。排查窗口越长、并发越高，越应该重新评估采样密度。

打开采样后，怎样把 block profile 交给 pprof

SetBlockProfileRate 只负责改变运行时的采样设置。读取 profile 时可以通过 pprof.Lookup("block") 找到名为 block 的 profile，再写入文件或接入已有的分析链路。

package main

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

func writeBlockProfile(path string) error {
    // 1 表示尽量记录每次阻塞事件，适合短时定位问题。
    runtime.SetBlockProfileRate(1)

    file, err := os.Create(path)
    if err != nil {
        return err
    }
    defer file.Close() // 文件句柄必须在导出结束后释放。

    profile := pprof.Lookup("block")
    if profile == nil {
        return os.ErrNotExist
    }
    // debug=0 保留 pprof 可继续分析的 profile 数据格式。
    return profile.WriteTo(file, 0)
}

示例的重点是分工：runtime 设置采样，pprof 查找并写出 profile。生产系统还要为导出动作设计权限和生命周期，不能因为 profile 名称固定就把调试入口无条件暴露给公网。

排查结束后如何恢复，避免采样设置变成隐性常驻开销

一次性诊断可以在采样前后明确写出状态；如果服务支持动态诊断，则应把“开启、导出、关闭”放在同一个受控流程里。关闭时传入小于等于 0 的值即可。

func beginShortDiagnostic() func() {
    // 提高采样密度只覆盖明确的诊断窗口。
    runtime.SetBlockProfileRate(1)

    return func() {
        // 诊断完成后关闭阻塞剖析，避免长期增加采样成本。
        runtime.SetBlockProfileRate(0)
    }
}

如果选择较大的正数，不能把它理解成“采样越安全”。它只是降低记录密度，可能让短暂但关键的等待更难出现。反过来，rate=1 也不是越精确越好：在高并发服务中，先选择短窗口和明确的访问范围，再看数据是否足够。

另外不要把 block profile 和 mutex profile 混为一谈。前者关注 goroutine 阻塞事件，后者关注互斥锁竞争；两者回答的问题不同，采样开关也不同。

常见问题

rate 的单位是秒吗？不是，单位是纳秒。它描述的是阻塞时间采样预算，不是定时器间隔。

rate 设置成 0 会清空旧 profile 吗？它关闭后续阻塞剖析，不应把“停止采样”和“删除已经导出的文件”混为一谈；历史文件由你的导出和存储流程负责管理。

只看 CPU profile 能定位 channel 等待吗？通常不够。CPU profile 观察运行中的 CPU 样本，等待原因应优先通过 block profile 观察。

线上应该固定使用 rate=1 吗？不建议直接这样假设。应按诊断窗口、并发量和可接受开销选择，并在问题定位后恢复关闭或更低密度的设置。

总结：SetBlockProfileRate 的关键不是记住一个推荐数字，而是理解 rate 与阻塞纳秒的关系：先识别等待型问题，再按排查窗口选择密度，用 runtime/pprof 读取 block profile，完成诊断后恢复设置。