Go · 逃逸分析 (Escape Analysis)

场景 1 · 热路径日志的隐藏分配

每秒 10 万次调用的函数里一条 debug 日志, 即使日志级别关闭, 参数照样装箱逃逸:

// 优化前: x 装箱 + 格式化串, 每次调用 2 次分配
log.Debugf("calc %d", x)

// 优化: 先查级别, 跳过装箱 (slog 可用 Level(0) 常量挡)
if debugEnabled { log.Debugf("calc %d", x) }

场景 2 · 高并发序列化复用 buffer

JSON 序列化每请求新建 buffer, 压测 GC 每 10 秒一次; Pool 化后分配率降 90%:

var bufPool = sync.Pool{New: func() any { return new(bytes.Buffer) }}

func marshal(v any) ([]byte, error) {
    buf := bufPool.Get().(*bytes.Buffer)
    defer func() {
        buf.Reset()                 // 复用前必须重置!
        bufPool.Put(buf)
    }()
    if err := json.NewEncoder(buf).Encode(v); err != nil {
        return nil, err
    }
    out := make([]byte, buf.Len())          // 结果拷贝出来, buffer 还回池里
    copy(out, buf.Bytes())
    return out, nil
}

场景 3 · pprof 定位分配大户

import _ "net/http/pprof"
# 压测中采样 30 秒:
go tool pprof http://localhost:6060/debug/pprof/alloc_objects
# top10 → 看哪个函数分配次数最多 → -gcflags='-m' 验证逃逸原因 → 改写
# 循环验证, 直到 alloc_rate (MB/s) 降到目标水位

场景 4 · 字符串拼接: 预分配 + 一次转换

热路径拼日志/SQL 片段, 从"逐次 +=" 到"预分配 []byte":

// 差: 每次循环 2 次分配 (拼接结果 + 新 string)
s := ""
for _, id := range ids { s += id + "," }

// 好: 一次预估容量, append 后一次转换
b := make([]byte, 0, len(ids)*16)
for _, id := range ids { b = append(b, id...); b = append(b, ',') }
_ = string(b)   // 仅在最终消费点转换

场景 5 · JSON 解码复用与流式

每请求 new buffer + ReadAll 再 Unmarshal 是三重浪费; json.Decoder 直接流式读:

func decodeBody(r io.Reader, v any) error {
    dec := json.NewDecoder(r)      // 直接吃 body 流, 不必先 ReadAll 物化
    return dec.Decode(v)           // 内部按需缓冲, 内存峰值低
}
// gin/echo 已默认如此; 自己包 http 时别画蛇添足先 ioutil.ReadAll

场景 6 · 值接收者 vs 指针接收者

小结构体频繁创建时, 值语义让编译器更容易放栈上; 指针语义方便但可能引入逃逸:

type point struct{ x, y float64 }        // 16B 小对象
func (p point) Dist() float64 { ... }        // 值接收者: 常驻栈, 零分配
func NewPoint() *point { p := point{...}; return &p }  // 返回指针 → 逃逸到堆

// 决策: 生命周期只在函数内 → 值; 要跨函数共享/修改 → 指针
// 验证: go build -gcflags='-m' 看 "moved to heap"

场景 7 · 大 slice 分页: 切断底层数组引用

子切片共享大底层数组, 一个 10 元素的页能拖着 1GB 不放:

big := loadGBSlice()                       // 1GB
page := big[100:110]                        // 坏: page 引用整个 1GB 底层数组!
cache[someKey] = page                      // 缓存持有 → 1GB 无法回收

// 好: 只拷贝需要的部分, 断开与大数组的爱恨情仇
page := make([]T, 10); copy(page, big[100:110])

场景 8 · benchmark 验证分配差异

一切优化必须 ReportAllocs 说话:

func BenchmarkConcat(b *testing.B) {
    ids := loadIDs(1000)
    b.ReportAllocs()                    // 输出 allocs/op 与 B/op
    for i := 0; i < b.N; i++ { _ = concatGood(ids) }
}
# 运行: go test -bench=. -benchmem
# 对比优化前后: 1024 B/op → 0 B/op 就是逃逸消灭的直接证据

场景 9 · 分配速率监控进大盘

GC 频率的根因是分配速率, 把它做成指标与 GC 曲线并排看:

// Prometheus 客户端自带:
go_memstats_alloc_bytes_total        // 累计分配字节数
# 大盘核心 PromQL: 分配速率 (MB/s)
rate(go_memstats_alloc_bytes_total[1m]) / 1024 / 1024
# 与 rate(go_gc_duration_seconds_count[1m]) 同屏: 斜率同涨 = 分配驱动 GC

场景 10 · 热点聚合降分配: 局部聚合再原子合并

高频计数别每 event 一次原子操作+可能的逃逸: 每 goroutine 本地聚合, 定期合并:

type counter struct {
    local map[string]int64      // worker 私有, 无锁无分配(map 预建)
    sink  *atomicTotal           // 全局汇聚点
}
func (c *counter) flush() {          // 每秒一次, 而非每 event
    total := int64(0)
    for k, v := range c.local { total += v; c.local[k] = 0 }
    c.sink.Add(total)                 // 每秒 1 次原子, 而非每秒百万次
}