17370845950

最稳妥启用pprof的方法是监听127.0.0.1:6060并禁止外网访问；CPU定位需用?seconds=5短采样，内存需区分--inuse_space与--alloc_objects，阻塞问题优先分析/debug/pprof/block和/trace。

怎么快速启用 pprof 并暴露到线上？

线上服务必须能随时采集 profile 数据，但不能影响主业务端口或引入安全风险。最稳妥的做法是：开一个独立监听地址（比如 :6060），只绑定 127.0.0.1 或内网 IP，并确保防火墙/ingress 不对外暴露。

代码里只需两行：

import _ "net/http/pprof"
go http.ListenAndServe("127.0.0.1:6060", nil)

注意：_ "net/http/pprof" 是副作用导入，会自动注册所有 /debug/pprof/xxx 路由到 http.DefaultServeMux；如果项目用了自定义 http.ServeMux（比如 gin/echo），就得手动注册 handler，否则访问 /debug/pprof/ 会 404。

• 别在生产环境用 ":6060"（即监听所有地址），否则可能被恶意抓取 profile 数据
• 若服务已用 gin.Engine 或 echo.Echo，需显式挂载：router.Any("/debug/pprof/*pprof", gin.WrapH(http.DefaultServeMux))
• 某些框架（如 go-zero）支持配置项一键开启，例如 Profile.Enable: true，不用手写代码

CPU 高了怎么定位热点函数？

不是一上来就跑 go tool pprof http://localhost:6060/debug/pprof/profile —— 默认 30 秒太长，线上不敢等；而且没加 ?seconds=5 容易卡住接口或被超时中断。

正确做法是先用短采样快速试探：

go tool pprof http://127.0.0.1:6060/debug/pprof/profile?seconds=5

进交互界面后立刻执行 top，看前几行的 flat%。如果发现 encoding/json.(*decodeState).object 占 40%+，基本就是 JSON 反序列化太重；如果是 runtime.mallocgc 高，说明分配频繁，得查内存而非 CPU。

• list 能看到具体哪一行耗时多，但前提是编译时没加 -ldflags="-s -w"（否则丢符号，显示为 (unknown)）
• 用 web 或 svg 生成火焰图需要本地装 Graphviz；没装的话，top -cum 看累积调用链更实际
• 避免在压测中途采样——此时 profile 会混入大量调度器噪声；应在 QPS 稳定、CPU 持续高于 70% 时采

内存涨了到底是泄漏还是临时分配爆炸？

直接访问 /debug/pprof/heap 看的是「当前堆上存活对象」，但很多问题出在「分配太快触发 GC 频繁」，而不是内存不释放。所以得区分两个指标：

• --inuse_space：看常驻内存（比如缓存没清、map 一直 grow）
• --alloc_objects 或 --alloc_space：看 30 秒内新分配了多少对象（比如循环里反复 json.Marshal）

命令示例：

go tool pprof --inuse_space http://127.0.0.1:6060/debug/pprof/heap
go tool pprof --alloc_objects http://127.0.0.1:6060/debug/pprof/heap?gc=1

?gc=1 强制在采样前触发一次 GC，让 --inuse_space 更干净；而 --alloc_* 不受 GC 影响，它统计的是分配事件本身。

常见陷阱：runtime.MemStats 里的 HeapAlloc 上升 ≠ 泄漏，得结合 HeapObjects 和 NumGC 一起看——如果对象数稳定但 HeapAlloc 持续涨，才是真泄漏。

goroutine 阻塞、channel 卡死、锁竞争怎么揪？

别只看 /debug/pprof/goroutine?debug=2 的文本快照——它只告诉你此刻有多少 goroutine，看不出谁在等谁。真正有用的是三个专项分析：

• /debug/pprof/block：专抓阻塞点，比如 chan receive、semacquire（mutex）、select 卡住。采样后用 top 看最深的阻塞调用栈
• /debug/pprof/mutex：当 contention=1（默认关闭）才收集锁竞争。启动前要加：runtime.SetMutexProfileFraction(1)，否则返回空
• /debug/pprof/trace?seconds=10：对 goroutine 生命周期做时序分析。用 go tool trace 打开后点「Goroutine Analysis」，能直接看到哪些 goroutine Inactive, no stack trace sampled —— 这就是卡在 channel 发送、锁等待、或 time.Sleep 里没醒过来

特别注意：/debug/pprof/goroutine?debug=1 返回的是 goroutine 数量摘要，?debug=2 才返回全部堆栈；线上慎用 debug=2，大量 goroutine 时响应极慢甚至 OOM。

pprof 不是万能探针——它靠采样，低频问题（比如每小时卡一次的 mutex 死锁）可能漏掉；真正难搞的阻塞，得配合 trace + 日志打点 + gdb attach 三路并进。但只

要记住：CPU 看 profile，内存看 heap 的两个 flag，阻塞看 block 和 trace，90% 的线上性能抖动都能当场定位。