go 的内存逃逸
2022-04-04 本文已影响0人
wayyyy
在C/C++ 中,例如对于局部变量的分配是在栈上,在go语言中,这是不确定的,局部变量的内存分配也许发生在堆上。
package main
var a int
func foo() *int {
a := 10
return &a // 在C++ 中,返回局部变量的指针是不安全的,但是在go中是安全的,因为发生了内存逃逸。
}
func main() {
a := *foo()
}
内存逃逸影响
变量在堆上的分配和回收都比在栈上开销大的多,对于 go 这种带 GC 的语言来说,会增加 gc 压力。
如何发现内存逃逸?
go 中逃逸分析在编译阶段完成的,在 build 时添加 -gcflags="-m -l"
选项可以看内存逃逸情况。-m
会打印出逃逸分析的优化策略。-l
禁止编译优化,这里主要是为了输出信息单一好看。
var a int
func foo() *int {
a := 10
return &a
}
func main() {
a = *foo()
}
# go build -gcflags="-m -l"
./main.go:8:5: moved to heap: a
哪些情形会发生内存逃逸?
-
返回局部变量指针或者闭包引用,因为变量的生命周期可能会超过函数周期,因此只能放入堆中。
func Foo () func (){ x := 5 // x发生逃逸,因为在Foo调用完成后,被闭包函数用到。 return func () { x += 1 } }
-
变量绑定到了堆上的变量
-
切片底层数据内存太大,逃逸到堆上
// 8191不会逃逸 s := make([]int, 8191, 8191) // 8192会逃逸 s := make([]int, 8192, 8192)
-
make 创建切片时,指定大小是非常量
func foo(size int) { a := make([]int, size) }
-
在 slice 或 map 中存储指针。比如 []*string,其后面的数组可能是在栈上分配的,但其引用的值还是在堆上。
-
向 channel 发送指针数据,因为在编译时,不知道channel中的数据会被哪个 goroutine 接收,因此编译器没法知道变量什么时候才会被释放,因此只能放入堆中。
package main func main() { ch := make(chan int, 1) x := 5 ch <- x // x不发生逃逸,因为只是复制的值 ch1 := make(chan *int, 1) y := 5 py := &y ch1 <- py // y逃逸,因为y地址传入了chan中,编译时无法确定什么时候会被接收,所以也无法在函数返回后回收y }
-
参数为interface类型,因为编译期间很难确定参数的具体类型
package main import "fmt" func main() { fmt.Print("hello world") }
编译查看输出:
# go build -gcflags="-m -l" ./main.go:7:16: ... argument does not escape ./main.go:7:17: "hello world" escapes to heap
避免内存逃逸
参考
1、https://juejin.cn/post/6952177646050639902
2、https://mp.weixin.qq.com/s/_tjDnPcdBkUpjJ80f3cGTg