很多函數(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) // 堆 動態(tài)分配不定空間 逃逸
}

3.4 閉包引用對象逃逸

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的壓力，不逃逸的對象分配在棧上，當函數(shù)返回時就回收了資源，不需要gc標記清除。
• 逃逸分析完后可以確定哪些變量可以分配在棧上，棧的分配比堆快，性能好(逃逸的局部變量會在堆上分配 ,而沒有發(fā)生逃逸的則有編譯器在棧上分配)。
• 同步消除，如果你定義的對象的方法上有同步鎖，但在運行時，卻只有一個線程在訪問，此時逃逸分析后的機器碼，會去掉同步鎖運行。

逃逸總結：

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

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

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

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

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）上？

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

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

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

二. golang 臨時對象池sync.Pool

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

實際項目基本都是通過

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

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

Golang使用的垃圾回收算法是『標記——清除』。

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

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

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

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