编程语言go语言重难点
Source
Edit
History

undefined

Go语言的内存逃逸

Golang 程序变量会携带一组校验数据，用来证明他的整个生命周期是否在运行时完全可知。如果变量通过了这些校验，他就可以在栈上分配。否则就说它逃逸了，必须在堆上分配。

一、引起变量逃逸到堆上的典型情况

  • 在方法内把局部变量指针返回，局部变量原本应该在栈中分配，在栈中回收。但是由于返回时被外部引用，因此其生命周期大于栈，则溢出。
  • 发送指针或带有指针的值到 channel 中。 在编译时，是没有办法知道哪个 goroutine 会在 channel 上接收数据。所以编译器没法知道变量什么时候才会被释放。
  • 在一个切片上存储指针或带指针的值。 一个典型的例子就是 []*string 。这会导致切片的内容逃逸。尽管其后面的数组可能是在栈上分配的，但其引用的值一定是在堆上。
  • slice 的背后数组被重新分配了，因为 append 时可能会超出其容量( cap )。 slice 初始化的地方在编译时是可以知道的，它最开始会在栈上分配。如果切片背后的存储要基于运行时的数据进行扩充，就会在堆上分配。
  • 在 interface 类型上调用方法。 在 interface 类型上调用方法都是动态调度的 —— 方法的真正实现只能在运行时知道。想像一个 io.Reader 类型的变量 r , 调用 r.Read(b) 会使得 r 的值和切片b 的背后存储都逃逸掉，所以会在堆上分配。

二、查询逃逸情况

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
package main

import "fmt"

type A struct {
    s string
}
// 这是上面提到的 "在方法内把局部变量指针返回" 的情况
func foo(s string) *A {
    a := new(A)
    a.s = s
    return a //返回局部变量a,在C语言中妥妥野指针，但在go则ok，但a会逃逸到堆
}
func main() {
    a := foo("hello")
    b := a.s + " world"
    c := b + "!"
    fmt.Println(c)
}
1
2
3
4
5
6
7
8
9
10
11
12
13
zhangyi@NOAHYZHANG-MB0 test24 % go build -gcflags=-m main.go 
# command-line-arguments
./main.go:9:6: can inline foo
./main.go:15:13: inlining call to foo
./main.go:18:16: inlining call to fmt.Println
./main.go:9:10: leaking param: s
./main.go:10:13: new(A) escapes to heap
./main.go:15:13: new(A) does not escape
./main.go:16:14: a.s + " world" does not escape
./main.go:17:12: b + "!" escapes to heap
./main.go:18:16: c escapes to heap
./main.go:18:16: []interface {} literal does not escape
<autogenerated>:1: .this does not escape

如上，我们可以看到，内存的逃逸情况。

  • ./main.go:10:13: new(A) escapes to heap ，说明 new(A) 逃逸了，也就是在方法内把局部变量的指针返回。从栈上分配的内存逃逸到堆上
  • ./main.go:16:14: a.s + " world" does not escape ，没有逃逸，因为它只在方法内存在，会在方法结束时被回收
  • ./main.go:17:12: b + "!" escapes to heap ，说明变量 c 发生了逃逸，通过 fmt.Println(...interface{}) 打印的变量，都会发生逃逸