>**關注公眾號 「程式設計師小喬」**

# 1. 從一個例子開始

下面是一段 c 程式碼，函式 getStr 生成了 a-z 的串，我們分別在函式內部和 main 中對字串進行了輸出。
```C
//例1.1
#include <stdio.h>

//返回字串
char* getStr(){
    //char陣列 函式棧上分配記憶體
    char buf[27];
    int i;

//產生a-z的串
    for (i=0; i<sizeof i="" buf="" printf="" return="" int="" main="" char="" p="getStr();" abcdefghijklmnopqrstuvwxyz="" m="" c="" in="" function="" warning:="" returns="" address="" of="" local="" variable="" malloc="">
#include <stdlib.h>

char* getStr(){
    char *buf;
    int len = 27;
    //堆上分配記憶體，不會在函式結束後被自動回收
    buf = (char *) malloc(len);

int i;
    for (i=0; i<len-1 i="" buf="" printf="" return="" int="" main="" char="" p="getStr();" free="" go="" package="" import="" func="" getstr="" byte="" :="[26]byte{}" for="" i:="0;" var="" fmt.printf="" abcdefghijklmnopqrstuvwxyz="" escape.go="" build="" command-line-arguments="" .="" inlining="" call="" to="" moved="" heap:="" escapes="" heap="" literal="" does="" not="" escape="">:1: .this does not escape
```
可見 buf 的確逃逸到了堆上。

# 4. 產生逃逸的情況

哪些情況 go 會將函式棧上的記憶體分配至堆上呢？官方的 FAQ([How do I know whether a variable is allocated on the heap or the stack?](https://golang.org/doc/faq#stack_or_heap))裡給出了答案
> When possible, the Go compilers will allocate variables that are local to a function in that function's stack frame. However, if the compiler cannot prove that the variable is not referenced after the function returns, then the compiler must allocate the variable on the garbage-collected heap to avoid dangling pointer errors. Also, if a local variable is very large, it might make more sense to store it on the heap rather than the stack.

可見逃逸的情形主要有兩大類：

* 編譯器無法證明變數在函式返回後不再被引用，則分配在堆上。

* 如果變數比較大，則放在堆上更合理。

## 4.1 函式返回後變數仍被使用的情況

1. 由於閉包，導致函式返回後函式內變數仍被外部使用。
```go
package main

func main() {
    f := fibonacci()
    f()
}

func fibonacci() func() int {
    a, b := 0, 1
    return func() int {
        a, b = b, a+b
        return a
    }
}
```
檢視逃逸情況如下：
```shell
go build -gcflags "-m -l" escape.go
# command-line-arguments
./escape.go:9:5: moved to heap: a
./escape.go:9:8: moved to heap: b
./escape.go:10:12: func literal escapes to heap
```
2. 返回指標
```go
package main

type User struct {
    name string
    age int8
}

//返回指向User的指標
func NewUser() *User{
    u := User{
        name: "ball",
        age: 99,
    }

//u對應的記憶體可能在外部被使用，放到堆上
    return &u
}

func main() {
}
```
檢視逃逸情況如下：
```shell
go build -gcflags "-m  -l" escape.go
# command-line-arguments
./escape.go:9:2: moved to heap: u
```
3. 返回介面
```go
package main

type Man interface{
    Show()
}

type User struct {
    name string
    age int8
}

func (u User)Show(){
}

func NewMan() (m Man){
    u:= User{
        name: "ball",
        age: 99,
    }

m = u

return
}

func main() {
}
```
檢視逃逸情況如下：
```shell
go build -gcflags "-m -l" escape.go
# command-line-arguments
./escape.go:12:7: u does not escape
./escape.go:21:4: u escapes to heap
<autogenerated>:1: .this does not escape
<autogenerated>:1: leaking param: .this
```
Newman 中有一個 u 到介面 m 的轉換。go 同的介面由動態值和動態型別兩部分構成，m 中的動態值指標，指向了 u(更準備的說應該是 u 的複製)對應的記憶體，這部分是可能在函式返回後會用到的，所以只能分配在堆上。

## 4.2 變數過大被分配在堆上的情況
```go
//escape.go
package main
func Slice(){
    s := make([]int64, 8192, 8192)
    s[0] = 1
}

func main() {
    Slice()
}
```
檢視逃逸情況如下：
```shell
go build -gcflags "-m -m -l" escape.go
# command-line-arguments
./escape.go:3:11: make([]int64, 8192, 8192) escapes to heap:
./escape.go:3:11:   flow: {heap} = &{storage for make([]int64, 8192, 8192)}:
./escape.go:3:11:     from make([]int64, 8192, 8192) (too large for stack) at ./escape.go:3:11
./escape.go:3:11: make([]int64, 8192, 8192) escapes to heap
```
這裡由於切片長度過大（too large for stack），被分配到了棧上。如果你的好奇心比較強，可能會有如下疑問：

* go 函式棧這麼小麼，長度是 10000 的 int64 切片都放不下？

* 這個 too large 到底是多大？

關於這些問題，準備後面寫一篇函式棧記憶體分配的文章專門說明。這裡你只要記住結論就可以。

* go 的函式棧是非常大的 32 位系統 250M，64 位系統 1G。(1.14.4 是這樣的，不確認不同版本的 go 是否完全相同)

* 這裡所說的 too large 不是函式棧的記憶體不夠，而是說一個變數如果對應這麼大塊的記憶體，把它分配在棧上的效率大機率比較低，所以放堆上更合理。

* go1.14.4 版本中，too large 是指 >= 8 位元組 * 8192。也就是說如果程式碼做如下改動，不會產生逃逸。
```go
s := make([]int64, 8191, 8191)
```
# 5. 逃逸分析可能帶來的問題

## 5.1 go 中記憶體分配在堆與棧上的不同

* 如果分配在棧中，則函式執行結束可自動將記憶體回收；

* 如果分配在堆中，則函式執行結束交給 GC（垃圾回收）處理;

## 5.2 可能的問題

由 5.1 可知，如果過多的產生逃逸，會使更多的記憶體分配在堆上，其後果是 GC 的壓力比較大，這同樣可能影響程式碼執行的效率。實際專案中需要進行權衡，以決定是否要避免逃逸。

我們看下面一個比較極端的例子：
```go
//benchmark.go
package gotest

func Slice(n int64){
    s := make([]int64, 8191, 8191)
    s[0] = 1
}
```
對應的壓測檔案
```go
//benchmark_test.go
package gotest_test

import (
    "testing"
    "gotest"
)

func BenchmarkSlice(b *testing.B){
    for i :=0; i<b.n i="" gotest.slice="" slice="" go="" test="" goos:="" linux="" goarch:="" amd64="" pkg:="" gotest="" benchmarkslice-4="" ns="" pass="" ok="" s="" :="make([]int64," package="" main="" func="" n="" build="" escape.go="" command-line-arguments="" .="" make="" escapes="" to="" heap:="" flow:="" for="" from="" size="" at="" heap="" non-constant="" type="" x="" struct="" p="" var="" i1="" int="" x1="" p:="" good:="" does="" not="" escape="" i2="" x2="" x2.p="&i2" bad:="" cause="" of="" moved="" literal="" benchmark="" flaws="" https:="">
                        </b.n></autogenerated></autogenerated></len-1></stdlib.h></sizeof></stdio.h>

從一個例子看Go的逃逸分析

相關文章