질문
골랑의 기억탈출에 대해 아시나요? 어떤 상황에서 메모리 탈출이 발생합니까?
답변
golang 프로그램 변수
는 전체 수명 주기가 런타임에 완전히 알려져 있는지 여부를 증명하기 위해 일련의 검증 데이터를 전달합니다. 변수가 이러한 검사를 통과하면 스택
에 할당될 수 있습니다. 그렇지 않으면 escape
라고 하며 힙
에 할당되어야 합니다. golang程序变量
会携带有一组校验数据,用来证明它的整个生命周期是否在运行时完全可知。如果变量通过了这些校验,它就可以在栈上
分配。否则就说它 逃逸
了,必须在堆上分配
。
能引起变量逃逸到堆上的典型情况:
- 在方法内把局部变量指针返回 局部变量原本应该在栈中分配,在栈中回收。但是由于返回时被外部引用,因此其生命周期大于栈,则溢出。
- 发送指针或带有指针的值到 channel 中。 在编译时,是没有办法知道哪个 goroutine 会在 channel 上接收数据。所以编译器没法知道变量什么时候才会被释放。
- 在一个切片上存储指针或带指针的值。 一个典型的例子就是 []*string 。这会导致切片的内容逃逸。尽管其后面的数组可能是在栈上分配的,但其引用的值一定是在堆上。
- slice 的背后数组被重新分配了,因为 append 时可能会超出其容量( cap )。 slice 初始化的地方在编译时是可以知道的,它最开始会在栈上分配。如果切片背后的存储要基于运行时的数据进行扩充,就会在堆上分配。
- 在 interface 类型上调用方法。 在 interface 类型上调用方法都是动态调度的 —— 方法的真正实现只能在运行时知道。想像一个 io.Reader 类型的变量 r , 调用 r.Read(b) 会使得 r 的值和切片b 的背后存储都逃逸掉,所以会在堆上分配。
举例
- 通过一个例子加深理解,接下来尝试下怎么通过
go build -gcflags=-m
查看逃逸的情况。
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) }
执行go build -gcflags=-m main.go
go build -gcflags=-m main.go # command-line-arguments ./main.go:7:6: can inline foo ./main.go:13:10: inlining call to foo ./main.go:16:13: inlining call to fmt.Println /var/folders/45/qx9lfw2s2zzgvhzg3mtzkwzc0000gn/T/go-build409982591/b001/_gomod_.go:6:6: can inline init.0 ./main.go:7:10: leaking param: s ./main.go:8:10: new(A) escapes to heap ./main.go:16:13: io.Writer(os.Stdout) escapes to heap ./main.go:16:13: c escapes to heap ./main.go:15:9: b + "!" escapes to heap ./main.go:13:10: main new(A) does not escape ./main.go:14:11: main a.s + " world" does not escape ./main.go:16:13: main []interface {} literal does not escape <autogenerated>:1: os.(*File).close .this does not escape
-
./main.go:8:10: new(A) escapes to heap
说明new(A)
逃逸了,符合上述提到的常见情况中的第一种。 -
./main.go:14:11: main a.s + " world" does not escape
说明b
变量没有逃逸,因为它只在方法内存在,会在方法结束时被回收。 -
./main.go:15:9: b + "!" escapes to heap
说明c
变量逃逸,通过fmt.Println(a ...interface{})
변수가 힙으로 이스케이프될 수 있는 일반적인 상황 - :