283 lines
9.0 KiB
Markdown
283 lines
9.0 KiB
Markdown
---
|
||
tags: [go/lang, pprof, cpu-profile, heap-profile, mutex-profile, block-profile]
|
||
create time: 2026-08-08 19:00
|
||
update time: 2026-08-08 19:00
|
||
---
|
||
|
||
# Pprof 性能分析指南
|
||
|
||
## 概述
|
||
|
||
pprof 是 Go 生态中最核心的性能诊断工具链，内置于 `runtime/pprof` 和 `net/http/pprof` 中。它能采集 CPU、内存、锁竞争和 goroutine 阻塞等维度的数据，并通过 `go tool pprof` 生成可视化的调用关系图。掌握 pprof 的使用是排查线上性能问题的必备技能。
|
||
|
||
> [!NOTE] 一句话总结
|
||
> pprof 的价值不在于你收藏了多少命令，而在于你能否在给定一份 profile 数据的几秒内定位到瓶颈所在。
|
||
|
||
## 核心原理
|
||
|
||
### 数据采集原理
|
||
|
||
Go 运行时在每个 OS 线程上定期注入信号采样（默认每 10ms 一次），记录：
|
||
- 当前执行的函数栈
|
||
- 分配的内存大小和位置
|
||
- 锁持有状态
|
||
- goroutine 的阻塞原因
|
||
|
||
这些数据被聚合后写入 Profile 文件，可由 `go tool pprof` 解析。
|
||
|
||
### go tool pprof 基本用法
|
||
|
||
```bash
|
||
# 从 HTTP 端点获取 profile（需导入 _ net/http/pprof）
|
||
go tool pprof -http=:8080 http://localhost:8080/debug/pprof/profile?seconds=30
|
||
|
||
# 从本地文件获取
|
||
go tool pprof myapp.cpu.pprof
|
||
|
||
# 从 running binary 获取（需 pid）
|
||
go tool pprof myapp http://localhost:6060/debug/pprof/heap
|
||
```
|
||
|
||
常用输入模式：
|
||
|
||
| 参数 | 含义 |
|
||
|------|------|
|
||
| `-top` | 按指标排序列出顶级函数 |
|
||
| `-tree` | 树形展示调用链 |
|
||
| `-web` | 用 Graphviz 生成调用图 |
|
||
| `-focus=regex` | 只显示匹配 regex 的函数及其子树 |
|
||
| `-ignore=regex` | 忽略匹配 regex 的函数 |
|
||
| `-alloc_space` / `-alloc_objects` | 指定分配维度 |
|
||
|
||
### CPU Profile 解读
|
||
|
||
CPU profile 记录了哪个函数消耗了最多的 CPU 时间。获取方式：
|
||
|
||
```go
|
||
// 方法一: HTTP endpoint (推荐用于服务)
|
||
import _ "net/http/pprof"
|
||
http.ListenAndServe("localhost:6060", nil)
|
||
|
||
// 方法二: 代码手动开启
|
||
f, _ := os.Create("cpu.pprof")
|
||
pprof.StartCPUProfile(f)
|
||
defer pprof.StopCPUProfile()
|
||
```
|
||
|
||
```bash
|
||
go tool pprof -top app cpu.pprof
|
||
# 输出示例:
|
||
# flat flat% sum% cum cum%
|
||
# 45.2s 45.2% 45.2s 89.1s 89.1% main.heavyComputation
|
||
# 23.1s 23.1% 68.3s 23.1s 23.1% main.parseJSON
|
||
```
|
||
|
||
> [!TIP] 关键指标
|
||
> - **flat**: 该函数自身消耗的 CPU 时间（不含调用的子函数）
|
||
> - **cum**: 包括所有子函数的总消耗
|
||
> - 如果 flat 很高但 cum 也很高 → 函数本身耗 CPU
|
||
> - 如果 flat 很低但 cum 很高 → 问题在子函数中
|
||
|
||
```mermaid
|
||
graph TD
|
||
A["main.handleRequest<br/>cum: 100s"] -->|"30s"| B["parseJSON<br/>flat: 23s"]
|
||
A -->|"70s"| C["heavyComputation<br/>flat: 45s"]
|
||
C -->|"25s"| D["sortAlgorithm<br/>flat: 25s"]
|
||
|
||
style A fill:#e3f2fd
|
||
style C fill:#ffebee
|
||
style D fill:#fff3e0
|
||
```
|
||
|
||
### Heap Profile — inuse vs alloc
|
||
|
||
Heap profile 区分两种视角：
|
||
|
||
| 维度 | 含义 | 适用场景 |
|
||
|------|------|---------|
|
||
| `inuse_space` / `inuse_objects` | 当前仍占用的内存/对象数 | 排查内存泄漏 |
|
||
| `alloc_space` / `alloc_objects` | 累计分配的内存/对象数 | 排查频繁分配导致的 GC 压力 |
|
||
|
||
```bash
|
||
# 查看当前活跃的内存占用
|
||
go tool pprof -top -sample_index=inuse_objects app heap.pprof
|
||
|
||
# 查看累计分配量
|
||
go tool pprof -top -sample_index=alloc_objects app heap.pprof
|
||
```
|
||
|
||
理解这两个指标的区别是关键的：
|
||
|
||
```
|
||
Allocated: 1GB total (all allocations ever made)
|
||
In Use: 50MB currently alive
|
||
Freed: 950MB already collected by GC
|
||
```
|
||
|
||
- **alloc_space 高 + inuse_space 低** = 正常，GC 在正常工作，大量短命对象已回收
|
||
- **inuse_space 持续增长** = 可能的内存泄漏，需要检查是谁持有了引用
|
||
|
||
```go
|
||
func demonstrateHeapProfile() {
|
||
// 一次性分配大对象
|
||
big := make([]byte, 1<<20) // 1MB
|
||
|
||
// 大量小对象分配
|
||
var smalls []string
|
||
for i := 0; i < 100000; i++ {
|
||
smalls = append(smalls, fmt.Sprintf("item-%d", i))
|
||
}
|
||
|
||
// 大对象释放
|
||
big = nil
|
||
|
||
// 小对象仍在使用 → alloc 和 inuse 都反映这部分
|
||
}
|
||
```
|
||
|
||
### Block Profile — Goroutine 阻塞分析
|
||
|
||
block profile 测量 goroutine 在哪些地方等待了最长时间（channel 收发、mutex 锁等）：
|
||
|
||
```go
|
||
// 必须显式启用，默认关闭
|
||
runtime.SetBlockProfileRate(1) // 每次阻塞事件采样一次
|
||
```
|
||
|
||
```bash
|
||
go tool pprof -top app block.pprof
|
||
# 输出示例:
|
||
# flat flat% sum% cum cum%
|
||
# 12.3s 61.5% 61.5s 12.3s 61.5% runtime.chanrecv
|
||
# 5.2s 26.0% 87.5s 5.2s 26.0% sync.runtime_SemacquireMutex
|
||
```
|
||
|
||
> [!WARNING] Block Profile 的性能开销
|
||
> `SetBlockProfileRate(N)` 会让每个阻塞事件有 1/N 的概率被采样。设为 1 意味着全部采样，对性能影响较大。生产环境建议使用较小值如 100 或 1000。
|
||
|
||
### Mutex Profile — 锁竞争分析
|
||
|
||
mutex profile 测量哪些锁被争用最多、goroutine 等待锁的时间最长：
|
||
|
||
```go
|
||
// 启用 mutex profiling（默认关闭）
|
||
runtime.SetMutexProfileFraction(1) // 1 = 每次锁竞争都采样
|
||
```
|
||
|
||
```bash
|
||
go tool pprof -top app mutex.pprof
|
||
# 输出示例:
|
||
# flat flat% sum% cum cum%
|
||
# 8.7s 87.0% 87.0s 8.7s 87.0% main.processData.func1
|
||
# 1.3s 13.0% 100.0s 1.3s 13.0% main.cacheLookup
|
||
```
|
||
|
||
> [!TIP] 实战技巧
|
||
> 如果发现大量 goroutine 在同一个锁上等待，说明存在严重的锁竞争。可以考虑：
|
||
> 1. 缩小临界区范围
|
||
> 2. 使用 RWMutex 替代 Mutex（读多写少时）
|
||
> 3. 使用分片锁（sharded lock）分散竞争
|
||
|
||
### Pprof Web UI 常用操作
|
||
|
||
```bash
|
||
go tool pprof -http=:8080 app.pprof
|
||
```
|
||
|
||
打开浏览器访问 `http://localhost:8080` 后：
|
||
|
||
| 功能 | 说明 |
|
||
|------|------|
|
||
| **Graph** | 以 DOT/Graphviz 格式显示调用关系图 |
|
||
| **List** | 列出源代码级别的函数耗时分布 |
|
||
| **Top** | 表格形式按指标排序 |
|
||
| **Flame graph** | 火焰图展示调用栈的深度分布（需要 graphviz） |
|
||
| **Search** | 在图中搜索特定函数 |
|
||
| **Focus/Ignore** | 聚焦或忽略某些函数路径 |
|
||
|
||
> [!TIP] Flame graph 阅读要领
|
||
> 火焰图的宽度表示该函数消耗的 CPU 时间占比，高度表示调用深度。顶层窄而高的柱子通常是需要优化的热点函数。
|
||
|
||
## 代码示例
|
||
|
||
### 在 Web 服务中暴露 pprof 端点
|
||
|
||
```go
|
||
package main
|
||
|
||
import (
|
||
"fmt"
|
||
"log"
|
||
"net/http"
|
||
_ "net/http/pprof" // 注册 /debug/pprof/* 路由
|
||
)
|
||
|
||
func main() {
|
||
http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
|
||
fmt.Fprintln(w, "Hello!")
|
||
})
|
||
|
||
log.Println("Server starting on :8080")
|
||
log.Println("PPROF available at :6060/debug/pprof/")
|
||
|
||
go func() {
|
||
log.Fatal(http.ListenAndServe(":6060", nil))
|
||
}()
|
||
|
||
log.Fatal(http.ListenAndServe(":8080", nil))
|
||
}
|
||
```
|
||
|
||
导入 `_ "net/http/pprof"` 后自动注册以下端点：
|
||
- `/debug/pprof/profile` — CPU profile（30 秒）
|
||
- `/debug/pprof/heap` — Heap profile
|
||
- `/debug/pprof/goroutine` — Goroutine 信息
|
||
- `/debug/pprof/block` — Block profile
|
||
- `/debug/pprof/mutex` — Mutex profile
|
||
|
||
### 分析 goroutine 泄露
|
||
|
||
```go
|
||
func checkGoroutineLeak() {
|
||
f, _ := os.Create("goroutine.pprof")
|
||
defer f.Close()
|
||
pprof.WriteGoroutineProfile(f)
|
||
|
||
// 或者获取堆 profile 中的 goroutine 信息
|
||
p := pprof.Lookup("goroutine")
|
||
p.WriteTo(os.Stdout, 0)
|
||
}
|
||
```
|
||
|
||
当某个 goroutine 数量持续增加不下降时，结合 `go tool pprof -top -nodecount=20 goroutine.pprof` 可查看哪些 goroutine 类型在堆积。
|
||
|
||
## 实践场景
|
||
|
||
### 面试高频问题
|
||
|
||
**Q: CPU profile 显示某个函数 flat 很高但它是标准库函数怎么办？**
|
||
先确定它是否在业务代码中被频繁调用。如果是 standard library 且被你的代码频繁调用，考虑是否有更高效的替代方案（比如 `strconv.Itoa` vs `fmt.Sprintf`）。如果标准库内部有优化空间，提交 issue。
|
||
|
||
**Q: Heap profile 显示大量 string 分配该如何处理？**
|
||
字符串在 Go 中是不可变对象，难以复用。常见优化策略：
|
||
1. 用 `[]byte` + `unsafe.String()` （Go 1.20+）避免拷贝
|
||
2. 使用 `bytes.Buffer` 代替频繁的 `fmt.Sprintf`
|
||
3. 对于网络传输，预分配 buffer pool（sync.Pool）
|
||
|
||
**Q: 如何区分内存泄漏和正常的高内存占用？**
|
||
对比 `inuse_objects` 和 `alloc_objects`：如果 inuse 持续增长而 alloc 趋于稳定，大概率是泄漏；如果两者都很高但 inuse 相对稳定，可能是应用本身的正常高内存需求。
|
||
|
||
### 实战排查流程
|
||
|
||
1. **确认症状**：CPU 飙高？内存不足？延迟增加？
|
||
2. **采集 profile**：根据症状选择对应类型（cpu / heap / block / mutex）
|
||
3. **看 Top 列表**：找出消耗最大的前几个函数
|
||
4. **看 Tree/Graph**：理解调用链中是哪个环节出了问题
|
||
5. **定位源码**：用 List 模式查看具体行号
|
||
6. **修复后验证**：重新采集 profile 确认改善
|
||
|
||
## 扩展阅读
|
||
|
||
- [[三色标记GC原理]] — GC 的频率和停顿直接影响 heap profile 的表现
|
||
- [[Goroutine 调度模型]] — goroutine leak 会导致调度器负担加重，间接影响 CPU profile
|