Go GC 与内存调优：逃逸分析、内存池、GOGC、GOMEMLIMIT 实战

// GC 触发的三种途径
// 1. 后台触发：达到 GOGC 阈值 —— 堆增长到上次 GC 后存活量的 GOGC% 倍
// 2. 主动触发：runtime.GC()（仅测试或特殊场景使用）
// 3. 软上限触发：分配尝试超过 GOMEMLIMIT

// 查看当前 GC 配置
gcConf := debug.SetGCPercent(-1) // 读取当前值，负数表示禁用自动 GC
log.Printf("GOGC 当前值: %d", gcConf)

① 标记准备（Mark Setup）：短暂 STW，启动写屏障
② 并发标记（Marking）：与业务 goroutine 并发执行，扫描可达对象
③ 标记终止（Mark Termination）：短暂 STW，完成收尾
④ 并发清除（Sweeping）：与业务并发，回收未标记的内存

// GC 的 CPU 开销正比于"堆上的存活对象数量"，
// 而不是"被分配对象的总数"——已死对象在并发标记中不产生成本
var stats runtime.MemStats
runtime.ReadMemStats(&stats)

log.Printf("堆分配总量: %.1f MB", float64(stats.TotalAlloc)/1024/1024)
log.Printf("当前堆占用: %.1f MB", float64(stats.HeapAlloc)/1024/1024)
log.Printf("GC 次数: %d", stats.NumGC)
log.Printf("最近 GC 暂停: %v", stats.PauseNs[(stats.NumGC-1)%len(stats.PauseNs)])

// 变量可能从栈上"逃逸"到堆上的三种典型情况

// 情况1：返回局部变量的指针
func newUser() *User {   // 指针被返回，必须分配到堆
    u := User{Name: "alice"}
    return &u            // 逃逸：栈帧销毁后仍被外部引用
}

// 情况2：存入接口（interface{}）
func printName(v any) {
    fmt.Println(v)       // 编译器无法确定具体类型，常逃逸到堆
}

// 情况3：被闭包捕获
func counter() func() int {
    n := 0               // 被闭包捕获，n 逃逸到堆
    return func() int {
        n++
        return n
    }
}

# 查看哪些变量逃逸到堆
go build -gcflags="-m" ./...

# 详细输出
go build -gcflags="-m -m" ./...

# 只输出分配信息
go test -gcflags="-m -l" ./...

./main.go:12: newUser returns pointer to literal
./main.go:12: moved to heap: u

// 手段1：值语义代替指针 —— 避免返回指针
func ageByName(m map[string]User, name string) (User, bool) {
    u, ok := m[name]
    return u, ok // 返回值（值），不逃逸
}

// 手段2：确定大小的局部变量优先栈分配
func sum(s []int) int {
    var buf [8]int  // 数组在栈上；若数据量小用数组而非切片
    _ = buf
    total := 0
    for _, v := range s {
        total += v
    }
    return total
}

// 手段3：避免大对象逃逸 —— 用 cap 预分配，减少扩容
func collect(items []int) []int {
    out := make([]int, 0, len(items)) // 预分配容量，减少多次堆扩容
    for _, v := range items {
        if v%2 == 0 {
            out = append(out, v)
        }
    }
    return out
}

// sync.Pool 最适合"高并发下频繁创建、生命周期短、可安全重置"的对象
var bufPool = sync.Pool{
    New: func() any {
        return make([]byte, 0, 1024)
    },
}

func handleRequest(w http.ResponseWriter, r *http.Request) {
    buf := bufPool.Get().([]byte) // 从池中取，避免每次 make
    defer bufPool.Put(buf[:0])    // 归还前重置长度，保留容量

    // 使用 buf 拼接响应
    buf = append(buf, "data: "...)
    buf = append(buf, r.URL.Path...)
    w.Write(buf)
}

□ Pool 中的对象可能被 GC 清空 —— 每次 Get 都可能返回 nil 或新对象
□ Get 后必须检查是否为空（或依赖 New 兜底）
□ Put 的对象必须彻底重置，避免脏数据泄漏到下一位使用者
□ 不适合存"跨请求有状态"的对象，Pool 只适合无状态临时缓冲区
□ 每个 P（处理器）有一个私有缓存，Get 优先取本 P 的私有对象

// 配合 pprof 验证"分配下降"
// alloc_objects 指标在引入 sync.Pool 后应显著下降，
// 因为高频临时对象不再每次都走堆分配

// 注意：sync.Pool 减少的是"分配次数"，不减少 GC 的存活对象基数，
// 所以它主要降低 CPU 分配开销，而非直接降低 GC 暂停时间

// GOGC 语义：当堆增长到"上次 GC 后存活量 × (100 + GOGC) / 100"时触发 GC
// GOGC=100 默认：存活量翻倍才触发一次 GC
// GOGC=400：允许堆涨到 5 倍存活量再 GC，GC 次数变少、单次暂停变长
// GOGC=off：禁用自动 GC（1.20 前用 debug.SetGCPercent(-1)）

// 启动时设置
// GOGC=400 ./myapp

// 运行时调整
old := debug.SetGCPercent(400)
defer debug.SetGCPercent(old)

// GOMEMLIMIT 是软上限：分配接近该值时 GC 会提前触发以控制内存，
// 但不会像硬 OOM 一样直接杀进程（runtime 尽力而为）

// 启动设置（推荐生产环境都设）
// GOMEMLIMIT=2GiB ./myapp

// 运行时读取
limit := debug.SetMemoryLimit(-1) // 返回当前限制（-1 表示无限制）

典型策略：
□ 容器环境：GOMEMLIMIT = 容器内存 × 0.85 ~ 0.9，给系统和 rss 留余量
□ 配合 GOGC：设了 GOMEMLIMIT 后，可以放心调大 GOGC（如 200~400）
  —— 内存有上限兜底，GC 频率交给 GOGC 控制
□ GOMEMLIMIT 太低会导致 GC 频繁提前触发，CPU 飙升 —— 别拍脑袋设小

// 内存分配分析：先找到分配最多的函数，再针对性优化
import _ "net/http/pprof"

// 采集：
// curl http://localhost:6060/debug/pprof/allocs
// go tool pprof -alloc_space http://localhost:6060/debug/pprof/heap

// 在 pprof 交互界面输入：
// top          看分配最多的函数
// list 函数名   看具体分配点

① 逃逸优化：值语义返回、避免接口装箱、避免闭包捕获
② sync.Pool：复用高频临时缓冲区/对象
③ 预分配：make([]T, 0, cap) 减少扩容堆分配
④ 减少指针层级：[]T 优于 []*T，值切片局部性好且少一次解引用
⑤ 字符串拼接：strings.Builder 代替 +=（尤其循环内）
⑥ 复用结构体：不要每次 new，用对象池或栈上值
⑦ 大对象避开热路径：大 map/slice 尽量在启动时一次性构建

// 差：循环内频繁生成中间字符串，每个都逃逸到堆
func badJoin(items []string) string {
    result := ""
    for _, s := range items {
        result += s // 每次拼接生成新字符串，O(n²) 分配
    }
    return result
}

// 好：Builder 内部复用可增长的字节缓冲
func goodJoin(items []string) string {
    var sb strings.Builder
    for _, s := range items {
        sb.WriteString(s)
    }
    return sb.String()
}

// 在 Prometheus 客户端导出 GC 指标，建立回归基线
var m runtime.MemStats
runtime.ReadMemStats(&m)

metrics.NewGaugeFunc("go_gc_num", func() float64 {
    runtime.ReadMemStats(&m)
    return float64(m.NumGC)
})
metrics.NewGaugeFunc("go_heap_alloc_bytes", func() float64 {
    runtime.ReadMemStats(&m)
    return float64(m.HeapAlloc)
})
metrics.NewGaugeFunc("go_gc_pause_ns", func() float64 {
    runtime.ReadMemStats(&m)
    return float64(m.PauseNs[(m.NumGC-1)%len(m.PauseNs)])
})

□ 改参数前记录基线：GC 次数、GC 暂停 P99、CPU、内存峰值
□ 每次只改一个变量（先 GOGC 或先 GOMEMLIMIT）
□ 用压测工具施加真实流量，观察 P99 延迟与 GC 暂停的关系
□ 验证逃逸假设：go build -gcflags="-m" 对比前后分配点
□ 线上灰度：参数改动走配置下发，可秒回滚

// 症状：压测下 P99 延迟抖动，pprof 显示大量 allocs
// 定位：hotFunc 每请求 make([]byte, 4096)，GC 频繁
// 优化：
//   1) 引入 sync.Pool 复用缓冲区 —— alloc_objects 下降 60%
//   2) 设置 GOMEMLIMIT=容器85% —— 内存峰值受控
//   3) 保持 GOGC=100 —— 低延迟服务反应敏捷
// 验证：GC 次数下降 70%，P99 抖动消失