高频golang面试题：简单聊聊内存逃逸？

た入场券 2023-01-15 03:59 113阅读 0赞

**问题**

知道golang的**内存逃逸**吗？什么情况下会发生内存逃逸？

## **怎么答** ##

`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{})`打印的变量，都会发生逃逸，感兴趣的朋友可以去查查为什么。
 *  以上操作其实就叫**逃逸分析**。**下篇文章，跟大家聊聊怎么用一个比较trick的方法使变量不逃逸。方便大家在面试官面前秀一波**。

**问题**

怎么避免**内存逃逸**？

## **怎么答** ##

在`runtime/stubs.go:133`有个函数叫`noescape`。`noescape`可以在逃逸分析中**隐藏一个指针**。让这个指针在逃逸分析中**不会被检测为逃逸**。

// noescape hides a pointer from escape analysis.  noescape is
     // the identity function but escape analysis doesn't think the
     // output depends on the input.  noescape is inlined and currently
     // compiles down to zero instructions.
     // USE CAREFULLY!
     //go:nosplit
     func noescape(p unsafe.Pointer) unsafe.Pointer {
         x := uintptr(p)
         return unsafe.Pointer(x ^ 0)
    }

## **举例** ##

*  通过一个例子加深理解，接下来尝试下怎么通过 `go build -gcflags=-m` 查看逃逸的情况。

package main
    
    import (
     "unsafe"
    )
    
    type A struct {
     S *string
    }
    
    func (f *A) String() string {
     return *f.S
    }
    
    type ATrick struct {
     S unsafe.Pointer
    }
    
    func (f *ATrick) String() string {
     return *(*string)(f.S)
    }
    
    func NewA(s string) A {
     return A{S: &s}
    }
    
    func NewATrick(s string) ATrick {
     return ATrick{S: noescape(unsafe.Pointer(&s))}
    }
    
    func noescape(p unsafe.Pointer) unsafe.Pointer {
     x := uintptr(p)
     return unsafe.Pointer(x ^ 0)
    }
    
    func main() {
     s := "hello"
     f1 := NewA(s)
     f2 := NewATrick(s)
     s1 := f1.String()
     s2 := f2.String()
     _ = s1 + s2
    }

执行`go build -gcflags=-m main.go`

$go build -gcflags=-m main.go
    # command-line-arguments
    ./main.go:11:6: can inline (*A).String
    ./main.go:19:6: can inline (*ATrick).String
    ./main.go:23:6: can inline NewA
    ./main.go:31:6: can inline noescape
    ./main.go:27:6: can inline NewATrick
    ./main.go:28:29: inlining call to noescape
    ./main.go:36:6: can inline main
    ./main.go:38:14: inlining call to NewA
    ./main.go:39:19: inlining call to NewATrick
    ./main.go:39:19: inlining call to noescape
    ./main.go:40:17: inlining call to (*A).String
    ./main.go:41:17: inlining call to (*ATrick).String
    /var/folders/45/qx9lfw2s2zzgvhzg3mtzkwzc0000gn/T/go-build763863171/b001/_gomod_.go:6:6: can inline init.0
    ./main.go:11:7: leaking param: f to result ~r0 level=2
    ./main.go:19:7: leaking param: f to result ~r0 level=2
    ./main.go:24:16: &s escapes to heap
    ./main.go:23:13: moved to heap: s
    ./main.go:27:18: NewATrick s does not escape
    ./main.go:28:45: NewATrick &s does not escape
    ./main.go:31:15: noescape p does not escape
    ./main.go:38:14: main &s does not escape
    ./main.go:39:19: main &s does not escape
    ./main.go:40:10: main f1 does not escape
    ./main.go:41:10: main f2 does not escape
    ./main.go:42:9: main s1 + s2 does not escape

其中主要看中间一小段

./main.go:24:16: &s escapes to heap    //这个是NewA中的，逃逸了
    ./main.go:23:13: moved to heap: s
    ./main.go:27:18: NewATrick s does not escape // NewATrick里的s的却没逃逸
    ./main.go:28:45: NewATrick &s does not escape

## **解释** ##

*  上段代码对`A`和`ATrick`同样的功能有两种实现：他们包含一个 `string` ，然后用 `String()`方法返回这个字符串。但是从逃逸分析看`ATrick` 版本没有逃逸。
 *  `noescape()` 函数的作用是遮蔽输入和输出的依赖关系。使编译器不认为 `p` 会通过 `x` 逃逸， 因为 `uintptr()` 产生的引用是编译器无法理解的。
 *  内置的 `uintptr` 类型是一个真正的指针类型，但是在编译器层面，它只是一个存储一个 `指针地址` 的 `int` 类型。代码的最后一行返回 `unsafe.Pointer` 也是一个 `int`。
 *  `noescape()` 在 `runtime` 包中使用 `unsafe.Pointer` 的地方被大量使用。如果作者清楚被 `unsafe.Pointer` 引用的数据肯定不会被逃逸，但编译器却不知道的情况下，这是很有用的。
 *  **面试中秀一秀是可以的**，如果在实际项目中如果使用这种unsafe包大概率会被同事打死。**不建议使用！** 毕竟包的名字就叫做 `unsafe`, 而且源码中的注释也写明了 `USE CAREFULLY!`。