[!info] 关联笔记

• 所属 MOC：性能与诊断 · 学习路线
• 前置概念：benchmark、testing、性能方法论
• 并列概念：race detector、逃逸分析、可观测性
• 运行时背景：调度、GC、栈与堆

Go pprof

这个概念为什么会出现

性能问题很少写在语法表面上：

• CPU 被哪个调用栈吃掉？
• 堆上谁在分配、谁在残留？
• goroutine 为何上万？堵在哪一行？
• 锁/阻塞是否成为串行化瓶颈？

没有剖析时，优化往往变成“换算法试试”“加缓存试试”。Go 工具链内建 pprof：以采样或快照形式给出带栈的证据，把优化从玄学拉回工程。

[!abstract] 一句话理解 pprof 是 Go 的性能剖析数据格式与工具链：采集 CPU/内存/阻塞/互斥/goroutine 等 profile，用 go tool pprof 或 Web UI 看热点栈；它回答“时间与资源花在哪”，不自动给出业务正确改法。

最小可运行示例

先把示例放进业务场景，再看代码：

场景：后台 worker 吃满 CPU，用 pprof 找热点函数

订单导出 worker 上线后 CPU 飙高，怀疑某个循环。
临时在进程挂上 net/http/pprof（生产要鉴权 + 独立 admin 端口），对 CPU 采 5 秒，用 go tool pprof 看 top 是否指向 busy。

package main

import (
	"log"
	"net/http"
	_ "net/http/pprof" // 空白导入：在 DefaultServeMux 注册 /debug/pprof/*
	"time"
)

// busy：模拟 CPU 热点（真实项目可能是 JSON 编解码 / 压缩 / 正则）
func busy() {
	n := 0
	for i := 0; i < 1e8; i++ {
		n += i
	}
	_ = n
}

func main() {
	// 后台 worker 不断跑 CPU 活
	go func() {
		for {
			busy()
			time.Sleep(10 * time.Millisecond)
		}
	}()
	// 仅演示：生产需鉴权、独立 listener、勿裸奔公网
	log.Println(http.ListenAndServe("localhost:6060", nil))
}

建议运行：

# 终端 1
go run .
# 终端 2：采 5 秒 CPU profile
go tool pprof http://localhost:6060/debug/pprof/profile?seconds=5
# 交互里: top, list busy, web

期望：top 中 main.busy（或内联相关帧）占比靠前。

结合场景再看三个关注点

1. 空白 import net/http/pprof 注册默认端点。
2. CPU profile 是一段时间内的采样，不是精确逐行计费。
3. 生产必须鉴权 / 内网；先复现负载再采，避免采到测试噪声。

核心概念与准确模型

两类入口

入口	包	场景
HTTP 端点	net/http/pprof	长期运行服务在线采
API 写文件	runtime/pprof、runtime/trace	测试、CLI、受控窗口
测试集成	go test -cpuprofile -memprofile	与 benchmark 结合

常见 profile 类型

名称	路径/含义	回答的问题
profile	CPU	采样期内谁在跑
heap	堆	分配与残留（注意 inuse vs alloc）
goroutine	栈快照	谁在阻塞、数量为何膨胀
block	阻塞	channel/锁等阻塞事件（需采样率）
mutex	互斥	锁竞争（需采样率）
threadcreate / allocs 等	视版本与端点	更细维度

文档入口：Diagnostics — Profiling、pprof 博客。

CPU profile 模型

运行时按频率采样当前运行的 goroutine 栈（并处理信号处理等细节）。结果是统计意义上的热点，不是精确计时器对每一行的计费。短函数、内联、采样噪声都可能影响观感——应用 top/peek 看聚合，用对比两次 profile 验证改动。

堆 profile 模型

• alloc_space / alloc_objects：累计分配（找分配热点）
• inuse_space / inuse_objects：当前仍引用（找泄漏或滞留）

看泄漏优先 inuse；看“分配太猛导致 GC 压力”看 alloc。配合 GODEBUG/metrics 与 go-garbage-collection。

交互与可视化

go tool pprof -http=:8081 cpu.pb.gz
go tool pprof mem.pb.gz
# top20, list FuncName, web, peek regexp

火焰图（flame graph）把栈宽表示资源占比，适合快速定位。

与 trace 的分工

	pprof	runtime/trace
强项	函数级热点、堆、锁采样	调度、STW、syscall、精确时间线
成本	相对较低（仍有开销）	更重，适合短窗口
问题类型	“谁最热”	“为何这一段延迟毛刺”

详见 Diagnostics。

边界情况

1. 生产裸奔 pprof：未鉴权暴露 debug/pprof → 信息泄露与 DoS。
2. 在错误负载下采 CPU：热点是测试脚本，不是真实流量。
3. 把采样噪声当结论：一次 1s profile 就重写模块。
4. 只看 flat 不看 cum：真正罪魁在调用者循环。
5. 优化非瓶颈：火焰图 2% 的函数被“精细打磨”。
6. 容器里符号/权限：无法打开 perf 事件时 CPU profile 行为需核对其平台限制。

常见误区

[!warning] 常见误区：pprof 会自动让程序变快 错误：接入 pprof 即优化完成。
正确：它只提供证据；改代码后要回归 benchmark/SLO。

[!warning] 常见误区：heap 高就是“内存泄漏” 错误：把正常缓存或峰值当泄漏。
正确：对比 inuse 趋势、引用链、业务生命周期。

[!warning] 常见误区：忽略观测开销 错误：长期全开高采样 block/mutex。
正确：按需开启；记录采集窗口与条件。

[!warning] 常见误区：不建基线 错误：改完凭体感。
正确：同负载前后 profile + go-benchmarking + 延迟指标。

工程实践

1. 先方法论后工具：定义 SLI/SLO → 复现 → 剖析 → 改一处 → 验证（go-performance-methodology）。
2. 服务暴露：独立 admin 端口、鉴权、仅内网；或用 pprof.StartCPUProfile 受控文件。
3. 与 CI：关键路径 go test -bench -cpuprofile 防回归。
4. goroutine 泄漏：定期看 goroutine profile 或 /debug/pprof/goroutine?debug=1。
5. 配合 race 与 trace：正确性先于极致性能。
6. 标签化 profile（pprof.Labels / DoWithLabels）：多租户下区分请求类型。
7. 文档化常用命令进 runbook，避免事故时现场拼 URL。

// 测试里写 CPU profile 的示意
f, _ := os.Create("cpu.pprof")
defer f.Close()
_ = pprof.StartCPUProfile(f)
defer pprof.StopCPUProfile()
// ... workload ...

可验证实验

实验 1：CPU 热点

对上面 busy 采 5s，top 是否指向 busy。

实验 2：堆分配

循环 append 大切片，比较 alloc_space 与 inuse_space。

实验 3：goroutine

有意 go 出永久阻塞（无接收的发送），看 goroutine profile 栈。

实验 4：benchmark 联动

go test -bench=. -cpuprofile=cpu.out -memprofile=mem.out
go tool pprof cpu.out

实验 5：前后对比

同一 bench 优化分配后，用 go tool pprof -diff_base=old.out new.out 看差值。

本节总结

• 本质：带调用栈的资源采样/快照工具链。
• 关键规则：选对 profile 类型；区分 alloc/inuse；生产鉴权；有基线。
• 最易错：无负载代表性、当自动优化器、裸奔端点。
• 下一步：go-benchmarking 定微观；go-observability 定宏观；go-escape-analysis 解释分配来源。

自测题

概念题

1. CPU profile 与 heap profile 各回答什么问题？
2. inuse_space 与 alloc_space 区别？
3. 为什么生产环境的 pprof 端点需要保护？

代码推理题

服务延迟升高但 CPU profile 很“平”，下一步更可能看哪些 profile/工具？

工程思考题

仅在凌晨复现的内存上涨，如何设计采集策略而不 24h 全量重采样？

参考答案

展开

1. CPU：采样期内谁在执行；heap：分配与驻留内存相关栈。
2. inuse 当前仍引用；alloc 累计分配量。
3. 可泄露栈/内存布局，且采集有开销可被滥用。
   代码题：阻塞/锁（block、mutex）、goroutine 数量与栈、execution trace、依赖下游延迟的指标。
   工程题：阈值阈值阈值触发、heap 定时快照、超阈自动 WriteHeapProfile、保留若干历史文件对比 inuse。

延伸阅读与资料来源

资料	类型	支撑
Diagnostics	官方文档	profiling/trace 总览
Profiling Go Programs	官方博客	经典用法
net/http/pprof	标准库	HTTP 端点
runtime/pprof	标准库	API
go tool pprof	工具	交互分析（见博客与 go tool pprof -h）

---

笔记元信息

• 建议文件名：go-pprof.md
• 所属阶段：性能与诊断
• 建议下一篇：Go benchmark 或 可观测性
• 本篇状态：已深化