【golang】内存逃逸常见情况和避免方式
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了【golang】内存逃逸常见情况和避免方式相关的知识,希望对你有一定的参考价值。
参考技术A 因为如果变量的内存发生逃逸,它的生命周期就是不可知的,其会被分配到堆上,而堆上分配内存不能像栈一样会自动释放,为了解放程序员双手,专注于业务的实现,go实现了gc垃圾回收机制,但gc会影响程序运行性能,所以要尽量减少程序的gc操作。1、在方法内把局部变量指针返回,被外部引用,其生命周期大于栈,则溢出。
2、发送指针或带有指针的值到channel,因为编译时候无法知道那个goroutine会在channel接受数据,编译器无法知道什么时候释放。
3、在一个切片上存储指针或带指针的值。比如[]*string,导致切片内容逃逸,其引用值一直在堆上。
4、因为切片的append导致超出容量,切片重新分配地址,切片背后的存储基于运行时的数据进行扩充,就会在堆上分配。
5、在interface类型上调用方法,在Interface调用方法是动态调度的,只有在运行时才知道。
1、go语言的接口类型方法调用是动态,因此不能在编译阶段确定,所有类型结构转换成接口的过程会涉及到内存逃逸发生,在频次访问较高的函数尽量调用接口。
2、不要盲目使用变量指针作为参数,虽然减少了复制,但变量逃逸的开销更大。
3、预先设定好slice长度,避免频繁超出容量,重新分配。
内存逃逸分析
问题
知道golang的内存逃逸吗?什么情况下会发生内存逃逸?
怎么答
因为函数都是运行在栈上的,在栈声明临时变量分配内存,函数运行完毕再回收该段栈空间,并且每个函数的栈空间都是独立的,其他代码都是不可访问的。但是在某些情况下,栈上的空间需要在
该函数被释放后依旧能访问到,这时候就涉及到内存的逃逸了。
能引起变量逃逸到堆上的典型情况:
- 在方法内把局部变量指针返回 局部变量原本应该在栈中分配,在栈中回收。但是由于返回时被外部引用,因此其生命周期大于栈,则溢出。
执行go build -gcflags=-m main.gotype S struct { s string } func getS(str string) *S { return &S{str} } a := getS("hello") b := a.s + " world" c := b + "!" fmt.Println(c)
./main.go:11:6: can inline getS ./main.go:16:11: inlining call to getS ./main.go:19:13: inlining call to fmt.Println ./main.go:11:11: leaking param: str ./main.go:12:9: &S literal escapes to heap 局部变量return逃逸 符合情况 ./main.go:16:11: &S literal does not escape 这里是a拿到了&S 局部变量 不逃逸 ./main.go:17:11: a.s + " world" does not escape 局部变量不逃逸 ./main.go:18:9: b + "!" escapes to heap c变量逃逸 ./main.go:19:13: c escapes to heap ./main.go:19:13: []interface {} literal does not escape
- 发送指针或带有指针的值到 channel 中。 在编译时,是没有办法知道哪个 goroutine 会在 channel 上接收数据。所以编译器没法知道变量什么时候才会被释放。
执行go build -gcflags=-m main.goch := make(chan *int, 1) a := 10 b := &a go func() { ch <- b }() go func() { select { case <-ch: return default: } }() time.Sleep(2 * time.Second)
./main.go:22:5: can inline main.func1 ./main.go:20:2: moved to heap: a ./main.go:22:5: func literal escapes to heap ./main.go:25:5: func literal escapes to heap
- 在一个切片上存储指针或带指针的值。 一个典型的例子就是 []*string 。这会导致切片的内容逃逸。尽管其后面的数组可能是在栈上分配的,但其引用的值一定是在堆上
执行go build -gcflags=-m main.gos := make([]*string, 10) a := "aaaaaa" s[0] = &a
./main.go:11:6: can inline main ./main.go:33:2: moved to heap: a 变量发生逃逸 ./main.go:32:11: make([]*string, 10) does not escape
- slice 的背后数组被重新分配了,因为 append 时可能会超出其容量( cap )。 slice 初始化的地方在编译时是可以知道的,它最开始会在栈上分配。如果切片背后的存储要基于运行时的数据进行扩充,就会在堆上分配。
- 在 interface 类型上调用方法。 在 interface 类型上调用方法都是动态调度的 —— 方法的真正实现只能在运行时知道。想像一个 io.Reader 类型的变量 r , 调用 r.Read(b) 会使得 r 的值和切片b 的背后存储都逃逸掉,所以会在堆上分配。
以上是关于【golang】内存逃逸常见情况和避免方式的主要内容,如果未能解决你的问题,请参考以下文章
"b = &boy{}" vs "*b = boy{}" 谁不讲武德?golang 逃逸分析入门
"b = &boy{}" vs "*b = boy{}" 谁不讲武德?golang 逃逸分析入门