淺析Golang中的記憶體逃逸

2022-10-18 14:00:21

什麼是記憶體逃逸分析

記憶體逃逸分析是go的編譯器在編譯期間，根據變數的型別和作用域，確定變數是堆上還是棧上

簡單說就是編譯器在編譯期間，對程式碼進行分析，確定變數分配記憶體的位置。如果變數需要分配在堆上，則稱作記憶體逃逸了。

為什麼需要逃逸分析

因為go語言是自動自動記憶體管理的，也就是有GC的。開發者在寫程式碼的時候不需要關心考慮記憶體釋放的問題，這樣編譯器和go執行時（runtime）就需要準確分配和管理記憶體，所以編譯器在編譯期間要確定變數是放在堆空間和棧空間。

如果變數放錯了位置會怎樣

我們知道，棧空間和生命週期是和函數生命週期相關的，如果一個函數的區域性變數離開了函數的範圍，比如函數結束時，區域性變數就會失效。所以要把這樣的變數放到堆空間上。

既然如此，那把所有在變數都放在堆上不就行了，這樣一來，是沒啥問題了，但是堆記憶體的使用成本比佔記憶體要高好多。使用堆記憶體，要向作業系統申請和歸還，而佔記憶體是程式執行時就確定好了，如何使用完全由程式自己確定。在棧上分配和回收記憶體成本很低，只需要 2 個 CPU 指令：PUSH 和 POP，push 將資料放到到棧空間完成分配，pop 則是釋放空間。

比如 C++ 經典錯誤，return 一個函數內部變數的指標

#include<iostream>

int* one(){
    int i = 10;
    return &i;
}

int main(){
    std::cout << *one();
}

這段程式碼在編譯的時候會如下警告:

one.cpp: 在函數‘int* one()’中:
one.cpp:4:6: 警告：返回了區域性變數的‘i’的地址 [-Wreturn-local-addr]
int i = 10;
^

雖然程式的執行結果大多數時候都和我們預期的一樣，但是這樣的程式碼還是有風險的。

這樣的程式碼在go裡就完全沒有問題了，因為go的編譯器會根據變數的作用範圍確定變數是放在棧上和堆上。

記憶體逃逸場景

go的編譯器提供了逃逸分析的工具，只需要在編譯的時候加上 -gcflags=-m 就可以看到逃逸分析的結果了

常見的有4種場景下會出現記憶體逃逸

return 區域性變數的指標

package main

func main() {

}

func One() *int {
   i := 10
   return &i
}

執行 go build -gcflags=-m main.go

# command-line-arguments
.main.go:3:6: can inline main
.main.go:7:6: can inline One
.main.go:8:2: moved to heap: i

可以看到變數 i 已經被分配到堆上了

interface{} 動態型別

當函數傳遞的變數型別是 interface{} 型別的時候，因為編譯器無法推斷執行時變數的實際型別，所以也會發生逃逸

package main

import "fmt"

func main() {
   i := 10
   fmt.Println(i)
}

執行 go build -gcflags=-m .main.go

.main.go:11:13: inlining call to fmt.Println
.main.go:11:13: i escapes to heap
.main.go:11:13: []interface {} literal does not escape
<autogenerated>:1: .this does not escape
<autogenerated>:1: .this does not escape

可看到，i 也被分配到棧上了

棧空間不足

因為棧的空間是有限的，所以在分配大塊記憶體時，會考慮棧空間內否存下，如果棧空間存不下，會分配到堆上。

package main

func main() {
   Make10()
   Make100()
   Make10000()
   MakeN(5)
}

func Make10() {
   arr10 := make([]int, 10)
   _ = arr10
}

func Make100() {
   arr100 := make([]int, 100)
   _ = arr100
}

func Make10000() {
   arr10000 := make([]int, 10000)
   _ = arr10000
}

func MakeN(n int) {
   arrN := make([]int, n)
   _ = arrN
}

執行 go build -gcflags=-m main.go

# command-line-arguments
.main.go:10:6: can inline Make10
.main.go:15:6: can inline Make100
.main.go:20:6: can inline Make10000
.main.go:25:6: can inline MakeN
.main.go:3:6: can inline main
.main.go:4:8: inlining call to Make10
.main.go:5:9: inlining call to Make100
.main.go:6:11: inlining call to Make10000
.main.go:7:7: inlining call to MakeN
.main.go:4:8: make([]int, 10) does not escape
.main.go:5:9: make([]int, 100) does not escape
.main.go:6:11: make([]int, 10000) escapes to heap
.main.go:7:7: make([]int, n) escapes to heap
.main.go:11:15: make([]int, 10) does not escape
.main.go:16:16: make([]int, 100) does not escape
.main.go:21:18: make([]int, 10000) escapes to heap
.main.go:26:14: make([]int, n) escapes to heap

可以看到當需要分配長度為10，100的int型別的slice時，不需要逃逸到堆上，在棧上就可以，如果slice長度達到1000時，就需要分配到堆上了。

還有一種情況，當在編譯期間長度不確定時，也需要分配到堆上。

閉包

package main

func main() {
   One()
}

func One() func() {
   n := 10
   return func() {
      n++
   }
}

在函數One中return了一個匿名函數，形成了一個閉包，看一下逃逸分析

# command-line-arguments
.main.go:3:6: can inline main
.main.go:9:9: can inline One.func1
.main.go:8:2: moved to heap: n
.main.go:9:9: func literal escapes to heap

可以看到變數 n 也分配到堆上了

還有一種情況，new 出來的變數不一定分配到堆上

package main

func main() {
   i := new(int)
   _ = i
}

像java C++等語言，new 出來的變數正常都會分配到堆上，但是在go裡，new出來的變數不一定分配到堆上，至於分配到哪裡，還是看編譯器的逃逸分析來確定

編譯一下看看 go build -gcflags=-m main.go

# command-line-arguments
.main.go:3:6: can inline main
.main.go:4:10: new(int) does not escape

可以看到 new出來的變數，並沒有逃逸，還是在棧上。

常見的記憶體逃逸場景差不多就是這些了，再說一下記憶體逃逸帶來的影響吧

效能

那肯定就是效能問題了，因為操作棧空間比堆空間要快多了，而且使用堆空間還會有GC問題，頻繁的建立和釋放堆空間，會增加GC的壓力

一個簡單的例子測試一下，一般來說，函數返回結構體的指標比直接返回結構體效能要好

package main

import "testing"

type MyStruct struct {
   A int
}

func BenchmarkOne(b *testing.B) {
   for i := 0; i < b.N; i++ {
      One()
   }
}

//go:noinline
func One() MyStruct {
   return MyStruct{
      A: 10,
   }
}

func BenchmarkTwo(b *testing.B) {
   for i := 0; i < b.N; i++ {
      Two()
   }
}

//go:noinline
func Two() *MyStruct {
   return &MyStruct{
      A: 10,
   }
}

注意被呼叫的函數一定要加上 //go:noinline 來禁止編譯器內聯優化

然後執行

go test -bench . -benchmem

goos: windows
goarch: amd64
pkg: escape
BenchmarkOne-6          951519297                1.26 ns/op            0 B/op          0 allocs/op
BenchmarkTwo-6          74933496                15.4 ns/op             8 B/op          1 allocs/op
PASS
ok      escape  2.698s

可以明顯看到函數 One返回結構體比函數Two 返回結構體指標的效能更好，而且還不會有記憶體分配，不會增加GC壓力

拋開結構體的大小談效能都是耍流氓，如果結構體比較複雜了還是指標效能更高，還有一些場景必須使用指標，所以實際工作中還是要分場景合理使用