詳解Golang的GC和內(nèi)存逃逸
更新時間：2023年07月07日 08:23:33 作者：編程妲己
這篇文章主要給大家詳細介紹了Golang的GC和內(nèi)存逃逸，文章中有詳細的代碼示例，對我們的學習或工作有一定的幫助,需要的朋友可以參考下
簡介
每個版本的Golang的垃圾回收都在不斷優(yōu)化中，而且方法和策略都在變化，因此這里只是總結出以下幾個關鍵點：
- 什么樣的數(shù)據(jù)需要GC
- 觸發(fā)GC的條件是什么
- GC時發(fā)生了什么
- 能否從代碼層面上提高GC的效率
GC的基本流程
Golang在確定的時間，或者內(nèi)存分配到達一定程度時，進行GC。GC時，會停止STW（Stop The World），即對外的服務都會暫停，然后進行垃圾回收處理。Go1.12引入了三色標記法和write-barrier的方式；在Go1.14中，引入看了搶占式回收機制。
write-barrier機制：
假設有4個G在運行，如下圖：
進行GC的時候，需要STW，此時的4個G都要停止工作。如果有一個沒有停止工作的，則GC暫時不能發(fā)生。比如下圖：
第4個G沒停止工作，則GC需要等待其結束。Go1.14中，可以搶占第4個G的工作狀態(tài)，保存其狀態(tài)后，再進行GC
GC的時候，GC機制會征用一些G并發(fā)輔助進行工作，一般有25%的G會被征用。
整體工作流程：
- 創(chuàng)建白、灰和黑三個集合
- 初始化所有的待回收對象都是白色的
- 從根節(jié)點遍歷對象，不遞歸；遍歷到的白色對象放到灰色集合當中
- 之后遍歷灰色集合，把灰色對象引用的對象，從白色集合中放入灰色集合，并把現(xiàn)在的灰色對象放入黑色集合中
- 重復上一步，知道灰色集合是空的
- 通過write-barrier檢測對象的變化，重復以上操作
- 回收所有的白色對象
GC回收的對象
永遠不要過早的優(yōu)化程序！?。?/strong>
棧內(nèi)存分配和回收的代價遠遠小于堆內(nèi)存。Golang的垃圾回收發(fā)生在全局的堆上和每個Goroutinue的棧上?；厥諚?nèi)存只需要兩個CPU指令，push和pop。然而，分配在棧內(nèi)存的數(shù)據(jù)，需要在編譯期間就得知道type和size。
Golang的編譯器使用“逃逸分析”的方式，決定采取?；厥者€是堆回收的方式。如果發(fā)生逃逸，則使用堆回收。
go build -gcflags '-m'命令可以分析內(nèi)存逃逸的現(xiàn)象。
發(fā)生內(nèi)存逃逸的幾種情況：
- 向chan中發(fā)送數(shù)據(jù)的指針或者包含指針的值。
- 因為編譯器此時不知道值什么時候會被接收，因此只能放入堆中
- 非直接的函數(shù)調(diào)用，比如在閉包中引用包外的值，因為閉包執(zhí)行的生命周期可能會超過函數(shù)周期，因此需要放入堆中
- 在slice或map中存儲指針或者包含指針的值。
- 比如[]*string，即使slice是在棧上，其存儲的值仍然會放入堆中
- slice如果底層使用array作為容器，在使用append擴容的時候。但是，如果知道具體擴容的數(shù)量，則仍然在棧上。
- 如果在編譯期間，slice知道自己的size，那么放入棧中。更多的時候，是不知道size的，比如append的時候，此時只能放入堆中。
- interface類型多態(tài)的時候調(diào)用方法，此時會發(fā)生逃逸
- 指針、slice和map作為參數(shù)返回的時候，此時肯定要發(fā)生逃逸。
總結一下發(fā)生逃逸的結論：
- 首先明確一點，Golang中所有的數(shù)據(jù)都是按值傳遞，這點和C語言是一樣的（注意Golang中的數(shù)組名是值，和C的差別）。所謂的map、slice和chan等是引用，其本質(zhì)原因是，這些結構的內(nèi)部都有指針，復制的時候，內(nèi)部都是復制的指針，因此表現(xiàn)的是傳值。
- 在函數(shù)調(diào)用中，對于指針的情況，只要指向的地址的所有者只有一個，那么必然是棧回收；而一旦存在地址存在不確定變化時，則轉(zhuǎn)換成堆的數(shù)據(jù)。比如slice情況，因為slice會擴容或者縮容，因此造成不確定情況。
以下使用代碼示例說明：
package main
func main() {
ch := make(chan int, 1)
x := 5
ch <- x // x不發(fā)生逃逸，因為只是復制的值
ch1 := make(chan *int, 1)
y := 5
py := &y
ch1 <- py // y逃逸，因為地址傳入了chan
z := 5
pz := &z // z不逃逸，因為是確定性析構
*pz += 1
}執(zhí)行命令：go build -gcflags ./main.go，得到結論是y z都發(fā)生了逃逸。
# command-line-arguments
.\main.go:3:6: can inline main as: func() { ch := make(chan int, 1); x := 5; ch <- x; ch1 := make(chan *int, 1); y := 5; py := &y; ch1 <- py; z := 5; pz := &z; *pz += 1 }
.\main.go:9:2: y escapes to heap:
.\main.go:9:2: flow: py = &y:
.\main.go:9:2: from &y (address-of) at .\main.go:10:8
.\main.go:9:2: from py := &y (assign) at .\main.go:10:5
.\main.go:9:2: flow: {heap} = py:
.\main.go:9:2: from ch1 <- py (send) at .\main.go:11:6
.\main.go:9:2: moved to heap: y如果使用slice和map的模式：
package main
func main() {
var x int
x = 10
var ls []*int
ls = append(ls, &x)
var y int
var mp map[string]*int
mp["y"] = &y
}結論分析：
# command-line-arguments
.\main.go:3:6: can inline main as: func() { var x int; x = <N>; x = 10; var ls []*int; ls = <N>; ls = append(ls, &x); var y int; y = <N>; var mp map[string]*int; mp = <N>; mp["y"] = &y }
.\main.go:4:6: x escapes to heap:
.\main.go:4:6: flow: {heap} = &x:
.\main.go:4:6: from &x (address-of) at .\main.go:7:18
.\main.go:4:6: from append(ls, &x) (call parameter) at .\main.go:7:13
.\main.go:9:6: y escapes to heap:
.\main.go:9:6: flow: {heap} = &y:
.\main.go:9:6: from &y (address-of) at .\main.go:11:12
.\main.go:9:6: from mp["y"] = &y (assign) at .\main.go:11:10
.\main.go:4:6: moved to heap: x
.\main.go:9:6: moved to heap: y使用閉包捕獲指針的模式：
package main
import "time"
func main() {
x := 10
go func(x *int) {
*x += 1
}(&x) // 捕獲的瞬間，x沒有移動到heap上，但是整個閉包移動到了heap上，因此x也跟隨閉包被移動到heap上了
time.Sleep(time.Second * 2)
}結論分析：
# command-line-arguments
.\main.go:5:6: cannot inline main: unhandled op GO
.\main.go:7:5: can inline main.func1 as: func(*int) { *x += 1 }
.\main.go:7:5: func literal escapes to heap:
.\main.go:7:5: flow: {heap} = &{storage for func literal}:
.\main.go:7:5: from func literal (spill) at .\main.go:7:5
.\main.go:7:5: from go (func literal)(&x) (call parameter) at .\main.go:7:2
.\main.go:6:2: x escapes to heap:
.\main.go:6:2: flow: {heap} = &x:
.\main.go:6:2: from &x (address-of) at .\main.go:9:4
.\main.go:6:2: from go (func literal)(&x) (call parameter) at .\main.go:7:2
.\main.go:7:10: x does not escape
.\main.go:6:2: moved to heap: x
.\main.go:7:5: func literal escapes to heap對于slice擴容的情況：
package main
import (
"os"
"strconv"
)
func main() {
ls := []int{1, 2, 3}
ls = append(ls, 4) // 確定性的，不逃逸，編譯期間可以知道
var n int
n, _ = strconv.Atoi(os.Args[1]) // 輸入數(shù)據(jù)后，則結果不可知，因此可能逃逸
ls1 := []int{1, 2, 3}
for i := 0; i < n; i++ {
ls1 = append(ls1, 1)
}
}interface類型的GC，涉及使用interface類型轉(zhuǎn)換并調(diào)用對應的方法的時候，都會發(fā)生內(nèi)存逃逸，給出代碼示例：
package main
type foo interface {
fooFunc()
}
type foo1 struct{}
func (f1 foo1) fooFunc() {}
type foo2 struct{}
func (f2 *foo2) fooFunc() {}
func main() {
var f foo
f = foo1{}
f.fooFunc() // 調(diào)用方法時，發(fā)生逃逸，因為方法是動態(tài)分配的
f = &foo2{}
f.fooFunc()
}執(zhí)行說明：
go-code ? go build -gcflags "-m" main.go # command-line-arguments .\main.go:9:6: can inline foo1.fooFunc .\main.go:13:6: can inline (*foo2).fooFunc .\main.go:13:7: f2 does not escape .\main.go:17:4: foo1 literal escapes to heap .\main.go:19:6: &foo2 literal escapes to heap <autogenerated>:1: leaking param: .this <autogenerated>:1: inlining call to foo1.fooFunc <autogenerated>:1: .this does not escape
返回slice等的情況：
package main
func foo() []int {
return []int{1, 2, 3}
}
func main() {
ls := foo() // 發(fā)生逃逸
ls = append(ls, 1)
}分析結果：
# command-line-arguments
.\main.go:3:6: can inline foo as: func() []int { return []int literal }
.\main.go:7:6: can inline main as: func() { ls := foo(); ls = append(ls, 1) }
.\main.go:8:11: inlining call to foo func() []int { return []int literal }
.\main.go:4:14: []int literal escapes to heap:
.\main.go:4:14: flow: ~r0 = &{storage for []int literal}:
.\main.go:4:14: from []int literal (spill) at .\main.go:4:14
.\main.go:4:14: from return []int literal (return) at .\main.go:4:2
.\main.go:4:14: []int literal escapes to heap
.\main.go:8:11: []int literal does not escape傳值還是傳指針的問題：
根據(jù)上面的分析，指針更容易出現(xiàn)內(nèi)存逃逸的現(xiàn)象。而一旦發(fā)生了內(nèi)存逃逸，則不可避免地對GC造成潛在的壓力。有種錯誤的觀念：傳指針的代價總是比傳值的拷貝代價小。這種觀念只在像C語言這種沒有GC的低級語言中可能適用。原因如下：
- 對指針解引用的時候，編譯器會進行一些檢查。
- 指針一般都不是臨近地址的引用，而復制時，一般都是CPU cash中的數(shù)據(jù)，cash line內(nèi)的數(shù)據(jù)的復制，速度基本和一個復制指針相等
因此，對于小型的數(shù)據(jù)，一般傳值就夠了。在某些情況下，需要對代碼做一些重構，以消除成員變量中不必要的指針類型。slice有些情況下，可能也會造成內(nèi)存逃逸，使用已知固定長度的slice，某些情況下會減少內(nèi)存逃逸。nterface調(diào)用方法會發(fā)生內(nèi)存逃逸，某些熱點的情況下，可以考慮優(yōu)化interface的情況。
幾個總結
- 永遠不要過早的優(yōu)化，使用數(shù)據(jù)驅(qū)動優(yōu)化代碼
- 棧回收的代價遠遠小于堆回收的代價
- 指針一般情況下會影響棧回收
- 在熱點代碼片段，謹慎的使用interface
以上就是詳解Golang的GC和內(nèi)存逃逸的詳細內(nèi)容，更多關于Golang GC和內(nèi)存逃逸的資料請關注腳本之家其它相關文章！
相關文章
這篇文章主要為大家介紹了Go流程控制與快樂路徑原則的原理解析，2023-10-10
有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進步，早日升職加薪
這篇文章主要為大家介紹了go?proto編譯引用外部包問題解決方案示例,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進步,早日升職加薪2023-10-10
RPC指(Remote Procedure Call Protocol)遠程過程調(diào)用協(xié)議。本文將實現(xiàn)利用Golang進行rpc調(diào)用(只實現(xiàn)一個rpc框架基本的功能，不對性能做保證)，需要的可以參考一下2023-03-03
這篇文章主要給大家介紹了關于golang實戰(zhàn)之truncate日志文件的相關資料，文中通過示例代碼介紹的非常詳細，對大家的學習或者工作具有一定的參考學習價值，需要的朋友們下面隨著小編來一起學習學習吧2018-07-07
Go在GoLand中引用github.com中的第三方包具體步驟
這篇文章主要給大家介紹了關于Go在GoLand中引用github.com中第三方包的具體步驟,文中通過圖文介紹的非常詳細,對大家學習或者使用Go具有一定的參考價值,需要的朋友可以參考下2024-01-01
這篇文章主要為大家介紹了Go語言select語句用法示例詳解，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進步，早日升職加薪2022-08-08
Go語言遍歷map實現(xiàn)(訪問map中的每一個鍵值對)
這篇文章主要介紹了Go語言遍歷map實現(xiàn)(訪問map中的每一個鍵值對)，文中通過示例代碼介紹的非常詳細，對大家的學習或者工作具有一定的參考學習價值，需要的朋友們下面隨著小編來一起學習學習吧2021-01-01
go語言中如果不設置指定的時區(qū),通過time.Now()獲取到的就是本地時區(qū),下面這篇文章主要給大家介紹了關于Go中時間與時區(qū)問題的相關資料,需要的朋友可以參考下2021-12-12
本文主要介紹了淺談golang通道類型，文中通過示例代碼介紹的非常詳細，對大家的學習或者工作具有一定的參考學習價值，需要的朋友們下面隨著小編來一起學習學習吧2023-02-02
Mac上Go環(huán)境和VS Code的正確安裝與配置方法
Go語言是一個新興的語言。下面介紹一下如何在Mac系統(tǒng)下安裝和使用這個語言，Go語言提供了mac下安裝包，可直接下載安裝包點擊安裝2018-03-03