性能優化與 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 類型

# 採集 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

速查表