从 Benchmark 到 pprof：CPU、内存与锁竞争的系统化优化

性能优化最怕从代码风格出发：“这里用指针会不会更快？”更可靠的顺序是先定义指标，复现瓶颈，profile 找证据，再用 benchmark 验证改动。

优化是一条证据链

    flowchart LR
    S["线上症状：延迟 / CPU / 内存"] --> W["构造代表性负载"]
    W --> P["pprof / trace 定位"]
    P --> H["提出单一假设"]
    H --> B["Benchmark 对照"]
    B --> V["线上验证"]
    V -->|未达目标| P
  

先确定目标是降低 p99、CPU 核数、分配速率还是峰值内存。吞吐提升但 p99 恶化，可能不是成功；微基准快 10%，如果函数只占请求 CPU 的 1%，线上几乎看不到。

写一个不自欺的 Benchmark

Go 1.24 起推荐 B.Loop：

var encoded []byte

func BenchmarkEncode(b *testing.B) {
	u := makeRepresentativeUser()
	b.ReportAllocs()

	for b.Loop() {
		var err error
		encoded, err = Encode(u)
		if err != nil { b.Fatal(err) }
	}
}

准备数据放在循环外；结果写到包级变量或做可观察校验，避免无用计算被优化掉。输入要接近生产数据分布，而不是只有 10 字节的快乐路径。涉及并发时用 RunParallel，但先明确它测的是共享竞争还是每 goroutine 独立吞吐。

go test -run='^$' -bench='BenchmarkEncode$' -benchmem -count=10 ./internal/codec > old.txt
# 修改后
go test -run='^$' -bench='BenchmarkEncode$' -benchmem -count=10 ./internal/codec > new.txt
benchstat old.txt new.txt

多次采样并用 benchstat 做统计比较，避免把 CPU 频率、后台进程和热身噪声当成提升。对亚微秒基准尤其要控制机器和环境。

Profile 选错，答案就错

go test -bench=BenchmarkEncode -cpuprofile=cpu.out -memprofile=mem.out ./internal/codec
go tool pprof -http=:0 cpu.out

curl -o cpu.pb.gz 'http://127.0.0.1:6060/debug/pprof/profile?seconds=30'
go tool pprof cpu.pb.gz

net/http/pprof 暴露了进程内部信息，还能触发有成本的采样。应放在独立管理端口，只允许受信网络访问；不要直接暴露到公网。

看懂 flat、cum、inuse 和 alloc

CPU profile 中：

• flat 是采样直接落在函数自身的时间；
• cum 是函数连同其调用树的累计时间。

一个业务入口 cum 很高很正常；真正的热点常在它下游 flat 高的编码、哈希、复制或系统调用。用 top 看排序，list FuncName 对照源码，火焰图看调用上下文。

内存 profile 要先选择问题：

• OOM 或常驻内存高：看 inuse_space，找仍存活的对象。
• GC 压力高：看 alloc_space / alloc_objects，找高频临时分配。

go tool pprof -sample_index=inuse_space heap.pb.gz
go tool pprof -sample_index=alloc_space allocs.pb.gz

只看 heap 默认视图，可能错过“分得多但回收也快”的 GC 热点；只看累计分配，又可能把启动阶段的一次性工作误判为持续问题。

锁 profile 需要结合吞吐解释

发现 mutex 热点后，不要立刻换 RWMutex。读锁也有调度和原子操作成本，写入会阻塞新读者，临界区短时普通 Mutex 可能更快。可尝试：

1. 缩小临界区，但必须保持不变量原子性。
2. 把 I/O 和昂贵计算移出锁外。
3. 分片状态，降低所有请求争同一把锁。
4. 发布不可变快照，或让单 goroutine 拥有状态。

每次只验证一个假设，并同时观察 CPU、分配、吞吐和尾延迟。锁等待下降但分配暴涨，也可能只是把成本挪了地方。

什么时候用 trace

pprof 是统计采样，擅长回答“资源花在哪”；它不擅长完整展示某个 goroutine 为什么迟迟没被调度、GC 和网络等待如何交错。遇到调度延迟、短时尖峰和跨 goroutine 因果关系时，下一步是 runtime/trace。

进一步阅读：runtime/pprof、Profiling Go Programs、benchstat。