Golang

关注公众号 jb51net

关闭
首页 > 脚本专栏 > Golang > Golang GC和内存逃逸

详解Golang的GC和内存逃逸

作者：编程妲己

这篇文章主要给大家详细介绍了Golang的GC和内存逃逸，文章中有详细的代码示例，对我们的学习或工作有一定的帮助,需要的朋友可以参考下

简介

每个版本的Golang的垃圾回收都在不断优化中，而且方法和策略都在变化，因此这里只是总结出以下几个关键点：

GC的基本流程

Golang在确定的时间，或者内存分配到达一定程度时，进行GC。GC时，会停止STW（Stop The World），即对外的服务都会暂停，然后进行垃圾回收处理。Go1.12引入了三色标记法和write-barrier的方式；在Go1.14中，引入看了抢占式回收机制。

write-barrier机制：

假设有4个G在运行，如下图：

进行GC的时候，需要STW，此时的4个G都要停止工作。如果有一个没有停止工作的，则GC暂时不能发生。比如下图：

第4个G没停止工作，则GC需要等待其结束。Go1.14中，可以抢占第4个G的工作状态，保存其状态后，再进行GC

GC的时候，GC机制会征用一些G并发辅助进行工作，一般有25%的G会被征用。

整体工作流程：

GC回收的对象

永远不要过早的优化程序！！！

栈内存分配和回收的代价远远小于堆内存。Golang的垃圾回收发生在全局的堆上和每个Goroutinue的栈上。回收栈内存只需要两个CPU指令，push和pop。然而，分配在栈内存的数据，需要在编译期间就得知道type和size。

Golang的编译器使用“逃逸分析”的方式，决定采取栈回收还是堆回收的方式。如果发生逃逸，则使用堆回收。

go build -gcflags '-m'命令可以分析内存逃逸的现象。

发生内存逃逸的几种情况：

总结一下发生逃逸的结论：

以下使用代码示例说明：

package main
func main() {
    ch := make(chan int, 1)
    x := 5
    ch <- x  // x不发生逃逸，因为只是复制的值
    ch1 := make(chan *int, 1)
    y := 5
    py := &y
    ch1 <- py  // y逃逸，因为地址传入了chan
    z := 5
    pz := &z  // z不逃逸，因为是确定性析构
    *pz += 1
 }

执行命令：go build -gcflags ./main.go，得到结论是y z都发生了逃逸。

# 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])  // 输入数据后，则结果不可知，因此可能逃逸
    ls1 := []int{1, 2, 3}
    for i := 0; i < n; i++ {
        ls1 = append(ls1, 1)
    }
}

interface类型的GC，涉及使用interface类型转换并调用对应的方法的时候，都会发生内存逃逸，给出代码示例：

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()   // 调用方法时，发生逃逸，因为方法是动态分配的
    f = &foo2{}
    f.fooFunc()
}

执行说明：

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() // 发生逃逸
	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

传值还是传指针的问题：

根据上面的分析，指针更容易出现内存逃逸的现象。而一旦发生了内存逃逸，则不可避免地对GC造成潜在的压力。有种错误的观念：传指针的代价总是比传值的拷贝代价小。这种观念只在像C语言这种没有GC的低级语言中可能适用。原因如下：

因此，对于小型的数据，一般传值就够了。在某些情况下，需要对代码做一些重构，以消除成员变量中不必要的指针类型。slice有些情况下，可能也会造成内存逃逸，使用已知固定长度的slice，某些情况下会减少内存逃逸。nterface调用方法会发生内存逃逸，某些热点的情况下，可以考虑优化interface的情况。

几个总结

以上就是详解Golang的GC和内存逃逸的详细内容，更多关于Golang GC和内存逃逸的资料请关注脚本之家其它相关文章！

您可能感兴趣的文章:
阅读全文