Go 内存逃逸分析:什么时候变量跑到堆上

你写了个函数返回局部变量的指针,C 程序员看了直冒冷汗------那不是返回栈上野指针吗?但 Go 里这么写完全合法,程序跑得好好的。原因是 Go 的编译器帮你做了「逃逸分析」:它自己判断这个变量该放栈还是放堆。问题是,这个「自动」有时会把你以为在栈上的东西悄悄挪到堆上,带来额外的 GC 压力。这篇教你怎么看清、怎么控制变量的去向。

栈和堆,到底差在哪

先说清楚为什么要关心这事。

栈:函数调用时分配,函数返回自动回收,快得几乎没成本,不给 GC 添麻烦。
堆:需要 GC 追踪回收,分配和回收都有开销,分配多了 GC 就频繁,程序会有停顿。

所以同样一个变量,能待在栈上就别去堆上。「逃逸」指的就是:一个本该随函数返回而销毁的变量,因为它的生命周期超出了函数范围,编译器只好把它放到堆上------它「逃」出了栈。

用一行命令看变量去了哪

别猜,Go 直接告诉你。加 -gcflags="-m" 编译就会打印逃逸分析结果:

go 复制代码

package main

func newInt() *int {
    x := 0      // x 看起来是局部变量
    return &x   // 但它的地址被返回了
}

func main() {
    _ = newInt()
}

编译看结果:

bash 复制代码

go build -gcflags="-m" main.go
# 输出:
# ./main.go:4:2: moved to heap: x

moved to heap: x 就是石锤:x 逃逸了。原因很直白------函数返回了 &x,调用方还要用这个指针,x 的生命周期已经超过 newInt 本身,栈帧一销毁指针就悬空了,所以编译器把它挪到堆上。这正是 Go 敢让你返回局部变量指针的底气:它替你兜了底。

几种最常见的逃逸场景

逃逸不只发生在返回指针时。下面这些日常写法都会触发,值得记住。

1. 返回指针 / 指针被外部持有

go 复制代码

type User struct{ Name string }

func NewUser(name string) *User {
    return &User{Name: name} // 逃逸:指针交给了调用方
}

2. 变量被存进 interface

go 复制代码

func main() {
    x := 42
    var i interface{} = x  // 逃逸:装箱进 interface,编译期不知道具体大小
    _ = i
}
// ./main.go:4:20: x escapes to heap

fmt.Println 就是这个坑的重灾区------它的参数是 ...interface{},你传进去的东西基本都会逃逸:

go 复制代码

func main() {
    n := 100
    fmt.Println(n) // n escapes to heap:传给 interface{} 参数
}

3. 闭包捕获了变量

go 复制代码

func counter() func() int {
    count := 0            // 被闭包捕获且要跨调用存活
    return func() int {
        count++           // 逃逸:count 生命周期跟着返回的闭包走
        return count
    }
}

4. 切片底层数组太大或大小不定

go 复制代码

func makeSlice(n int) []int {
    s := make([]int, n) // n 是运行时才知道的变量,编译器保守起见放堆上
    return s
}

如果 make 的长度是编译期常量且不大,通常能留在栈上;一旦长度是变量,编译器往往判定逃逸。

一个真实的优化:值传递 vs 指针传递

很多人有个直觉「传指针快,因为不用拷贝」。但对小结构体,这个直觉常常是错的------传指针反而可能引发逃逸,得不偿失。

go 复制代码

type Point struct{ X, Y int } // 小结构体,才 16 字节

// 版本 A:传值
func sumValue(p Point) int {
    return p.X + p.Y
}

// 版本 B:传指针
func sumPointer(p *Point) int {
    return p.X + p.Y
}

func main() {
    p := Point{1, 2}
    sumValue(p)     // p 拷贝进栈,不逃逸
    sumPointer(&p)  // 取地址,可能促使 p 逃逸到堆
}

对这种十几字节的小结构体,拷贝的成本比一次堆分配 + GC 追踪低得多。经验法则:小结构体(几十字节内)优先传值;大结构体或确实要修改原值,才传指针。 别为了「省一次拷贝」把变量赶上堆。

用基准测试验证时,可以看每次操作的堆分配次数:

bash 复制代码

go test -bench=. -benchmem
# allocs/op 为 0 说明这条路径没有堆分配,逃逸被消除了

allocs/op(每次操作的分配次数)是判断有没有逃逸最直接的运行时指标,盯着它调优最靠谱。

小结

逃逸的本质:变量生命周期超出所在函数栈帧,编译器只好把它放堆上;这不是 bug,是 Go 帮你保证安全。
怎么查 :go build -gcflags="-m" 看 moved to heap / escapes to heap;go test -benchmem 看 allocs/op。
常见逃逸源 :返回指针、装进 interface(含 fmt.Println)、被闭包捕获、make 长度不定或过大。
优化方向 :小结构体传值别传指针,减少不必要的取地址;热点路径盯着 allocs/op 压到 0。
一句话记忆:变量的地址活得比函数久,它就得上堆------想省 GC,就别让局部变量的地址「漏出去」。