1. 前言

所謂的逃逸分析（Escape analysis）是指由編譯器決定內(nèi)存分配的位置嗎不需要程序員指定。

函數(shù)中申請一個新的對象

• 如果分配在棧中， 則函數(shù)執(zhí)行結(jié)束后可自動將內(nèi)存回收
• 如果分配在堆中， 則函數(shù)執(zhí)行借宿可交給GC(垃圾回收)處理

有了逃逸分析，返回函數(shù)局部變量將變得可能，除此之外，逃逸分析還跟閉包息息相關(guān)，了解哪些場景下對象會逃逸至關(guān)重要。

2. 逃逸策略

每當(dāng)函數(shù)中申請新的對象，編譯器會根據(jù)該對象是否被函數(shù)外部引用來決定是否逃逸：

• 如果函數(shù)外部沒有引用，則優(yōu)先放到棧中；
• 如果函數(shù)外部存在引用，則必定放到堆中；

注意，對于函數(shù)外部沒有引用的對象，也有可能放到堆中，比如內(nèi)存過大超過棧的存儲能力。

3. 逃逸場景

3.1 指針逃逸

我們知道Go可以返回局部變量指針，這其實(shí)是一個典型的變量逃逸案例，示例代碼如下：

package main
 
type Student struct {
    Name string
    Age  int
}
 
func StudentRegister(name string, age int) *Student {
    s := new(Student) //局部變量s逃逸到堆
 
    s.Name = name
    s.Age = age
 
    return s
}
 
func main() {
    StudentRegister("Jim", 18)
}

函數(shù)StudentRegister()內(nèi)部s為局部變量，其值通過函數(shù)返回值返回，s本身為一指針，其指向的內(nèi)存地址不會是棧而是堆，這就是典型的逃逸案例。

通過編譯參數(shù)-gcflag=-m可以查看編譯過程中的逃逸分析：

D:\SourceCode\GoExpert\src>go build -gcflags=-m
# _/D_/SourceCode/GoExpert/src
.\main.go:8: can inline StudentRegister
.\main.go:17: can inline main
.\main.go:18: inlining call to StudentRegister
.\main.go:8: leaking param: name
.\main.go:9: new(Student) escapes to heap
.\main.go:18: main new(Student) does not escape

可見在StudentRegister()函數(shù)中，也即代碼第9行顯示”escapes to heap”，代表該行內(nèi)存分配發(fā)生了逃逸現(xiàn)象。

3.2 ?？臻g不足逃逸

看下面的代碼，是否會產(chǎn)生逃逸呢？

package main
 
func Slice() {
    s := make([]int, 1000, 1000)
 
    for index, _ := range s {
        s[index] = index
    }
}
 
func main() {
    Slice()
}

上面代碼Slice()函數(shù)中分配了一個1000個長度的切片，是否逃逸取決于?？臻g是否足夠大。

直接查看編譯提示，如下：

D:\SourceCode\GoExpert\src>go build -gcflags=-m
# _/D_/SourceCode/GoExpert/src
.\main.go:4: Slice make([]int, 1000, 1000) does not escape

我們發(fā)現(xiàn)此處并沒有發(fā)生逃逸。那么把切片長度擴(kuò)大10倍即10000會如何呢?

D:\SourceCode\GoExpert\src>go build -gcflags=-m
# _/D_/SourceCode/GoExpert/src
.\main.go:4: make([]int, 10000, 10000) escapes to heap

我們發(fā)現(xiàn)當(dāng)切片長度擴(kuò)大到10000時就會逃逸。

實(shí)際上當(dāng)?？臻g不足以存放當(dāng)前對象時或無法判斷當(dāng)前切片長度時會將對象分配到堆中。

3.3 動態(tài)類型逃逸

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

如下代碼所示：

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

上述代碼s變量只是一個string類型變量，調(diào)用fmt.Println()時會產(chǎn)生逃逸：

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

3.4 閉包引用對象逃逸

某著名的開源框架實(shí)現(xiàn)了某個返回Fibonacci數(shù)列的函數(shù)：

func Fibonacci() func() int {
    a, b := 0, 1
    return func() int {
        a, b = b, a+b
        return a
    }
}

該函數(shù)返回一個閉包，閉包引用了函數(shù)的局部變量a和b，使用時通過該函數(shù)獲取該閉包，然后每次執(zhí)行閉包都會依次輸出Fibonacci數(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())
    }
}

上述代碼通過Fibonacci()獲取一個閉包，每次執(zhí)行閉包就會打印一個Fibonacci數(shù)值。輸出如下所示：

D:\SourceCode\GoExpert\src>src.exe
Fibonacci: 1
Fibonacci: 1
Fibonacci: 2
Fibonacci: 3
Fibonacci: 5
Fibonacci: 8
Fibonacci: 13
Fibonacci: 21
Fibonacci: 34
Fibonacci: 55

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

D:\SourceCode\GoExpert\src>go build -gcflags=-m
# _/D_/SourceCode/GoExpert/src
.\main.go:7: can inline Fibonacci.func1
.\main.go:7: func literal escapes to heap
.\main.go:7: func literal escapes to heap
.\main.go:8: &a escapes to heap
.\main.go:6: moved to heap: a
.\main.go:8: &b escapes to heap
.\main.go:6: moved to heap: b
.\main.go:17: f() escapes to heap
.\main.go:17: main ... argument does not escape

4.逃逸總結(jié)

棧上分配內(nèi)存比在堆中分配內(nèi)存有更高的效率

棧上分配的內(nèi)存不需要GC處理

堆上分配的內(nèi)存使用完畢會交給GC處理

逃逸分析目的是決定內(nèi)分配地址是棧還是堆

逃逸分析在編譯階段完成

5. 注意事項(xiàng)

思考一下這個問題：函數(shù)傳遞指針真的比傳值效率高嗎？

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

到此這篇關(guān)于Go語言中內(nèi)存管理逃逸分析詳解的文章就介紹到這了,更多相關(guān)Go 內(nèi)存管理逃逸分析內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論