網站首頁 編程語言 正文
什么是內存逃逸分析
內存逃逸分析是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壓力
拋開結構體的大小談性能都是耍流氓,如果結構體比較復雜了還是指針性能更高,還有一些場景必須使用指針,所以實際工作中還是要分場景合理使用
最后
常見的go 逃逸分析差不多就是這些了,雖然go會自動管理內存,減小了寫代碼的負擔,但是想要寫出高效可靠的代碼還是有一些細節有注意的。
原文鏈接:https://juejin.cn/post/7154711508142784526
相關推薦
- 2022-06-06 解決:Access denied for user ‘root‘@‘localhost‘ (usin
- 2022-08-26 一篇文章搞懂Go語言中的Context_Golang
- 2022-08-18 R語言ComplexHeatmap繪制復雜熱圖heatmap_R語言
- 2022-08-20 pip安裝路徑修改的詳細方法步驟_python
- 2022-07-26 Android自定義評分控件的完整實例_Android
- 2022-07-03 python爬蟲lxml庫解析xpath網頁過程示例_python
- 2021-12-12 【Groovy】集合遍歷 ( 使用集合的 eachWithIndex 方法進行遍歷 | 代碼示例 )
- 2022-08-24 使用chrome控制臺作為.Net的日志查看器_實用技巧
- 最近更新
-
- window11 系統安裝 yarn
- 超詳細win安裝深度學習環境2025年最新版(
- Linux 中運行的top命令 怎么退出?
- MySQL 中decimal 的用法? 存儲小
- get 、set 、toString 方法的使
- @Resource和 @Autowired注解
- Java基礎操作-- 運算符,流程控制 Flo
- 1. Int 和Integer 的區別,Jav
- spring @retryable不生效的一種
- Spring Security之認證信息的處理
- Spring Security之認證過濾器
- Spring Security概述快速入門
- Spring Security之配置體系
- 【SpringBoot】SpringCache
- Spring Security之基于方法配置權
- redisson分布式鎖中waittime的設
- maven:解決release錯誤:Artif
- restTemplate使用總結
- Spring Security之安全異常處理
- MybatisPlus優雅實現加密?
- Spring ioc容器與Bean的生命周期。
- 【探索SpringCloud】服務發現-Nac
- Spring Security之基于HttpR
- Redis 底層數據結構-簡單動態字符串(SD
- arthas操作spring被代理目標對象命令
- Spring中的單例模式應用詳解
- 聊聊消息隊列,發送消息的4種方式
- bootspring第三方資源配置管理
- GIT同步修改后的遠程分支