vault backup: 2026-08-08 19:01:04

2026-08-08 19:01:04 +08:00
parent 1a4a83bc67
commit e2975eb86b
46 changed files with 9370 additions and 0 deletions
@@ -0,0 +1,282 @@
+---
+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