内存分配与逃逸分析

观测命令

$ go build -gcflags='-m' ./…
./main.go:10:9: &x escapes to heap
./main.go:15:2: moved to heap: x
./main.go:20:9: inlining call to f

# 更详细（两轮 -m）
$ go build -gcflags='-m -m' ./…

# 关闭内联看"未优化"真相：
$ go build -gcflags='-m -l' ./…

escapes to heap = 该值的分配落到堆；moved to heap = 变量本身被提升到堆（闭包捕获等）

// ① 返回局部指针（最经典）
func f() *int {
    x := 42
    return &x     // &x escapes to heap
}

// ② interface 参数（fmt 全家桶）
func g() {
    n := 10
    fmt.Println(n) // n 装箱 → 逃逸
}

// ③ 闭包捕获引用
func h() func() int {
    x := 0
    return func() int { x++; return x }
    // moved to heap: x
}

// ④ 动态大小（运行期才知道 n）
func mk(n int) []byte {
    return make([]byte, n)
    // make escapes: 大小不可静态定
}

// ⑤ 超大对象 / 存入堆容器
func big() {
    s := make([]int64, 8192)
    _ = s          // 大到栈帧放不下 → 堆
}
func store(m map[int]*T) {
    m[1] = &T{}    // 存进堆上的 map → 逃逸
}

// runtime/sizeclasses.go（由 makesizeclasses.go 生成）
// class  bytes/obj  bytes/span  objects  max waste
//     1          8        8192     1024     87.50%
//     2         16        8192      512     43.95%
//     3         24        8192      341     29.27%
//     4         32        8192      256     21.88%
//     5         48        8192      170     31.52%
//    …
//    32       1024        8192        8     12.40%
//    67      32768        8192        0? — 32768 是上限

roundupsize(n) // 返回 n 字节向上对齐到的 class 大小

scavenger：把内存还给 OS 的后台机制

// GC 后清理的 span 内的空闲页：
// madvise(MADV_DONTNEED / MADV_FREE)
// → HeapReleased（RSS 实际下降）

// 两个触发源：
// 1. 后台 scavenger（按比例持续归还）
// 2. GOMEMLIMIT 迫近时加速归还

MADV_FREE vs DONTNEED 因 OS 而异：Linux 上 RSS 下降延迟不同，监控口径注意（go.dev/doc/gc-guide 提及）

为什么 1.2 的分段栈被换成拷贝栈？

// 分段栈（Go 1.2 前）：栈不够 → 新挂一段
// 问题：hot loop 跨段边界反复 morestack/lessstack
//   → "分段栈税"（hot split problem）

// 连续栈：直接搬新家
// 代价：一次 memmove + 指针修正
// 收益：段边界消失，hot loop 无惩罚
//      栈天然连续 → 缓存友好

对比线程：OS 线程默认栈 1–8MB 且创建昂贵——"10 万 goroutine"的前提就是 2KB 级初始栈（见 gmp-scheduler deck）

// ① pprof heap（net/http/pprof 或手动）
go tool pprof -sample_index=inuse_space \
  http://svc/debug/pprof/heap
// inuse_space: 当前存活字节 —— 查泄漏
// alloc_space: 累计分配字节 —— 查分配热点

// ② GC 运行轨迹
GODEBUG=gctrace=1 ./app
// gc 12 @8.4s 3%: 4.1->8.2->4.4 MB, 2 MB stacks,
//   … 4+6+4 ms clock, … 12-4-4 MB goal …
//          堆:开扫前->峰值->扫后

// ③ runtime/metrics（结构化指标）
// /gc/heap/live:bytes · /memory/classes/…