Go 服务 CPU 高还是内存涨：按症状选择 pprof profile 并验证热点

Go 服务出现 CPU 飙高或内存持续上涨时，第一步不是把所有 profile 都抓一遍，而是先按症状选画像：CPU 使用率高看 CPU profile；怀疑堆内存或泄漏看 heap；大量 goroutine 卡住看 goroutine；同步原语等待时间高看 block；锁竞争明显看 mutex。选对 profile 后，再用 top、list 和一次对照采样确认热点，结论才有可复现性。

先记住三个判断：CPU profile 解释“正在消耗 CPU 的时间”，heap 关注“仍存活的对象和历史分配”；等待类 profile 解释并发阻塞，不等于 CPU 热点。block、mutex 默认不会自动记录全部信息，需要先打开相应采样。

先按症状选对 pprof profile

如果进程的 CPU 使用率与吞吐一起升高，优先采集 CPU profile；它回答的是哪些调用栈在主动消耗 CPU 周期，不会把睡眠或等待 I/O 当成 CPU 热点。内存曲线涨时先看 heap：它偏向最近一次 GC 后仍存活的对象，也可以切换到累计分配视角，不能只凭 RSS 直接断定是 Go 堆泄漏。

goroutine 适合回答“现在有哪些 goroutine、分别停在哪里”；block 记录同步原语上的累计阻塞时间；mutex 则专门看争用锁的等待代价。两者都不是默认完整开启的：可在程序初始化阶段设置 runtime.SetBlockProfileRate 和 runtime.SetMutexProfileFraction，再按相同负载采样。

启用 HTTP 入口并按症状采样

独立诊断端口可以这样接入。生产环境要把它放在受保护的管理网络，不要直接暴露到公网：

import (
    _ "net/http/pprof"
    "log"
    "net/http"
)

go func() {
    log.Println(http.ListenAndServe("127.0.0.1:6060", nil))
}()

CPU 采样通常给出一个明确的持续时间；下面的 30 秒只是示例，持续时间要覆盖一段具有代表性的请求：

go tool pprof -http=:0 \
  http://127.0.0.1:6060/debug/pprof/profile?seconds=30

内存可以抓 heap，想看一段时间内的变化再使用 seconds 参数。block、mutex 入口也通过同一组 HTTP handler 提供；如果没有先启用采样，文件可能无法回答你要问的问题。一次只抓一种主要画像，避免精确内存采样、阻塞采样等诊断手段互相干扰。

用 top、list 和对照采样验证热点

拿到 profile 后先看总量，再落到源码行：

go tool pprof cpu.prof
(pprof) top
(pprof) list HandleRequest

top 用来筛选占比靠前的函数，list 用来确认具体行；如果是 heap，要先明确是在看 inuse_space（当前存活字节）还是 alloc_space（进程启动以来累计分配字节）。同一个函数在累计分配榜靠前，不代表它现在仍然占着最多内存。

验证时保留三项证据：采样持续时间与负载、热点函数或源码行、同一请求在优化前后的指标。若 CPU 热点只在空载出现，先增加代表性请求；若 heap 榜只看到了短命对象，先区分累计分配与存活对象；若 block 或 mutex 结果为空，回头检查采样开关和采样期间是否真的发生了等待。

收束处理结论并控制诊断影响

pprof 给的是定位证据，不是自动优化方案。一次只修改一个瓶颈因素，例如先减少某个热点函数的重复编码，再用相同请求比例重新采集 CPU；不要同时改缓存、锁粒度和 GC 参数。CPU、heap、block、mutex 之间也不要互相代替：CPU 低而请求慢，可能是等待；heap 存活对象稳定但 RSS 上涨，可能要继续看非堆内存。

处理完成后记录 profile 文件名、采集窗口、版本、负载和结论，方便回滚与复盘。必要时关闭高成本诊断开关，并限制管理端口访问范围。

相关问题

CPU 不高但接口很慢，先看哪个 profile？

先看 goroutine，再根据堆栈是否集中在同步原语上选择 block 或 mutex；若是网络或系统调用等待，还要结合 trace 或系统侧工具判断。

heap profile 能直接证明内存泄漏吗？

不能。它展示采样到的分配信息，需在相同负载下做多次对照，并优先观察 GC 后仍存活对象是否持续增长。