眾所周知，Golang是一門自帶GC的編程語言。這意味著內(nèi)存的分配和管理絕大多數(shù)情況下不需要開發(fā)者去過多干涉。
在編譯程序優(yōu)化理論中，逃逸分析是一種確定指針動態(tài)范圍的方法——分析在程序的哪些地方可以訪問到指針。它涉及到指針分析和形狀分析。
當一個變量(或?qū)ο?在子程序中被分配時，一個指向變量的指針可能逃逸到其它執(zhí)行線程中，或是返回到調(diào)用者子程序。如果使用尾遞歸優(yōu)化（通常在函數(shù)編程語言中是需要的），對象也可以看作逃逸到被調(diào)用的子程序中。如果一種語言支持第一類型的延續(xù)性在Scheme和Standard ML of New Jersey中同樣如此），部分調(diào)用棧也可能發(fā)生逃逸。
如果一個子程序分配一個對象并返回一個該對象的指針，該對象可能在程序中被訪問到的地方無法確定——這樣指針就成功“逃逸”了。如果指針存儲在全局變量或者其它數(shù)據(jù)結(jié)構(gòu)中，因為全局變量是可以在當前子程序之外訪問的，此時指針也發(fā)生了逃逸。
逃逸分析確定某個指針可以存儲的所有地方，以及確定能否保證指針的生命周期只在當前進程或線程中。引用自 維基百科
簡單梳理一下，逃逸分析的討論范圍，主要是值的可達性，保證在需要的時候能夠獲取到相對應(yīng)的值。在Golang的具體語境下，逃逸分析一般是討論編譯時決定值是存放在棧上，還是逃逸到堆上。
首先，明確一下堆棧的定義：
- 棧 棧是為每個具體函數(shù)分配的內(nèi)存片段，棧的生存周期等同于函數(shù)的生命周期，函數(shù)執(zhí)行完?？臻g會被回收
- 堆 堆是運行時動態(tài)使用的內(nèi)存塊，堆的生存周期為整個程序的生命周期，甚至更長
那么編譯器究竟如何決定值的分配區(qū)域呢？簡單一句話就是：需要在棧幀之間傳遞的，分配在堆上；大對象分配在堆上；盡在棧內(nèi)部使用的，分配在棧上。
下面通過幾個具體示例來簡單說明，我們可以通過go的gcflags來把逃逸部分的信息打印出來：
go build -gcflags "-m -l" demo.go
示例1
package main
type People struct {
Name string
}
//go:noinline
func newPeople1() People {
return People{
Name: "test1",
}
}
//go:noinline
func newPeople2() *People {
return &People{
Name: "test2",
}
}
func main() {
p1 := newPeople1()
p2 := newPeople2()
_, _ = p1, p2
}
運行結(jié)果：
# command-line-arguments
./demo.go:16:9: &People literal escapes to heap
# 這里運行結(jié)果可以看出，只有newPeople2函數(shù)的返回值才逃逸到堆上，這是因為newPeople2函數(shù)返回的是指針，為了確保這個指針在newPeople2方法執(zhí)行完之后依舊可以訪問，只能將它分配到堆上
示例2
...
// 其他部分代碼如*示例1*
func main() {
p1 := newPeople1()
p2 := newPeople2()
fmt.Println(p1, p2)
}
執(zhí)行結(jié)果：
# command-line-arguments
./demo.go:18:9: &People literal escapes to heap
# 這里同示例1的解釋
./demo.go:26:13: ... argument does not escape
./demo.go:26:13: p1 escapes to heap
# 因為在Println函數(shù)中需要p1的值，所以p1也逃逸到了堆上
示例3
...
// 其他部分代碼如*示例1*
//go:noinline
func GetPeople1(p *People) *People {
p1 := p
return p1
}
//go:noinline
func GetPeople2(p *People) *People {
p1 := *p
return &p1
}
func main() {
p := People{Name: "test3"}
_ = GetPeople1(&p)
_ = GetPeople2(&p)
}
運行結(jié)果：
# command-line-arguments
./demo.go:16:9: &People literal escapes to heap
./demo.go:22:17: leaking param: p to result ~r1 level=0
./demo.go:28:17: leaking param content: p
./demo.go:29:2: moved to heap: p1
# 因為GetPeople2函數(shù)中返回值是棧內(nèi)數(shù)據(jù)(p1)的地址(&p1)，為了保證這個值能夠被安全訪問到，所以p1逃逸到堆上。
示例4
package main
type People struct {
Name *string
Age int32
}
func setPeople1(p People, name string) People {
p.Name = &name
return p
}
func setPeople2(p People, age int32) People {
p.Age = age
return p
}
func main() {
p := People{}
_ = setPeople1(p, "Mike")
_ = setPeople2(p, 25)
}
運行結(jié)果：
# command-line-arguments
./demo.go:8:17: leaking param: p to result ~r2 level=0
./demo.go:8:27: moved to heap: name
# 在setPeople1函數(shù)中，返回值的Name字段的值指向一個棧內(nèi)的值(name)的地址，所以逃逸到堆上
./demo.go:13:17: leaking param: p to result ~r2 level=0
示例5
package main
func sliceAppend(s []int64) []int64 {
for i := 0; i < 1000; i++ {
s = append(s, int64(i))
}
return s
}
func sliceSlice(s []int64) []int64 {
return s[1:]
}
func mapExtend(m map[int64]int64) map[int64]int64 {
for i := 0; i < 1000; i++ {
m[int64(i)] = int64(2 * i)
}
return m
}
func mapRemove(m map[int64]int64) map[int64]int64 {
for k, v := range m {
if k%2 == 0 || v%2 == 0 {
delete(m, k)
}
}
return m
}
func main() {
s := make([]int64, 32)
m := make(map[int64]int64)
s = sliceAppend(s)
s = sliceSlice(s)
m = mapExtend(m)
m = mapRemove(m)
}
運行結(jié)果：
# command-line-arguments
./demo.go:3:18: leaking param: s to result ~r1 level=0
./demo.go:10:17: leaking param: s to result ~r1 level=0
./demo.go:14:16: leaking param: m to result ~r1 level=0
./demo.go:21:16: leaking param: m to result ~r1 level=0
./demo.go:31:11: make([]int64, 32) does not escape
./demo.go:32:11: make(map[int64]int64) does not escape
# 從結(jié)果來看，slice和map都是簡單的值傳遞，不涉及任何逃逸行為
總結(jié)
逃逸分析對于我們實際編程有什么意義呢？我們上面提到過，分配在棧上的空間會隨著函數(shù)執(zhí)行完而被回收，所以我們?nèi)粘Ｌ岬降腉C主要是指各種對于堆上內(nèi)存空間的追蹤和清理。理解逃逸分析有助于我們寫出GC友好的代碼（通過減少堆上內(nèi)存分配來減少內(nèi)存壓力），從另一個角度來看，如果代碼不分配在堆上，就意味著有可能會在多個棧中存在多個拷貝，額外空間占用和GC開銷之間需要作出權(quán)衡。
