Go pprof 锁竞争数据怎么和 CPU profile 区分

Go 服务出现“接口变慢”时，直接打开 CPU profile 并不一定能找到原因。CPU profile 看的是程序正在消耗处理器的栈；mutex profile 看竞争锁让其他 goroutine 等了多久；block profile 则覆盖锁、通道、WaitGroup、Cond 等同步阻塞。三者可以同时采集，但含义完全不同。

判断口诀是：CPU 看“谁在跑”，mutex 看“谁持锁导致别人等”，block 看“谁在什么同步点被挡住”。如果 CPU 不高而请求变慢，优先把 mutex 和 block 放进同一个复现窗口比较。

先看采样对象：CPU、mutex、block 不是同一张表

CPU profile 是采样“当前正在执行的代码”，常见结论是某个函数消耗了较多 CPU。它无法直接回答“有多少 goroutine 在等待这把锁”。mutex profile 的样本值近似表示其他 goroutine 因竞争 mutex 累计等待的时间，而且记录位置偏向造成竞争的临界区结束处，例如 sync.Mutex.Unlock 附近。

block profile 的范围更宽，记录 goroutine 在同步原语上被阻塞的时间，既可能是 sync.Mutex.Lock，也可能是通道收发、WaitGroup 或 Cond。因而一个请求等待通道，不一定会在 mutex profile 中出现，却可能在 block profile 中很明显。

采集窗口要同时打开两个开关

复现锁竞争时，可以在程序启动阶段加入下面的诊断配置，并用空白导入注册 HTTP pprof。示例只负责暴露采集入口，不代表线上应永久使用最高采样频率。

package main

import (
    "log"
    "net/http"
    _ "net/http/pprof" // 注册 /debug/pprof/ 下的标准处理器
    "runtime"
)

func enableProfiles() {
    // 复现阶段记录每次 mutex 竞争；生产环境应按开销调大分母或关闭。
    runtime.SetMutexProfileFraction(1)
    // 以纳秒为单位设置 block 的平均采样间隔；1 便于短窗口复现。
    runtime.SetBlockProfileRate(1)
}

func main() {
    enableProfiles()
    go func() {
        // 只监听本机诊断端口，避免把调试入口直接暴露到公网。
        log.Println(http.ListenAndServe("127.0.0.1:6060", nil))
    }()
    // 这里启动业务服务；诊断窗口结束后应恢复采样设置。
    select {}
}

SetMutexProfileFraction(1) 表示每次竞争事件都参与采样；SetBlockProfileRate(1) 把阻塞采样间隔设为最小，适合短时复现但可能增加开销。若只是观察趋势，可用更低的采样频率，并确保比较前后的采集设置一致。

用相同窗口做三次对照

假设 pprof 服务运行在本机 6060 端口，先用相同的 seconds 窗口采集。mutex 和 block 的 HTTP 接口支持按时间返回增量数据；CPU profile 则在指定时长内采集执行样本。

# CPU：看采集窗口内真正消耗处理器的调用栈
go tool pprof -top 'http://127.0.0.1:6060/debug/pprof/profile?seconds=30'

# mutex：看竞争 mutex 造成的累计等待时间
go tool pprof -top 'http://127.0.0.1:6060/debug/pprof/mutex?seconds=30'

# block：看所有同步阻塞点的累计阻塞时间
go tool pprof -top 'http://127.0.0.1:6060/debug/pprof/block?seconds=30'

这里的关键不是三份报告谁的数值更大，而是让它们覆盖同一类请求、同一段流量和相同的采集时长。CPU 热点高但 mutex、block 较低，通常先检查计算、序列化或循环；CPU 不高而 mutex 高，优先回到持锁范围；block 高但 mutex 低，则要检查通道、WaitGroup、Cond 或其他同步等待。

看到栈顶后怎么定位

mutex 报告里出现的 Unlock 相关栈，不代表 Unlock 本身耗 CPU，也不代表应该把解锁语句删掉；它提示这段临界区持有时间或竞争密度值得检查。沿栈向上找共享状态、批量 I/O、慢编码和不必要的锁内工作，通常比只盯着函数名更有效。

block 报告则先看阻塞原语：如果是 chan receive，检查生产者是否没有及时发送；如果是 WaitGroup，检查计数是否存在遗漏；如果是 Mutex.Lock，再与 mutex profile 对照，看它是不是同一把竞争锁。两份报告都高时，mutex 给出锁竞争的聚焦视角，block 帮你确认等待发生在整个同步链路的哪一层。

诊断结束后不要忘记把采样设置恢复为关闭状态，例如调用 runtime.SetMutexProfileFraction(0) 和 runtime.SetBlockProfileRate(0)。调试端口也应限制监听地址，并按服务的访问控制策略保护。

相关问题：mutex 和 block profile 该先看哪个

如果症状已经明确是“锁竞争导致请求排队”，先看 mutex；如果只知道 goroutine 在等待、但不确定是锁还是通道，先看 block。CPU profile 适合回答“处理器时间花在哪里”，不适合单独证明“请求慢是因为等待锁”。

最终判断应回到同一采集窗口：CPU 高说明有人在运行，mutex 高说明竞争锁的等待成本突出，block 高说明同步等待范围更广。把三者的采样开关、时间窗口和栈位置记录在一起，才不会用错误的 profile 解释性能问题。