當(dāng)前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

通过实例理解 Go 逃逸分析

發(fā)布時間：2024/4/11 编程问答 26 豆豆

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

本文轉(zhuǎn)載自白明老師，這是中文社區(qū)里面最好、最全面的一篇關(guān)于逃逸分析的文章，寫得非常好。既有理論、又有實踐，引經(jīng)據(jù)典，精彩至及。

翻看了一下自己的Go文章歸檔^[1]，發(fā)現(xiàn)自己從未專門寫過有關(guān)Go逃逸分析（escape analysis）的文章。關(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)進(jìn)程虛擬內(nèi)存地址（virtual memory address）的概念后，如下圖所示，應(yīng)用程序的虛擬內(nèi)存地址空間就被劃分為堆內(nèi)存區(qū)（如圖中的heap）和棧內(nèi)存區(qū)（如圖中的stack）：

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

在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ā)人員帶來很大的心智負(fù)擔(dān)。為了降低這方面的心智負(fù)擔(dān)，帶有GC（垃圾回收）的編程語言出現(xiàn)了，比如Java、Go等。這些帶有GC的編程語言會對位于堆上的對象進(jìn)行自動管理。當(dāng)某個對象不可達(dá)時（即沒有其對象引用它時），它將會被回收并被重用。

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

逃逸分析（escape analysis）就是在程序編譯階段根據(jù)程序代碼中的數(shù)據(jù)流，對代碼中哪些變量需要在棧上分配，哪些變量需要在堆上分配進(jìn)行靜態(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ù)到使用第一版逃逸分析。之所以重寫，主要是考慮第一版代碼的可讀性和可維護(hù)性問題，新版代碼主要位于Go項目源碼的src/cmd/compile/internal/gc/escape.go中，它將逃逸分析代碼從上一版的2400多行縮減為1600多行，并作了更為完整文檔和注釋。但注意的是新版代碼在算法精確性上并沒有質(zhì)的變化。

但即便如此，經(jīng)過了這么多年的“修修補(bǔ)補(bǔ)”，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)原理。注釋中的原理說明中提到了算法基于的兩個不變性：

指向棧對象的指針不能存儲在堆中（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函數(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 //?強(qiáng)連接node?-?一個數(shù)據(jù)結(jié)構(gòu) 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) }

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

首先，構(gòu)建一個有向加權(quán)圖，其中頂點(稱為"location"，由gc.EscLocation表示)代表由語句和表達(dá)式分配的變量，而邊(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.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"來執(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+0rel?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.gotype?slice?struct?{array?unsafe.Pointerlen???intcap???int }

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

//?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函數(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?=?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輸出切片三元組中的代表底層數(shù)組地址的字段，這里是slice data。

我們看到：

第一個函數(shù)noEscapeWithDataInHeap聲明了一個空slice，并在后面使用append向切片附加元素。從輸出結(jié)果來看，slice自身是分配在棧上的，但是運行時在動態(tài)擴(kuò)展切片時，選擇了將其元素存儲在heap上；
第二個函數(shù)noEscapeWithDataInStack直接初始化了一個包含8個元素存儲空間的切片，切片自身沒有逃逸，并且在附加(append)的元素個數(shù)小于等于8個的時候，元素直接使用了為其分配的棧空間；但如果附加的元素超過8個，那么運行時會在堆上分配一個更大的空間并將原棧上的8個元素復(fù)制過去，后續(xù)該切片的元素就都存儲在了堆上。這也是為什么強(qiáng)烈建議在創(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.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兩個預(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”這句的含義究竟是什么呢？顯然逃逸分析在這一行是對進(jìn)入fmt.Printf的數(shù)據(jù)流的分析，我們修改一下go標(biāo)準(zhǔn)庫源碼，然后build -a重新編譯一下printf1.go^[10]，看看在fmt.Printf內(nèi)部變量的分布情況：

//?$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并運行編譯后的可執(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.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函數(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

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

Go核心團(tuán)隊成員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. 手動強(qiáng)制避免逃逸

對于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?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() }

對該代碼實施統(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逃逸分析的實例以及對逃逸分析輸出日志的說明。最后，我們給出一個強(qiáng)制避開逃逸分析的方案，但要謹(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

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

Go技術(shù)書籍的書摘和讀書體會系列
Go與eBPF系列

歡迎大家加入！

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

我的網(wǎng)課“Kubernetes實戰(zhàn)：高可用集群搭建、配置、運維與應(yīng)用^[17]”在慕課網(wǎng)熱賣中，歡迎小伙伴們訂閱學(xué)習(xí)！

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

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

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

我的聯(lián)系方式：

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

商務(wù)合作方式：撰稿、出書、培訓(xùn)、在線課程、合伙創(chuàng)業(yè)、咨詢、廣告合作。

參考資料

[1]?

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

[2]?

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

[3]?

go堆內(nèi)存所使用的內(nèi)存頁(page)與goroutine的棧所使用的內(nèi)存頁是交織在一起的:?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]?

切片實現(xiàn)原理:?https://www.imooc.com/read/87/article/2383

[9]?

為什么強(qiáng)烈建議在創(chuàng)建 slice 時帶上預(yù)估的cap參數(shù)的原因:?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]?

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

[15]?

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

[16]?

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

[17]?

Kubernetes實戰(zhàn)：高可用集群搭建、配置、運維與應(yīng)用:?https://coding.imooc.com/class/284.html

[18]?

我愛發(fā)短信:?https://51smspush.com/

[19]?

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。

实例