很多函數(shù)參數(shù)為interface類型，比如fmt.Println(a …interface{})，編譯期間很難確定其參數(shù)的具體類型，也能產(chǎn)生逃逸。

如下代碼所示：

package main
import "fmt"
func main() {
    s := "Escape"
    fmt.Println(s)
}

逃逸分下如下：

D:\SourceCode\GoExpert\src>go build -gcflags=-m
# _/D_/SourceCode/GoExpert/src
.\main.go:7: s escapes to heap
.\main.go:7: main ... argument does not escape

又或者像前面提到的例子：

func F() {
	a := make([]int, 0, 20)     // 棧 空間小
	b := make([]int, 0, 20000) // 堆 空間過大 逃逸
	l := 20
	c := make([]int, 0, l) // 堆 動(dòng)態(tài)分配不定空間 逃逸
}

3.4 閉包引用對(duì)象逃逸

Fibonacci數(shù)列的函數(shù)：

package main
import "fmt"
func Fibonacci() func() int {
    a, b := 0, 1
    return func() int {
        a, b = b, a+b
        return a
    }
}
func main() {
    f := Fibonacci()
    for i := 0; i < 10; i++ {
        fmt.Printf("Fibonacci: %d\n", f())
    }
}

輸出如下：

~/go/src/gitHub/test/pool  go run main.go
Fibonacci: 1
Fibonacci: 1
Fibonacci: 2
Fibonacci: 3
Fibonacci: 5
Fibonacci: 8
Fibonacci: 13
Fibonacci: 21
Fibonacci: 34
Fibonacci: 55

逃逸如下：

~/go/src/gitHub/test/pool  go build -gcflags=-m
# gitHub/test/pool
./main.go:7:9: can inline Fibonacci.func1
./main.go:7:9: func literal escapes to heap
./main.go:7:9: func literal escapes to heap
./main.go:8:10: &b escapes to heap
./main.go:6:5: moved to heap: b
./main.go:8:13: &a escapes to heap
./main.go:6:2: moved to heap: a
./main.go:17:34: f() escapes to heap
./main.go:17:13: main ... argument does not escape

Fibonacci()函數(shù)中原本屬于局部變量的a和b由于閉包的引用，不得不將二者放到堆上，以致產(chǎn)生逃逸。

逃逸分析的作用是什么呢？

• 逃逸分析的好處是為了減少gc的壓力，不逃逸的對(duì)象分配在棧上，當(dāng)函數(shù)返回時(shí)就回收了資源，不需要gc標(biāo)記清除。
• 逃逸分析完后可以確定哪些變量可以分配在棧上，棧的分配比堆快，性能好(逃逸的局部變量會(huì)在堆上分配 ,而沒有發(fā)生逃逸的則有編譯器在棧上分配)。
• 同步消除，如果你定義的對(duì)象的方法上有同步鎖，但在運(yùn)行時(shí)，卻只有一個(gè)線程在訪問，此時(shí)逃逸分析后的機(jī)器碼，會(huì)去掉同步鎖運(yùn)行。

逃逸總結(jié)：

• 棧上分配內(nèi)存比在堆中分配內(nèi)存有更高的效率
• 棧上分配的內(nèi)存不需要GC處理
• 堆上分配的內(nèi)存使用完畢會(huì)交給GC處理
• 逃逸分析目的是決定內(nèi)分配地址是棧還是堆
• 逃逸分析在編譯階段完成

提問：函數(shù)傳遞指針真的比傳值效率高嗎？

我們知道傳遞指針可以減少底層值的拷貝，可以提高效率，但是如果拷貝的數(shù)據(jù)量小，由于指針傳遞會(huì)產(chǎn)生逃逸，可能會(huì)使用堆，也可能會(huì)增加GC的負(fù)擔(dān)，所以傳遞指針不一定是高效的。

在官網(wǎng) (golang.org) FAQ 上有一個(gè)關(guān)于變量分配的問題如下：

From a correctness standpoint, you don’t need to know. Each variable in Go exists as long as there are references to it. The storage location chosen by the implementation is irrelevant to the semantics of the language.
The storage location does have an effect on writing efficient programs. 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.
In the current compilers, if a variable has its address taken, that variable is a candidate for allocation on the heap. However, a basic escape analysis recognizes some cases when such variables will not live past the return from the function and can reside on the stack.

翻譯如下：

如何得知變量是分配在棧（stack）上還是堆（heap）上？

準(zhǔn)確地說，你并不需要知道。Golang 中的變量只要被引用就一直會(huì)存活，存儲(chǔ)在堆上還是棧上由內(nèi)部實(shí)現(xiàn)決定而和具體的語(yǔ)法沒有關(guān)系。

知道變量的存儲(chǔ)位置確實(shí)和效率編程有關(guān)系。如果可能，Golang 編譯器會(huì)將函數(shù)的局部變量分配到函數(shù)棧幀（stack frame）上。 然而，如果編譯器不能確保變量在函數(shù) return之后不再被引用，編譯器就會(huì)將變量分配到堆上。而且，如果一個(gè)局部變量非常大，那么它也應(yīng)該被分配到堆上而不是棧上。

當(dāng)前情況下，如果一個(gè)變量被取地址，那么它就有可能被分配到堆上。然而，還要對(duì)這些變量做逃逸分析，如果函數(shù)return之后，變量不再被引用，則將其分配到棧上。

二. golang 臨時(shí)對(duì)象池sync.Pool

1. 內(nèi)存碎片化問題

實(shí)際項(xiàng)目基本都是通過

c := make([]int, 0, l)

來申請(qǐng)內(nèi)存，長(zhǎng)度都是不確定的，自然而然這些變量都會(huì)申請(qǐng)到堆上面了。

Golang使用的垃圾回收算法是『標(biāo)記——清除』。

簡(jiǎn)單得說，就是程序要從操作系統(tǒng)申請(qǐng)一塊比較大的內(nèi)存，內(nèi)存分成小塊，通過鏈表鏈接。

每次程序申請(qǐng)內(nèi)存，就從鏈表上面遍歷每一小塊，找到符合的就返回其地址，沒有合適的就從操作系統(tǒng)再申請(qǐng)。如果申請(qǐng)內(nèi)存次數(shù)較多，而且申請(qǐng)的大小不固定，就會(huì)引起內(nèi)存碎片化的問題。

申請(qǐng)的堆內(nèi)存并沒有用完，但是用戶申請(qǐng)的內(nèi)存的時(shí)候卻沒有合適的空間提供。這樣會(huì)遍歷整個(gè)鏈表，還會(huì)繼續(xù)向操作系統(tǒng)申請(qǐng)內(nèi)存。這就能解釋我一開始描述的問題，申請(qǐng)一塊內(nèi)存變成了慢語(yǔ)句。

到此這篇關(guān)于一文帶你搞懂golang中內(nèi)存分配逃逸分析的文章就介紹到這了,更多相關(guān)go內(nèi)存分配逃逸內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！