golang的fmt包引发的变量逃逸到堆的问题

问题:

fmt.Printf等函数会导致传进去的参数在编译时从栈逃逸到堆上?

golang的issue:(https://github.com/golang/go/issues/8618)

磨刀(逃逸分析工具):

分析工具:

  • 1.通过编译工具查看详细的逃逸分析过程(go build -gcflags '-m -l' main.go)
  • 2.通过反编译命令查看go tool compile -S main.go

其中 编译参数(-gcflags)介绍:

  • -N: 禁止编译优化

  • -l: 禁止内联(可以有效减少程序大小)

  • -m: 逃逸分析(最多可重复四次)

  • -benchmem: 压测时打印内存分配统计

练功(实验):

Example:

package main

import (
    "fmt"
    "runtime"
)
type obj struct{
     }
func main() {
     
    a := &obj{
     }
    fmt.Printf("%p\n", a)
    b := &obj{
     }
  	println(b)
}

逃逸分析:

./main.go:17:7: &obj literal escapes to heap
./main.go:18:12: ... argument does not escape
./main.go:20:7: &obj literal does not escape
0x11a6c10
0xc000072f1f

可以看到我们的变量a因为fmt的函数逃逸到了堆上。

干仗(尝试验证问题):

首先声明,我们只是验证了这个问题的发生,但并没有解决这个问题,有想法的同学可以直接去提交m

目前网上的解释有2个方向:

fmt.Printf等函数会导致传进去的参数在编译时从栈逃逸到堆上

第一个罪犯:

其实,fmt.Printf 的第二个参数,是一个 interface 类型,在底层的调用中用到了断言,具体的调用逻辑是:

Printf->Fprintf->doPrintf->reflect.TypeOf(arg).Kind()

这里有人通过模拟fmt包得出了初步的结论(https://reusee.github.io/post/escape_analysis/),调用interface的Type方法会导致变量被移到堆上。

所以我们可以认为a在编译阶段,编译器无法确定其具体的类型。因此会产生逃逸,最终分配到堆上(最本质的原因是interface{}类型一般情况下底层会进行reflect,而使用的reflect.TypeOf(arg).Kind()获取接口类型对象的底层数据类型时发生了堆逃逸,最终就会反映为当入参是空接口类型时发生了逃逸)。

但不是说往func(interface{})传值,或者往func(*struct)传指针就会导致逃逸分析。只是大多数场景下,其内部都会用到反射,导致逃逸(switch type不会导致逃逸)。

验证:

package main

import (
    "fmt"
    "runtime"
)
type obj struct{
     }
func main() {
     
    a := &obj{
     }
    fmt.Printf("%p\n", a)
    b := &obj{
     }
  	reflect.TypeOf(b).Kind()
		println(b)
}

逃逸分析:

# command-line-arguments
./main.go:20:7: &obj literal escapes to heap
./main.go:21:12: ... argument does not escape
./main.go:23:7: &obj literal escapes to heap
0x11a6c30
0x11a6c30

可以发现两个变量都到了堆上,至于地址为什么一摸一样,可以关注我的另一篇文章:https://www.jianshu.com/p/e0fd84a59088

第二个罪犯:

我们点进去看看fmt.Printf的源码,同样的排查链路,Printf->Fprintf->doPrintf->printArg

我们发现有这么一段赋值代码,我们传入的u被赋值给了pp指针的一个成员变量:

func (p *pp) printArg(arg interface{
     }, verb rune) {
     
      p.arg = arg
      p.value = reflect.Value{
     } 
      ...
}

而这个pp类型的指针p是由构造函数newPrinter返回的,所以他的生命周期就变了,p一定发生逃逸,而p引用了传入指针u,经测试是逃逸了。

验证

package main
import (
	"fmt"
)
type obj struct{
     }
type pointer struct {
     
	o *obj
}
func main() {
     
	a := &obj{
     }
	fmt.Printf("%p\n", a)
	b := &obj{
     }
	p := newPrinter()
	p.o = b
	println(b)
}
func newPrinter() *pointer {
     
	return new(pointer)
}

结论:

# command-line-arguments
./main.go:23:12: new(pointer) escapes to heap
./main.go:14:7: &obj literal escapes to heap   // a
./main.go:15:12: ... argument does not escape
./main.go:16:7: &obj literal escapes to heap   // b
0x11a6c10
0x11a6c10

我们看到被p引用的b也被赶到了堆上

收功(总结):

fmt.Printf等函数传入参数会发生堆逃逸。

虽然日常的开发,go已经帮我们处理了编译前的内存分配,我们也不需要关注堆栈的使用情况,但有意识的避免堆逃逸可以有效的提高负担重的服务性能。堆逃逸在go中并不罕见,并且对gc的影响带来的性能消耗也是不容小觑的。

日常经常会碰到的:

1.函数返回指向栈内对象的指针,或者说是参数泄漏,延长了指针对象的生命周期。

2.调用反射(未知类型)(fmt案例的第一个问题)。

3.被已经逃逸的变量引用的指针,一定发生逃逸(fmt案例的第二个问题)。

4.被指针类型的slice、map和chan引用的指针,一定发生逃逸。

避免逃逸的好处:
  • 1.减少gc的压力,不逃逸的对象分配在栈上,当函数返回时就回收了资源,不需要gc标记清除

  • 2.逃逸分析完后可以确定哪些变量可以分配在栈上,栈的分配比堆快,性能好(系统开销少)

  • 3.减少动态分配所造成的内存碎片

反思:

函数传递指针真的比传值效率高吗?

我们知道传递指针可以减少底层值的拷贝,可以提高效率,负担也比较小

但是当数据比较小且多的情况,由于指针传递经常会导致逃逸到堆上,会增加GC的负担,所以传递指针不一定是高效的。

example:

使用指针的chan比使用值的chan慢30%,使用指针的chan发生逃逸,gc拖慢了速度。

ps :https://stackoverflow.com/questions/41178729/why-passing-pointers-to-channel-is-slower

你可能感兴趣的:(fmt,堆逃逸,后端,golang)