Go記憶體逃逸分析

分析記憶體逃逸之前要搞清楚一件事我們編寫的程式中的函式和區域性變數是存放在棧上的(補充一點堆上儲存的資料的指標是存放在棧上的因為指標的大小是可以提前預知的還有就是go的基本型別也是存放在棧內的), 而其餘的變數是存在堆上的, 棧是由作業系統層面控制進行記憶體空間的釋放 , 堆預設是程式控制的像c c++ 是需要標明釋放記憶體空間的位置 , 棧的執行速度遠大於堆 . 擁有gc的高階語言**的便是堆中的內容

函式返回區域性變數是乙個指標變數

# 
type user struct 
func name(s string) *user 
func main() 
# command-line-arguments
./main.go:9:6: can inline name
./main.go:18:14: inlining call to name
./main.go:19:13: inlining call to fmt.println
./main.go:9:11: leaking param: s
./main.go:10:10: new(user) escapes to heap // 造成逃逸
./main.go:18:14: new(user) escapes to heap // 造成逃逸
./main.go:19:13: inte***ce {} does not escape
:1: leaking param content: .this

2.inte***ce的動態型別造成的記憶體逃逸

// fmt.println 接受的引數就是inte***ce動態型別 編譯器很難確定接收變數的型別 所有會將123這個變數逃逸到堆
func main() 
# command-line-arguments
./main.go:16:6: can inline main
./main.go:20:13: inlining call to fmt.println
./main.go:20:14: 123 escapes to heap
./main.go:20:13: inte***ce {} does not escape
:1: leaking param content: .this

3.閉包函式產生的記憶體逃逸

// 因為函式也是乙個指標型別 所以將匿名函式作為返回值時  也會產生記憶體逃逸 原理類似於 第乙個 原因
func bibao() func() string 
}# command-line-arguments
./main.go:24:9: func literal escapes to heap:
./main.go:24:9: flow: ~r0 = &:
./main.go:24:9: from func literal (spill) at ./main.go:24:9
./main.go:24:9: from return func literal (return) at ./main.go:24:2
./main.go:24:9: func literal escapes to heap

4.變數大小無法確定或棧空間不足引發記憶體逃逸

ulimit -a    // ulimit -a 可以看到我們的棧空間是8192
-t: cpu time (seconds) unlimited
-f: file size (blocks) unlimited
-d: data seg size (kbytes) unlimited
-s: stack size (kbytes) 8192
-c: core file size (blocks) 0
-v: address space (kbytes) unlimited
-l: locked-in-memory size (kbytes) unlimited
-u: processes 2784
-n: file descriptors 2560
// 超大切片超出棧空間 引發的記憶體逃逸
package main
func main() 
}

Go記憶體逃逸分析

Go語言之GO 語言變數逃逸分析

JVM物件逃逸分析 JVM記憶體

逃逸分析 Escape Analysis）

Go記憶體逃逸分析

Go語言之GO 語言變數逃逸分析

JVM物件逃逸分析 JVM記憶體

逃逸分析 Escape Analysis）

相關推薦