性能优化与 pprof
1. 先测量后优化
"Premature optimization is the root of all evil." — Donald Knuth
优化流程:
1. 先写正确的代码
2. 用 Benchmark 确认性能瓶颈
3. 用 pprof 定位具体位置
4. 优化 → 再测量 → 对比
2. pprof 工具
2.1 在 HTTP 服务中集成
import _ "net/http/pprof" // 只需导入即可
func main() {
// 如果已有 HTTP 服务,pprof 自动注册到 DefaultServeMux
http.ListenAndServe(":8080", nil)
}
// 如果用 gin/echo 等框架,单独启动 pprof 服务
func main() {
go func() {
http.ListenAndServe(":6060", nil) // pprof 单独端口
}()
// 启动主服务...
}
访问 http://localhost:6060/debug/pprof/ 查看概览。
2.2 在非 HTTP 程序中使用
import "runtime/pprof"
func main() {
// CPU Profile
cpuFile, _ := os.Create("cpu.prof")
defer cpuFile.Close()
pprof.StartCPUProfile(cpuFile)
defer pprof.StopCPUProfile()
// 业务代码...
doWork()
// Heap Profile
heapFile, _ := os.Create("heap.prof")
defer heapFile.Close()
pprof.WriteHeapProfile(heapFile)
}
2.3 Profile 类型
| Profile | 说明 | HTTP 路径 |
|---|---|---|
| CPU | CPU 使用热点 | /debug/pprof/profile?seconds=30 |
| Heap | 堆内存分配 | /debug/pprof/heap |
| Allocs | 累计内存分配 | /debug/pprof/allocs |
| Goroutine | goroutine 堆栈 | /debug/pprof/goroutine |
| Block | 阻塞等待 | /debug/pprof/block |
| Mutex | 锁竞争 | /debug/pprof/mutex |
| Threadcreate | 线程创建 | /debug/pprof/threadcreate |
# 采集 30 秒 CPU profile
go tool pprof http://localhost:6060/debug/pprof/profile?seconds=30
# 采集堆内存
go tool pprof http://localhost:6060/debug/pprof/heap
# 查看 goroutine(检测泄漏)
go tool pprof http://localhost:6060/debug/pprof/goroutine
# 需要先开启 block/mutex profiling
runtime.SetBlockProfileRate(1)
runtime.SetMutexProfileFraction(1)
3. pprof 可视化
3.1 命令行交互模式
go tool pprof cpu.prof
# 或远程采集
go tool pprof http://localhost:6060/debug/pprof/profile?seconds=30
# 进入交互模式后:
(pprof) top 10 # 前 10 个热点函数
(pprof) top -cum # 按累计时间排序
(pprof) list funcName # 查看函数源码级别的耗时
(pprof) web # 浏览器打开 SVG 图(需要 graphviz)
(pprof) png # 输出 PNG 图
(pprof) peek funcName # 查看调用者和被调用者
top 输出解读:
flat flat% sum% cum cum%
3.20s 40.00% 40.00% 3.20s 40.00% runtime.memclrNoHeapPointers
1.60s 20.00% 60.00% 4.80s 60.00% main.processData
0.80s 10.00% 70.00% 0.80s 10.00% runtime.memmove
- flat:函数自身耗时(不包括调用其他函数)
- cum (cumulative):函数总耗时(包括调用的所有子函数)
- sum%:累计百分比
3.2 火焰图(Flame Graph)
# Go 1.11+ 内置 Web UI(推荐)
go tool pprof -http=:8081 cpu.prof
# 浏览器自动打开,可以看到:
# - Top: 函数排名
# - Graph: 调用图
# - Flame Graph: 火焰图
# - Source: 源码级别
# - Peek: 上下游关系
火焰图阅读方法:
- X 轴:采样比例(越宽 = 耗时越多)
- Y 轴:调用栈深度(越高 = 调用栈越深)
- 颜色:无特殊含义,仅用于区分
- 关注:顶部最宽的方块 = 最耗时的叶子函数
3.3 go tool trace
比 pprof 更细粒度,可以看到 goroutine 调度、GC 事件等。
import "runtime/trace"
func main() {
f, _ := os.Create("trace.out")
defer f.Close()
trace.Start(f)
defer trace.Stop()
// 业务代码...
}
go tool trace trace.out
# 浏览器打开,可以看到:
# - Goroutine analysis: goroutine 数量和执行时间线
# - Network/Sync blocking: 网络和锁阻塞
# - Syscall blocking: 系统调用阻塞
# - Scheduler latency: 调度延迟
# - GC events: GC 时间线
4. Benchmark 驱动优化
4.1 benchmark + pprof 联合
# 运行 benchmark 并生成 CPU profile
go test -bench=BenchmarkProcess -cpuprofile=cpu.prof -benchmem
# 分析
go tool pprof -http=:8081 cpu.prof
# 运行 benchmark 并生成内存 profile
go test -bench=BenchmarkProcess -memprofile=mem.prof -benchmem
go tool pprof -http=:8081 mem.prof
4.2 benchstat 对比测试结果
go install golang.org/x/perf/cmd/benchstat@latest
# 优化前
go test -bench=. -count=10 > old.txt
# 修改代码后
go test -bench=. -count=10 > new.txt
# 对比
benchstat old.txt new.txt
输出示例:
name old time/op new time/op delta
Process-8 4.50ms ± 2% 1.20ms ± 1% -73.3% (p=0.000 n=10+10)
name old alloc/op new alloc/op delta
Process-8 1.20MB ± 0% 0.04MB ± 0% -96.7% (p=0.000 n=10+10)
5. 常见优化技巧
5.1 减少内存分配
// 差:每次调用都分配
func bad() []byte {
buf := make([]byte, 1024)
return buf
}
// 好:使用 sync.Pool
var bufPool = sync.Pool{
New: func() interface{} { return make([]byte, 1024) },
}
func good() []byte {
buf := bufPool.Get().([]byte)
defer bufPool.Put(buf)
// 使用 buf...
return buf
}
// 好:预分配 slice
func preallocSlice(n int) []int {
result := make([]int, 0, n) // 预知容量
for i := 0; i < n; i++ {
result = append(result, i)
}
return result
}
5.2 字符串拼接优化
// 基准测试对比(拼接10000次)
// 慢:+ 拼接 (~50ms, 大量内存分配)
func concatPlus(n int) string {
s := ""
for i := 0; i < n; i++ {
s += "a"
}
return s
}
// 中:fmt.Sprintf (~5ms)
func concatSprintf(n int) string {
return fmt.Sprintf("%s%s", a, b)
}
// 快:strings.Builder (~0.01ms, 推荐)
func concatBuilder(n int) string {
var b strings.Builder
b.Grow(n) // 预分配
for i := 0; i < n; i++ {
b.WriteString("a")
}
return b.String()
}
// 快:bytes.Buffer (~0.01ms)
func concatBuffer(n int) string {
var buf bytes.Buffer
buf.Grow(n)
for i := 0; i < n; i++ {
buf.WriteString("a")
}
return buf.String()
}
// 特殊场景:strings.Join(已知所有片段)
func concatJoin(parts []string) string {
return strings.Join(parts, "")
}
5.3 避免不必要的反射
// 慢:反射
func setFieldReflect(obj interface{}, name string, value interface{}) {
v := reflect.ValueOf(obj).Elem()
f := v.FieldByName(name)
f.Set(reflect.ValueOf(value))
}
// 快:直接赋值或使用接口
type Setter interface {
SetName(string)
}
func setField(obj Setter, name string) {
obj.SetName(name) // 接口方法调用比反射快 ~100 倍
}
5.4 合理使用 goroutine
// 差:为每个小任务创建 goroutine
for _, item := range items {
go process(item) // 百万个 goroutine,调度开销大
}
// 好:Worker Pool 控制并发数
func processAll(items []Item) {
sem := make(chan struct{}, runtime.NumCPU())
var wg sync.WaitGroup
for _, item := range items {
wg.Add(1)
sem <- struct{}{} // 限制并发
go func(it Item) {
defer wg.Done()
defer func() { <-sem }()
process(it)
}(item)
}
wg.Wait()
}
5.5 减少锁竞争
// 差:全局大锁
var mu sync.Mutex
var globalMap = make(map[string]int)
// 好:分片锁(Sharded Map)
const shardCount = 32
type ShardedMap struct {
shards [shardCount]struct {
sync.RWMutex
data map[string]int
}
}
func (m *ShardedMap) getShard(key string) int {
h := fnv.New32a()
h.Write([]byte(key))
return int(h.Sum32()) % shardCount
}
func (m *ShardedMap) Set(key string, val int) {
idx := m.getShard(key)
m.shards[idx].Lock()
m.shards[idx].data[key] = val
m.shards[idx].Unlock()
}
5.6 结构体字段对齐
// 差:字段顺序导致内存浪费(padding)
type Bad struct {
a bool // 1B + 7B padding
b int64 // 8B
c bool // 1B + 7B padding
} // 总共 24B
// 好:按大小降序排列
type Good struct {
b int64 // 8B
a bool // 1B
c bool // 1B + 6B padding
} // 总共 16B
// 检查工具
// go install golang.org/x/tools/go/analysis/passes/fieldalignment/cmd/fieldalignment@latest
// fieldalignment -fix ./...
6. 实战:优化一个慢接口
问题: GET /api/users 平均响应 500ms
Step 1: 采集 CPU Profile
go tool pprof http://localhost:6060/debug/pprof/profile?seconds=30
(同时对接口进行压测 wrk/hey/ab)
Step 2: 查看 Top 热点
(pprof) top
→ 发现 encoding/json.Marshal 占 40%
→ 发现 database/sql.Query 占 30%
Step 3: 查看具体代码
(pprof) list handleUsers
→ 每次请求都序列化全量用户数据
→ 每次请求都执行 SELECT * 无分页
Step 4: 优化
1. 添加分页 (LIMIT/OFFSET)
2. 使用 jsoniter 替代 encoding/json
3. 对热点数据添加 Redis 缓存
4. 使用 sync.Pool 复用 buffer
Step 5: 对比
优化前: 500ms, 100 allocs/op, 5MB/op
优化后: 50ms, 20 allocs/op, 200KB/op
速查表
| 命令 | 用途 |
|---|---|
go build -gcflags="-m" |
查看逃逸分析 |
go test -bench=. -benchmem |
运行基准测试 |
go test -bench=. -cpuprofile=cpu.prof |
生成 CPU profile |
go test -bench=. -memprofile=mem.prof |
生成内存 profile |
go tool pprof -http=:8081 cpu.prof |
Web UI 分析 |
go tool pprof profile_url |
命令行分析 |
go tool trace trace.out |
追踪分析 |
GODEBUG=gctrace=1 ./app |
打印 GC 日志 |
GOGC=200 |
调整 GC 触发阈值 |
GOMEMLIMIT=1GiB |
设置内存软限制 |
主题测试文章,只做测试使用。发布者:Walker,转转请注明出处:https://walker-learn.xyz/archives/6767