通過實例理解Go逃逸分析

關(guān)于Go變量的逃逸分析，大多數(shù)Gopher其實并不用關(guān)心，甚至可以無視。但是如果你將Go應(yīng)用于性能敏感的領(lǐng)域，要完全壓榨出Go應(yīng)用的性能，那么理解Go逃逸分析就大有裨益了。在本文，我們就一起來理解一下Go的逃逸分析。

1. 逃逸分析（escape analysis）要解決的問題

C/C++語言出身的程序員^[2]對堆內(nèi)存（heap）和棧內(nèi)存（stack）都有著“涇渭分明”的理解。在操作系統(tǒng)演化出現(xiàn)進程虛擬內(nèi)存地址（virtual memory address）的概念后，如下圖所示，應(yīng)用程序的虛擬內(nèi)存地址空間就被劃分為堆內(nèi)存區(qū)（如圖中的heap）和棧內(nèi)存區(qū)（如圖中的stack）：

在x86平臺linux操作系統(tǒng)下，如上圖，一般將棧內(nèi)存區(qū)放在高地址，棧向下延伸；而堆內(nèi)存去放在低地址，堆向上延伸，這樣做的好處就是便于堆和棧可動態(tài)共享那段內(nèi)存區(qū)域。

這是否意味著所有分配在堆內(nèi)存區(qū)域的內(nèi)存對象地址一定比分配在棧內(nèi)存區(qū)域的內(nèi)存對象地址要小呢？在C/C++中是這樣的，但是在Go語言中，這是不一定的，因為go堆內(nèi)存所使用的內(nèi)存頁(page)與goroutine的棧所使用的內(nèi)存頁是交織在一起的^[3]。

無論是棧內(nèi)存還是堆內(nèi)存，對于應(yīng)用而言都是合法可用的內(nèi)存地址空間。之所以將其區(qū)分開，是因為應(yīng)用程序的內(nèi)存分配和管理的需要。

棧內(nèi)存上的對象的存儲空間是自動分配和銷毀的，無需開發(fā)人員或編程語言運行時過多參與，比如下面的這段C代碼（用C代碼更能體現(xiàn)棧內(nèi)存與堆內(nèi)存的差別）：

// github.com/bigwhite/experiments/blob/master/go-escape-analysis/c/cstack.c

#include <stdio.h>

void bar() {
 int e = 31;
 int f = 32;
 printf("e = %d\n", e);
 printf("f = %d\n", f);
}

void foo() {
 int c = 21;
 int d = 22;
 printf("c = %d\n", c);
 printf("d = %d\n", d);
}

int main() {
 int a = 11;
 int b = 12;
 printf("a = %d\n", a);
 printf("b = %d\n", b);
 foo();
 bar();
}

上面這段c程序算上main函數(shù)共有三個函數(shù)，每個函數(shù)中都有兩個整型變量，C編譯器自動為這些變量在棧內(nèi)存上分配空間，我們無需考慮它什么時候被創(chuàng)建以及何時被銷毀，我們只需在特定的作用域（其所在函數(shù)內(nèi)部）使用它即可，而無需擔(dān)心其內(nèi)存地址不合法，因此這些被分配在棧內(nèi)存上的變量也被稱為“自動變量”。但是如果將其地址返回到函數(shù)的外部，那么函數(shù)外部的代碼通過解引用而訪問這些變量時便會出錯，如下面示例：

// github.com/bigwhite/experiments/blob/master/go-escape-analysis/c/cstack_coredump.c

#include <stdio.h>
  
int *foo() {
    int c = 11;
    return &c;
}

int main() {
    int *p = foo();
    printf("the return value of foo = %d\n", *p);
}

如代碼所示，在上面這個例子中，我們將foo函數(shù)內(nèi)的自動變量c的地址通過函數(shù)返回值返回給foo函數(shù)的調(diào)用者（main）了，這樣當(dāng)我們在main函數(shù)中引用該地址輸出該變量值的時候，我們就會收到異常，比如在ubuntu上運行上述程序，我們會得到如下結(jié)果（在macos上運行，gcc會給出相同的警告，但程序運行不會dump core）：

# gcc cstack_dumpcore.c
cstack_dumpcore.c: In function ‘foo’:
cstack_dumpcore.c:5:12: warning: function returns address of local variable [-Wreturn-local-addr]
     return &c;
            ^~
# ./a.out 
Segmentation fault (core dumped)

這樣一來我們就需要一種內(nèi)存對象，可以在全局（跨函數(shù)間）合法使用，這就是堆內(nèi)存對象。但是和位于棧上的內(nèi)存對象由程序自行創(chuàng)建銷毀不同，堆內(nèi)存對象需要通過專用API手工分配和釋放，在C中對應(yīng)的分配和釋放方法就是malloc和free：

// github.com/bigwhite/experiments/blob/master/go-escape-analysis/c/cheap.c

#include <stdio.h>
#include <stdlib.h>

int *foo() {
 int *c = malloc(sizeof(int));
 *c = 12;
 return c;
}

int main() {
 int *p = foo();
 printf("the return value of foo = %d\n", *p);
 free(p);
}

在這個示例中我們使用malloc在foo函數(shù)中分配了一個堆內(nèi)存對象，并將該對象返回給main函數(shù)，main函數(shù)使用完該對象后調(diào)用了free函數(shù)手工釋放了該堆內(nèi)存塊。

顯然和自動變量相比，堆內(nèi)存對象的生命周期管理將會給開發(fā)人員帶來很大的心智負擔(dān)。為了降低這方面的心智負擔(dān)，帶有GC（垃圾回收）的編程語言出現(xiàn)了，比如Java、Go等。這些帶有GC的編程語言會對位于堆上的對象進行自動管理。當(dāng)某個對象不可達時（即沒有其對象引用它時），它將會被回收并被重用。

但GC的出現(xiàn)雖然降低了開發(fā)人員在內(nèi)存管理方面的心智負擔(dān)，但GC不是免費的，它給程序帶來的性能損耗是不可忽視的，尤其是當(dāng)堆內(nèi)存上有大量待掃描的堆內(nèi)存對象時，將會給GC帶來過大的壓力，從而使得GC占用更多本應(yīng)用于處理業(yè)務(wù)邏輯的計算和存儲資源。于是人們開始想方法盡量減少在堆上的內(nèi)存分配，可以在棧上分配的變量盡量留在棧上。

逃逸分析（escape analysis）就是在程序編譯階段根據(jù)程序代碼中的數(shù)據(jù)流，對代碼中哪些變量需要在棧上分配，哪些變量需要在堆上分配進行靜態(tài)分析的方法。一個理想的逃逸分析算法自然是能將那些人們認(rèn)為需要分配在棧上的變量盡可能保留在棧上，盡可能少的“逃逸”到堆上的算法。但這太過理想，各種語言都有自己的特殊情況，各種語言的逃逸算法的精確度實際都會受到這方面的影響。

2. Go語言的逃逸分析

Go從誕生那天^[4]起，逃逸分析就始終伴隨其左右。正如上面說到的逃逸分析的目標(biāo)，Go編譯器使用逃逸分析來決定哪些變量應(yīng)該在goroutine的棧上分配，哪些變量應(yīng)該在堆上分配。

截至目前，Go一共有兩個版本的逃逸分析實現(xiàn)，分水嶺在Go 1.13版本^[5]重寫的第二版逃逸分析^[6]，并默認(rèn)開啟，可以通過-gcflags="-m -newescape=false"恢復(fù)到使用第一版逃逸分析。之所以重寫，主要是考慮第一版代碼的可讀性和可維護性問題，新版代碼主要位于Go項目源碼的src/cmd/compile/internal/gc/escape.go中，它將逃逸分析代碼從上一版的2400多行縮減為1600多行，并作了更為完整文檔和注釋。但注意的是新版代碼在算法精確性上并沒有質(zhì)的變化。

但即便如此，經(jīng)過了這么多年的“修修補補”，Dmitry Vyukov 2015年提出的那些“Go Escape Analysis Flaws”^[7]多數(shù)已經(jīng)fix了。Go項目中內(nèi)置了對逃逸分析的詳盡的測試代碼（位于Go項目下的test/escape*.go文件中）。

在新版逃逸分析實現(xiàn)的注釋中（$GOROOT/src/cmd/compile/internal/gc/escape.go），我們可以大致了解逃逸分析的實現(xiàn)原理。注釋中的原理說明中提到了算法基于的兩個不變性：

1. 指向棧對象的指針不能存儲在堆中（pointers to stack objects cannot be stored in the heap）；
2. 指向棧對象的指針不能超過該棧對象的存活期（即指針不能在棧對象被銷毀后依舊存活）（pointers to a stack object cannot outlive that object）。

源碼注釋中也給出Go逃逸分析的大致原理和過程。Go逃逸分析的輸入是Go編譯器解析了Go源文件后所獲得的整個程序的抽象語法樹（Abstract syntax tree，AST）：

源碼解析后得到的代碼AST的Node切片為xtop：

// $GOROOT/src/cmd/compile/internal/gc/go.go
var xtop []*Node

在Main函數(shù)中，xtop被傳入逃逸分析的入口函數(shù)escapes：

// $GOROOT/src/cmd/compile/internal/gc/main.go

// Main parses flags and Go source files specified in the command-line
// arguments, type-checks the parsed Go package, compiles functions to machine
// code, and finally writes the compiled package definition to disk.
func Main(archInit func(*Arch)) {
    ... ...
    // Phase 6: Escape analysis.
    // Required for moving heap allocations onto stack,
    // which in turn is required by the closure implementation,
    // which stores the addresses of stack variables into the closure.
    // If the closure does not escape, it needs to be on the stack
    // or else the stack copier will not update it.
    // Large values are also moved off stack in escape analysis;
    // because large values may contain pointers, it must happen early.
    timings.Start("fe", "escapes")
    escapes(xtop)
    ... ...
}

下面是escapes函數(shù)的實現(xiàn)：

// $GOROOT/src/cmd/compile/internal/gc/esc.go
func escapes(all []*Node) {
    visitBottomUp(all, escapeFuncs)
}

// $GOROOT/src/cmd/compile/internal/gc/scc.go
// 強連接node - 一個數(shù)據(jù)結(jié)構(gòu)
func visitBottomUp(list []*Node, analyze func(list []*Node, recursive bool)) {
    var v bottomUpVisitor
    v.analyze = analyze
    v.nodeID = make(map[*Node]uint32)
    for _, n := range list {
        if n.Op == ODCLFUNC && !n.Func.IsHiddenClosure() {
            v.visit(n)
        }
    }
}

// $GOROOT/src/cmd/compile/internal/gc/escape.go

// escapeFuncs performs escape analysis on a minimal batch of
// functions.
func escapeFuncs(fns []*Node, recursive bool) {
    for _, fn := range fns {
        if fn.Op != ODCLFUNC {
            Fatalf("unexpected node: %v", fn)
        }
    }

    var e Escape
    e.heapLoc.escapes = true

    // Construct data-flow graph from syntax trees.
    for _, fn := range fns {
        e.initFunc(fn)
    }
    for _, fn := range fns {
        e.walkFunc(fn)
    }
    e.curfn = nil

    e.walkAll()
    e.finish(fns)
}

根據(jù)注釋，escapes的大致原理是(直譯)：

• 首先，構(gòu)建一個有向加權(quán)圖，其中頂點(稱為"location"，由gc.EscLocation表示)代表由語句和表達式分配的變量，而邊(gc.EscEdge)代表變量之間的賦值(權(quán)重代表尋址/取地址次數(shù))。
• 接下來，遍歷(visitBottomUp)該有向加權(quán)圖，在圖中尋找可能違反上述兩個不變量條件的賦值路徑。違反上述不變量的賦值路徑。如果一個變量v的地址是儲存在堆或其他可能會超過它的存活期的地方，那么v就會被標(biāo)記為需要在堆上分配。
• 為了支持函數(shù)間的分析，算法還記錄了從每個函數(shù)的參數(shù)到堆的數(shù)據(jù)流以及到其結(jié)果的數(shù)據(jù)流。算法將這些信息稱為“參數(shù)標(biāo)簽(parameter tag)”。這些標(biāo)簽信息在靜態(tài)調(diào)用時使用，以改善對函數(shù)參數(shù)的逃逸分析。

當(dāng)然即便看到這，你可能依舊一頭霧水，沒關(guān)系，這里不是講解逃逸分析原理，如果想了解原理，那就請認(rèn)真閱讀那2400多行代碼。

注：有一點需要明確，那就是靜態(tài)逃逸分析也無法確定的對象會被放置在堆上，后續(xù)精確的GC會處理這些對象，這樣最大程度保證了代碼的安全性。

3. Go逃逸分析的示例

Go工具鏈提供了查看逃逸分析過程的方法，我們可以通過在-gcflags中使用-m來讓Go編譯器輸出逃逸分析的過程，下面是一些典型的示例。

1) 簡單原生類型變量的逃逸分析

我們來看一個原生整型變量的逃逸分析過程，下面是示例的代碼：

// github.com/bigwhite/experiments/blob/master/go-escape-analysis/go/int.go
     1 package main
     2 
     3 import "testing"
     4 
     5 func foo() {
     6  a := 11
     7  p := new(int)
     8  *p = 12
     9  println("addr of a is", &a)
    10  println("addr that p point to is", p)
    11 }
    12 
    13 func bar() (*int, *int) {
    14  m := 21
    15  n := 22
    16  println("addr of m is", &m)
    17  println("addr of n is", &n)
    18  return &m, &n
    19 }
    20 
    21 func main() {
    22  println(int(testing.AllocsPerRun(1, foo)))
    23  println(int(testing.AllocsPerRun(1, func() {
    24   bar()
    25  })))
    26 }

我們通過-gcflags "-m -l"來執(zhí)行逃逸分析，之所以傳入-l是為了關(guān)閉inline，屏蔽掉inline對這個過程以及最終代碼生成的影響：

// go 1.16版本 on MacOS
$go build -gcflags "-m -l" int.go
# command-line-arguments
./int.go:7:10: new(int) does not escape
./int.go:14:2: moved to heap: m
./int.go:15:2: moved to heap: n
./int.go:23:38: func literal does not escape

逃逸分析的結(jié)果與我們手工分析的一致：函數(shù)bar中的m、n逃逸到heap(對應(yīng)上面輸出的有moved to heap: xx字樣的行)，這兩個變量將在heap上被分配存儲空間。而函數(shù)foo中的a以及指針p指向的內(nèi)存塊都在棧上分配（即便我們是調(diào)用的new創(chuàng)建的int對象，Go中new出來的對象可不一定分配在堆上，逃逸分析的輸出日志中還專門提及new(int)沒有逃逸）。我們執(zhí)行一下該示例（執(zhí)行時同樣傳入-l關(guān)閉inline）：

$go run -gcflags "-l" int.go  
addr of a is 0xc000074860
addr that p point to is 0xc000074868
addr of a is 0xc000074860
addr that p point to is 0xc000074868
0
addr of m is 0xc0000160e0
addr of n is 0xc0000160e8
addr of m is 0xc0000160f0
addr of n is 0xc0000160f8
2

首先，我們看到未逃逸的a和p指向的內(nèi)存塊的地址區(qū)域在0xc000074860~0xc000074868；而逃逸的m和n被分配到了堆內(nèi)存空間，從輸出的結(jié)果來看在0xc0000160e0~0xc0000160e8。我們可以明顯看到這是兩塊不同的內(nèi)存地址空間；另外通過testing包的AllocsPerRun的輸出，我們同樣印證了函數(shù)bar中執(zhí)行了兩次堆內(nèi)存分配動作。

我們再來看看這個代碼對應(yīng)的匯編代碼：

$go tool compile -S int.go |grep new   
 0x002c 00044 (int.go:14) CALL runtime.newobject(SB)
 0x004d 00077 (int.go:15) CALL runtime.newobject(SB)
 rel 45+4 t=8 runtime.newobject+0
 rel 78+4 t=8 runtime.newobject+0

我們看到在對應(yīng)源碼的14和15行，匯編調(diào)用了runtime.newobject在堆上執(zhí)行了內(nèi)存分配動作，這恰是逃逸的m和n聲明的位置。從下面newobject代碼的實現(xiàn)我們也能看到，它實際上在gc管理的內(nèi)存上執(zhí)行了malloc動作：

// $GOROOT/src/runtime/malloc.go

// implementation of new builtin
// compiler (both frontend and SSA backend) knows the signature
// of this function
func newobject(typ *_type) unsafe.Pointer {
    return mallocgc(typ.size, typ, true)
}

2) 切片變量自身和切片元素的逃逸分析

了解過切片實現(xiàn)原理^[8]的gopher都知道，切片變量實質(zhì)上是一個三元組：

//$GOROOT/src/runtime/slice.go

type slice struct {
    array unsafe.Pointer
    len   int
    cap   int
}

其中這個三元組的第一個字段array指向的是切片底層真正存儲元素的指針。這樣當(dāng)為一個切片變量分配內(nèi)存時，便既要考慮切片本身(即上面的slice結(jié)構(gòu)體)在哪里分配，也要考慮切片元素的存儲在哪里分配。我們看下面示例：

// github.com/bigwhite/experiments/blob/master/go-escape-analysis/go/slice.go

     1 package main
     2 
     3 import (
     4  "reflect"
     5  "unsafe"
     6 )
     7 
     8 func noEscapeSliceWithDataInHeap() {
     9  var sl []int
    10  println("addr of local(noescape, data in heap) slice = ", &sl)
    11  printSliceHeader(&sl)
    12  sl = append(sl, 1)
    13  println("append 1")
    14  printSliceHeader(&sl)
    15  println("append 2")
    16  sl = append(sl, 2)
    17  printSliceHeader(&sl)
    18  println("append 3")
    19  sl = append(sl, 3)
    20  printSliceHeader(&sl)
    21  println("append 4")
    22  sl = append(sl, 4)
    23  printSliceHeader(&sl)
    24 }
    25 
    26 func noEscapeSliceWithDataInStack() {
    27  var sl = make([]int, 0, 8)
    28  println("addr of local(noescape, data in stack) slice = ", &sl)
    29  printSliceHeader(&sl)
    30  sl = append(sl, 1)
    31  println("append 1")
    32  printSliceHeader(&sl)
    33  sl = append(sl, 2)
    34  println("append 2")
    35  printSliceHeader(&sl)
    36 }
    37 
    38 func escapeSlice() *[]int {
    39  var sl = make([]int, 0, 8)
    40  println("addr of local(escape) slice = ", &sl)
    41  printSliceHeader(&sl)
    42  sl = append(sl, 1)
    43  println("append 1")
    44  printSliceHeader(&sl)
    45  sl = append(sl, 2)
    46  println("append 2")
    47  printSliceHeader(&sl)
    48  return &sl
    49 }
    50 
    51 func printSliceHeader(p *[]int) {
    52  ph := (*reflect.SliceHeader)(unsafe.Pointer(p))
    53  println("slice data =", unsafe.Pointer(ph.Data))
    54 }
    55 
    56 func main() {
    57  noEscapeSliceWithDataInHeap()
    58  noEscapeSliceWithDataInStack()
    59  escapeSlice()
    60 }

對上述示例運行逃逸分析：

$go build -gcflags "-m -l" slice.go
# command-line-arguments
./slice.go:51:23: p does not escape
./slice.go:27:15: make([]int, 0, 8) does not escape
./slice.go:39:6: moved to heap: sl
./slice.go:39:15: make([]int, 0, 8) escapes to heap

我們從輸出的信息中看到：

• 位于39行的escapeSlice函數(shù)中的sl逃逸到堆上了；
• 位于39行的escapeSlice函數(shù)中的切片sl的元素也逃逸到堆上了；
• 位于27行的切片sl的元素沒有逃逸。

由于很難看到三個函數(shù)中各個切片的元素是否逃逸，我們通過運行該示例來看一下：

$go run -gcflags " -l" slice.go
addr of local(noescape, data in heap) slice =  0xc00006af48
slice data = 0x0
append 1
slice data = 0xc0000160c0
append 2
slice data = 0xc0000160d0
append 3
slice data = 0xc0000140c0
append 4
slice data = 0xc0000140c0

addr of local(noescape, data in stack) slice =  0xc00006af48
slice data = 0xc00006af08
append 1
slice data = 0xc00006af08
append 2
slice data = 0xc00006af08

addr of local(escape) slice =  0xc00000c030
slice data = 0xc00001a100
append 1
slice data = 0xc00001a100
append 2
slice data = 0xc00001a100

注：我們利用reflect包的SliceHeader輸出切片三元組中的代表底層數(shù)組地址的字段，這里是slice data。

我們看到：

• 第一個函數(shù)noEscapeWithDataInHeap聲明了一個空slice，并在后面使用append向切片附加元素。從輸出結(jié)果來看，slice自身是分配在棧上的，但是運行時在動態(tài)擴展切片時，選擇了將其元素存儲在heap上；
• 第二個函數(shù)noEscapeWithDataInStack直接初始化了一個包含8個元素存儲空間的切片，切片自身沒有逃逸，并且在附加(append)的元素個數(shù)小于等于8個的時候，元素直接使用了為其分配的棧空間；但如果附加的元素超過8個，那么運行時會在堆上分配一個更大的空間并將原棧上的8個元素復(fù)制過去，后續(xù)該切片的元素就都存儲在了堆上。這也是為什么強烈建議在創(chuàng)建 slice 時帶上預(yù)估的cap參數(shù)的原因^[9]，不僅減少了堆內(nèi)存的頻繁分配，在切片變量未逃逸的情況下，在cap容量之下，所有元素都分配在棧上，這將提升運行性能。
• 第三個函數(shù)escapeSlice則是切片變量自身以及其元素的存儲都在堆上。

3) fmt.Printf系列函數(shù)讓變量逃逸到堆(heap)上了？

很多人在go項目的issue中反饋fmt.Printf系列函數(shù)讓變量逃逸到堆上了，情況真的是這樣么？我們通過下面示例來看一下：

// github.com/bigwhite/experiments/blob/master/go-escape-analysis/go/printf1.go
     1 package main
     2 
     3 import "fmt"
     4 
     5 func foo() {
     6  var a int = 66666666
     7  var b int = 77
     8  fmt.Printf("a = %d\n", a)
     9  println("addr of a in foo =", &a)
    10  println("addr of b in foo =", &b)
    11 }
    12 
    13 func main() {
    14  foo()
    15 }

注：println和print兩個預(yù)定義函數(shù)并沒有像fmt.Printf系列函數(shù)的“副作用”，不會影響變量的逃逸性。所以這里使用println來輸出變量的實際分配內(nèi)存地址。

對上面的代碼運行逃逸分析：

$go build -gcflags "-m -l" printf1.go
# command-line-arguments
./printf1.go:8:12: ... argument does not escape
./printf1.go:8:13: a escapes to heap

我們看到逃逸分析輸出第8行的變量“a escapes to heap”，不過這個“逃逸”有些奇怪，因為按照之前的經(jīng)驗，如果某個變量真實逃逸了，那么逃逸分析會在其聲明的那行輸出：“moved to heap: xx”字樣。而上面這個輸出既不是在變量聲明的那一行，也沒有輸出“moved to heap: a”字樣，變量a真的逃逸了么？我們運行一下上面示例，看看變量a的地址究竟是在堆上還是棧上：

$go run -gcflags "-l" printf1.go  
a = 66666666
addr of a in foo = 0xc000092f50
addr of b in foo = 0xc000092f48

我們看到變量a的地址與未逃逸的變量b的地址都在同一個棧空間，變量a并未逃逸！如果你反編譯為匯編，你肯定也看不到runtime.newobject的調(diào)用。

那么“./printf1.go:8:13: a escapes to heap”這句的含義究竟是什么呢？顯然逃逸分析在這一行是對進入fmt.Printf的數(shù)據(jù)流的分析，我們修改一下go標(biāo)準(zhǔn)庫源碼，然后build -a重新編譯一下printf1.go^[10]，看看在fmt.Printf內(nèi)部變量的分布情況：

// $GOROOT/src/fmt/print.go

func Printf(format string, a ...interface{}) (n int, err error) { 
    // 添加下面四行代碼
    for i := 0; i < len(a); i++ { 
        println(a[i])
        println(&a[i])
    } 
    return Fprintf(os.Stdout, format, a...)
}

重新編譯printf1.go并運行編譯后的可執(zhí)行文件(為了避免)：

$go build -a -gcflags "-l" printf1.go
$./printf1
(0x10af200,0xc0000160c8)
0xc00006cf58
a = 66666666
addr of a in foo = 0xc00006cf50
addr of b in foo = 0xc00006cf48

我們看到fmt.Printf的實參a在傳入后被裝箱到一個interface{}類型的形參變量中，而這個形參變量自身則是被分配在棧上的（0xc00006cf58），而通過println輸出的該interface{}類型形參變量的類型部分和值部分分別指向0x10af200和0xc0000160c8。顯然值部分是在堆內(nèi)存上分配的。那么“./printf1.go:8:13: a escapes to heap”是否指的是裝箱后的值部分在堆上分配呢？這里也不確定。

我們再來看一個例子來對比一下：

// github.com/bigwhite/experiments/blob/master/go-escape-analysis/go/printf2.go
     1 package main
     2 
     3 import "fmt"
     4 
     5 func foo() {
     6  var a int = 66666666
     7  var b int = 77
     8  fmt.Printf("addr of a in bar = %p\n", &a)
     9  println("addr of a in bar =", &a)
    10  println("addr of b in bar =", &b)
    11 }
    12 
    13 func main() {
    14  foo()
    15 }

在printf2.go這個例子中，與printf1.go不同的是我們在foo函數(shù)中使用fmt.Printf輸出的是變量a的地址：&a。我們運行一下新版逃逸分析：

// go 1.16

$go build -gcflags "-m -l" printf2.go
# command-line-arguments
./printf2.go:6:6: moved to heap: a
./printf2.go:8:12: ... argument does not escape

我們看到位于第6行聲明的變量a居然真的逃逸到了堆上。我們運行一下printf2.go：

$go build -a -gcflags "-l" printf2.go 
$./printf2
(0x10ab4a0,0xc0000160c8)
0xc00006cf58
addr of a in bar = 0xc0000160c8
addr of a in bar = 0xc0000160c8
addr of b in bar = 0xc00006cf48

我們看到變量a的地址果然與位于棧上的變量b相差很大，應(yīng)該就是在堆上，那么這樣看那些在go項目中提issue的gopher所言不虛。變量a的地址以實參的形式傳入fmt.Printf后被裝箱到一個interface{}形參變量中，而從結(jié)果來看，fmt.Printf真的要求裝箱的形參變量的值部分要在堆上分配，但根據(jù)逃逸分析不變性，堆上的對象不能存儲一個棧上的地址，而這次存儲的是a的地址，于是將a判定為逃逸，于是a自身也就被分配到了堆上(0xc0000160c8)。

我們用go 1.12.7運行一下老版的逃逸分析：

// go 1.12.7
$go build -gcflags "-m -l" printf2.go
# command-line-arguments
./printf2.go:8:40: &a escapes to heap
./printf2.go:8:40: &a escapes to heap
./printf2.go:6:6: moved to heap: a
./printf2.go:8:12: foo ... argument does not escape
./printf2.go:9:32: foo &a does not escape
./printf2.go:10:32: foo &b does not escape

老版的逃逸分析給出了更詳細的輸出，比如：“&a escapes to heap”，其所指想必就是&a被裝箱到堆內(nèi)存上；而println輸出&a則無需&a被裝箱。但此后對變量a的最終判定為逃逸。

Go核心團隊成員Keith Randall^[11]對逃逸分析輸出的日志給過一個解釋^[12]，大致意思是：當(dāng)逃逸分析輸出“b escapes to heap”時，意思是指存儲在b中的值逃逸到堆上了(當(dāng)b為指針變量時才有意義），即任何被b引用的對象必須分配在堆上，而b自身則不需要；如果b自身也逃逸到堆上，那么逃逸分析會輸出“&b escapes to heap”。

這個問題目前已經(jīng)沒有fix，其核心問題在8618這個issue^[13]中。

5. 手動強制避免逃逸

對于printf2.go中的例子，我們確定一定以及肯定：a不需要逃逸。但若使用fmt.Printf，我們無法阻攔a的逃逸。那是否有一種方法可以干擾逃逸分析，使逃逸分析認(rèn)為需要在堆上分配的內(nèi)存對象而我們確定認(rèn)為不需要逃逸的對象避免逃逸呢？在Go運行時代碼中，我們發(fā)現(xiàn)了一個函數(shù)：

// $GOROOT/src/runtime/stubs.go
func noescape(p unsafe.Pointer) unsafe.Pointer {
    x := uintptr(p)
    return unsafe.Pointer(x ^ 0) // 任何數(shù)值與0的異或都是原數(shù)
}

并且在Go標(biāo)準(zhǔn)庫和運行時實現(xiàn)中，該函數(shù)得到大量使用。該函數(shù)的實現(xiàn)邏輯使得我們傳入的指針值與其返回的指針值是一樣的。該函數(shù)只是通過uintptr做了一次轉(zhuǎn)換，而這次轉(zhuǎn)換將指針轉(zhuǎn)換成了數(shù)值，這“切斷”了逃逸分析的數(shù)據(jù)流跟蹤，導(dǎo)致傳入的指針避免逃逸。

我們看一下下面例子：

// github.com/bigwhite/experiments/blob/master/go-escape-analysis/go/printf3.go
package main

import (
 "fmt"
 "unsafe"
)

func noescape(p unsafe.Pointer) unsafe.Pointer {
 x := uintptr(p)
 return unsafe.Pointer(x ^ 0)
}

func foo() {
 var a int = 66666666
 var b int = 77
 fmt.Printf("addr of a in bar = %p\n", (*int)(noescape(unsafe.Pointer(&a))))
 println("addr of a in bar =", &a)
 println("addr of b in bar =", &b)
}

func main() {
 foo()
}

對該代碼實施統(tǒng)一分析：

$go build -gcflags "-m -l" printf3.go

# command-line-arguments
./printf3.go:8:15: p does not escape
./printf3.go:16:12: ... argument does not escape

我們看到a這次沒有逃逸。運行一下編譯后的可執(zhí)行文件：

$./printf3
(0x10ab4c0,0xc00009af50)
0xc00009af58
addr of a in bar = 0xc00009af50
addr of a in bar = 0xc00009af50
addr of b in bar = 0xc00009af48

我們看到a沒有像printf2.go那樣被放在堆上，這次和b一樣都是在棧上分配的。并且在fmt.Printf執(zhí)行的過程中a的棧地址始終是有效的。

曾有一篇通過逃逸分析優(yōu)化性能的論文^[14]《Escape from Escape Analysis of Golang》使用的就是上述noescape函數(shù)的思路，有興趣的童鞋可以自行下載閱讀。

6. 小結(jié)

通過這篇文章，我們了解到了逃逸分析要解決的問題、Go逃逸分析的現(xiàn)狀與簡單原理、一些Go逃逸分析的實例以及對逃逸分析輸出日志的說明。最后，我們給出一個強制避開逃逸分析的方案，但要謹(jǐn)慎使用。

日常go開發(fā)過程，絕大多數(shù)情況無需考慮逃逸分析，除非性能敏感的領(lǐng)域。在這些領(lǐng)域，對系統(tǒng)執(zhí)行熱點路徑做一次逃逸分析以及相應(yīng)的優(yōu)化，可能回帶來程序性能的一定提升。

本文涉及的源碼可以在這里^[15]下載：https://github.com/bigwhite/experiments/blob/master/go-escape-analysis

參考資料