當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

通过实例理解 Go 逃逸分析

發布時間：2024/4/11 编程问答 27 豆豆

生活随笔收集整理的這篇文章主要介紹了通过实例理解 Go 逃逸分析小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

本文轉載自白明老師，這是中文社區里面最好、最全面的一篇關于逃逸分析的文章，寫得非常好。既有理論、又有實踐，引經據典，精彩至及。

翻看了一下自己的Go文章歸檔^[1]，發現自己從未專門寫過有關Go逃逸分析（escape analysis）的文章。關于Go變量的逃逸分析，大多數Gopher其實并不用關心，甚至可以無視。但是如果你將Go應用于性能敏感的領域，要完全壓榨出Go應用的性能，那么理解Go逃逸分析就大有裨益了。在本文，我們就一起來理解一下Go的逃逸分析。

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

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

圖：一個進程的虛擬內存地址空間（圖來自https://dave.cheney.net/2014/06/07/five-things-that-make-go-fast）

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

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

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

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

//?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函數共有三個函數，每個函數中都有兩個整型變量，C編譯器自動為這些變量在棧內存上分配空間，我們無需考慮它什么時候被創建以及何時被銷毀，我們只需在特定的作用域（其所在函數內部）使用它即可，而無需擔心其內存地址不合法，因此這些被分配在棧內存上的變量也被稱為“自動變量”。但是如果將其地址返回到函數的外部，那么函數外部的代碼通過解引用而訪問這些變量時便會出錯，如下面示例：

//?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函數內的自動變量c的地址通過函數返回值返回給foo函數的調用者（main）了，這樣當我們在main函數中引用該地址輸出該變量值的時候，我們就會收到異常，比如在ubuntu上運行上述程序，我們會得到如下結果（在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)

這樣一來我們就需要一種內存對象，可以在全局（跨函數間）合法使用，這就是堆內存對象。但是和位于棧上的內存對象由程序自行創建銷毀不同，堆內存對象需要通過專用API手工分配和釋放，在C中對應的分配和釋放方法就是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函數中分配了一個堆內存對象，并將該對象返回給main函數，main函數使用完該對象后調用了free函數手工釋放了該堆內存塊。

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

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

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

2. Go語言的逃逸分析

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

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

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

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

指向棧對象的指針不能存儲在堆中（pointers to stack objects cannot be stored in the heap）；

指向棧對象的指針不能超過該棧對象的存活期（即指針不能在棧對象被銷毀后依舊存活）（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函數中，xtop被傳入逃逸分析的入口函數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函數的實現：

//?$GOROOT/src/cmd/compile/internal/gc/esc.go func?escapes(all?[]*Node)?{visitBottomUp(all,?escapeFuncs) }//?$GOROOT/src/cmd/compile/internal/gc/scc.go //?強連接node?-?一個數據結構 func?visitBottomUp(list?[]*Node,?analyze?func(list?[]*Node,?recursive?bool))?{var?v?bottomUpVisitorv.analyze?=?analyzev.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?Escapee.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?=?nile.walkAll()e.finish(fns) }

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

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

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

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

3. Go逃逸分析的示例

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

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

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

//?github.com/bigwhite/experiments/blob/master/go-escape-analysis/go/int.go1?package?main2?3?import?"testing"4?5?func?foo()?{6??a?:=?117??p?:=?new(int)8??*p?=?129??println("addr?of?a?is",?&a)10??println("addr?that?p?point?to?is",?p)11?}12?13?func?bar()?(*int,?*int)?{14??m?:=?2115??n?:=?2216??println("addr?of?m?is",?&m)17??println("addr?of?n?is",?&n)18??return?&m,?&n19?}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"來執行逃逸分析，之所以傳入-l是為了關閉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

逃逸分析的結果與我們手工分析的一致：函數bar中的m、n逃逸到heap(對應上面輸出的有moved to heap: xx字樣的行)，這兩個變量將在heap上被分配存儲空間。而函數foo中的a以及指針p指向的內存塊都在棧上分配（即便我們是調用的new創建的int對象，Go中new出來的對象可不一定分配在堆上，逃逸分析的輸出日志中還專門提及new(int)沒有逃逸）。我們執行一下該示例（執行時同樣傳入-l關閉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指向的內存塊的地址區域在0xc000074860~0xc000074868；而逃逸的m和n被分配到了堆內存空間，從輸出的結果來看在0xc0000160e0~0xc0000160e8。我們可以明顯看到這是兩塊不同的內存地址空間；另外通過testing包的AllocsPerRun的輸出，我們同樣印證了函數bar中執行了兩次堆內存分配動作。

我們再來看看這個代碼對應的匯編代碼：

$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+0rel?78+4?t=8?runtime.newobject+0

我們看到在對應源碼的14和15行，匯編調用了runtime.newobject在堆上執行了內存分配動作，這恰是逃逸的m和n聲明的位置。從下面newobject代碼的實現我們也能看到，它實際上在gc管理的內存上執行了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) 切片變量自身和切片元素的逃逸分析

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

//$GOROOT/src/runtime/slice.gotype?slice?struct?{array?unsafe.Pointerlen???intcap???int }

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

//?github.com/bigwhite/experiments/blob/master/go-escape-analysis/go/slice.go1?package?main2?3?import?(4??"reflect"5??"unsafe"6?)7?8?func?noEscapeSliceWithDataInHeap()?{9??var?sl?[]int10??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?&sl49?}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函數中的sl逃逸到堆上了；
位于39行的escapeSlice函數中的切片sl的元素也逃逸到堆上了；
位于27行的切片sl的元素沒有逃逸。

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

$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?=?0xc0000140c0addr?of?local(noescape,?data?in?stack)?slice?=??0xc00006af48 slice?data?=?0xc00006af08 append?1 slice?data?=?0xc00006af08 append?2 slice?data?=?0xc00006af08addr?of?local(escape)?slice?=??0xc00000c030 slice?data?=?0xc00001a100 append?1 slice?data?=?0xc00001a100 append?2 slice?data?=?0xc00001a100

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

我們看到：

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

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

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

//?github.com/bigwhite/experiments/blob/master/go-escape-analysis/go/printf1.go1?package?main2?3?import?"fmt"4?5?func?foo()?{6??var?a?int?=?666666667??var?b?int?=?778??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兩個預定義函數并沒有像fmt.Printf系列函數的“副作用”，不會影響變量的逃逸性。所以這里使用println來輸出變量的實際分配內存地址。

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

$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”，不過這個“逃逸”有些奇怪，因為按照之前的經驗，如果某個變量真實逃逸了，那么逃逸分析會在其聲明的那行輸出：“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的調用。

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

//?$GOROOT/src/fmt/print.gofunc?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并運行編譯后的可執行文件(為了避免)：

$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。顯然值部分是在堆內存上分配的。那么“./printf1.go:8:13: a escapes to heap”是否指的是裝箱后的值部分在堆上分配呢？這里也不確定。

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

//?github.com/bigwhite/experiments/blob/master/go-escape-analysis/go/printf2.go1?package?main2?3?import?"fmt"4?5?func?foo()?{6??var?a?int?=?666666667??var?b?int?=?778??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函數中使用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相差很大，應該就是在堆上，那么這樣看那些在go項目中提issue的gopher所言不虛。變量a的地址以實參的形式傳入fmt.Printf后被裝箱到一個interface{}形參變量中，而從結果來看，fmt.Printf真的要求裝箱的形參變量的值部分要在堆上分配，但根據逃逸分析不變性，堆上的對象不能存儲一個棧上的地址，而這次存儲的是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被裝箱到堆內存上；而println輸出&a則無需&a被裝箱。但此后對變量a的最終判定為逃逸。

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

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

5. 手動強制避免逃逸

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

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

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

我們看一下下面例子：

//?github.com/bigwhite/experiments/blob/master/go-escape-analysis/go/printf3.go package?mainimport?("fmt""unsafe" )func?noescape(p?unsafe.Pointer)?unsafe.Pointer?{x?:=?uintptr(p)return?unsafe.Pointer(x?^?0) }func?foo()?{var?a?int?=?66666666var?b?int?=?77fmt.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() }

對該代碼實施統一分析：

$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這次沒有逃逸。運行一下編譯后的可執行文件：

$./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執行的過程中a的棧地址始終是有效的。

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

6. 小結

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

日常go開發過程，絕大多數情況無需考慮逃逸分析，除非性能敏感的領域。在這些領域，對系統執行熱點路徑做一次逃逸分析以及相應的優化，可能回帶來程序性能的一定提升。

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

“Gopher部落”知識星球正式轉正（從試運營星球變成了正式星球）！“gopher部落”旨在打造一個精品Go學習和進階社群！高品質首發Go技術文章，“三天”首發閱讀權，每年兩期Go語言發展現狀分析，每天提前1小時閱讀到新鮮的Gopher日報，網課、技術專欄、圖書內容前瞻，六小時內必答保證等滿足你關于Go語言生態的所有需求！部落目前雖小，但持續力很強。在2021年上半年，部落將策劃兩個專題系列分享，并且是部落獨享哦：

Go技術書籍的書摘和讀書體會系列
Go與eBPF系列

歡迎大家加入！

Go技術專欄“改善Go語?編程質量的50個有效實踐^[16]”正在慕課網火熱熱銷中！本專欄主要滿足廣大gopher關于Go語言進階的需求，圍繞如何寫出地道且高質量Go代碼給出50條有效實踐建議，上線后收到一致好評！歡迎大家訂閱！

我的網課“Kubernetes實戰：高可用集群搭建、配置、運維與應用^[17]”在慕課網熱賣中，歡迎小伙伴們訂閱學習！

我愛發短信^[18]：企業級短信平臺定制開發專家 https://51smspush.com/。smspush : 可部署在企業內部的定制化短信平臺，三網覆蓋，不懼大并發接入，可定制擴展；短信內容你來定，不再受約束, 接口豐富，支持長短信，簽名可選。2020年4月8日，中國三大電信運營商聯合發布《5G消息白皮書》，51短信平臺也會全新升級到“51商用消息平臺”，全面支持5G RCS消息。

著名云主機服務廠商DigitalOcean發布最新的主機計劃，入門級Droplet配置升級為：1 core CPU、1G內存、25G高速SSD，價格5$/月。有使用DigitalOcean需求的朋友，可以打開這個鏈接地址^[19]：https://m.do.co/c/bff6eed92687 開啟你的DO主機之路。

Gopher Daily(Gopher每日新聞)歸檔倉庫 - https://github.com/bigwhite/gopherdaily

我的聯系方式：

微博：https://weibo.com/bigwhite20xx
微信公眾號：iamtonybai
博客：tonybai.com
github: https://github.com/bigwhite
“Gopher部落”知識星球：https://public.zsxq.com/groups/51284458844544

商務合作方式：撰稿、出書、培訓、在線課程、合伙創業、咨詢、廣告合作。

參考資料

[1]?

Go文章歸檔:?https://tonybai.com/tag/go

[2]?

C/C++語言出身的程序員:?https://tonybai.com/tag/c

[3]?

go堆內存所使用的內存頁(page)與goroutine的棧所使用的內存頁是交織在一起的:?https://github.com/golang/go/issues/30554#issuecomment-469141498

[4]?

Go從誕生那天:?https://www.imooc.com/read/87/article/2320

[5]?

Go 1.13版本:?https://mp.weixin.qq.com/s/Txqvanb17LYQYgohNiUHig

[6]?

第二版逃逸分析:?https://github.com/golang/go/issues/23109

[7]?

“Go Escape Analysis Flaws”:?https://docs.google.com/document/d/1CxgUBPlx9iJzkz9JWkb6tIpTe5q32QDmz8l0BouG0Cw/preview#

[8]?

切片實現原理:?https://www.imooc.com/read/87/article/2383

[9]?

為什么強烈建議在創建 slice 時帶上預估的cap參數的原因:?https://www.imooc.com/read/87/article/2383

[10]?

build -a重新編譯一下printf1.go:?https://www.imooc.com/read/87/article/2387

[11]?

Keith Randall:?https://github.com/randall77

[12]?

解釋:?https://github.com/golang/go/issues/30554#issuecomment-469117368

[13]?

8618這個issue:?https://github.com/golang/go/issues/8618

[14]?

通過逃逸分析優化性能的論文:?http://www.wingtecher.com/themes/WingTecherResearch/assets/papers/ICSE20.pdf

[15]?

這里:?https://github.com/bigwhite/experiments/blob/master/go-escape-analysis

[16]?

改善Go語?編程質量的50個有效實踐:?https://www.imooc.com/read/87

[17]?

Kubernetes實戰：高可用集群搭建、配置、運維與應用:?https://coding.imooc.com/class/284.html

[18]?

我愛發短信:?https://51smspush.com/

[19]?

鏈接地址:?https://m.do.co/c/bff6eed92687

總結

以上是生活随笔為你收集整理的通过实例理解 Go 逃逸分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。

实例

上一篇：使用 litmus 验证内存重排
下一篇： Go gomaxprocs 调高引起调度