golang 的GC原理

因此，gc一旦开始，无论是创建对象还是对象的引用改变，都会先变为灰色。

<h2>堆栈</h2> <h3>内存分配中的堆和栈</h3>

栈（操作系统）：由操作系统自动分配释放 ，存放函数的参数值，局部变量的值等。其操作方式类似于数据结构中的栈。

堆（操作系统）： 一般由程序员分配释放， 若程序员不释放，程序结束时可能由OS回收，分配方式倒是类似于链表。

<h3>堆栈缓存方式</h3>

栈使用的是一级缓存， 他们通常都是被调用时处于存储空间中，调用完毕立即释放。

堆则是存放在二级缓存中，生命周期由虚拟机的垃圾回收算法来决定（并不是一旦成为孤儿对象就能被回收）。所以调用这些对象的速度要相对来得低一些。

申请到 栈内存 好处：函数返回直接释放，不会引起垃圾回收，对性能没有影响。

<h2>内存分配逃逸</h2>

所谓逃逸分析（Escape analysis）是指由编译器决定内存分配的位置，不需要程序员指定。

在函数中申请一个新的对象：

<ul><li>如果分配 在栈中，则函数执行结束可自动将内存回收；</li> <li>如果分配在堆中，则函数执行结束可交给GC（垃圾回收）处理;</li> </ul><h3>逃逸场景（什么情况才分配到堆中）</h3> <h4>指针逃逸</h4> <pre><code class="lang-go hljs">package main type Student struct { Name string Age int } func StudentRegister(name string, age int) *Student { s := new(Student) //局部变量s逃逸到堆 s.Name = name s.Age = age return s } func main() { StudentRegister("Jim", 18) } </code></code></pre>

虽然 在函数 StudentRegister() 内部 s 为局部变量，其值通过函数返回值返回，s 本身为一指针，其指向的内存地址不会是栈而是堆，这就是典型的逃逸案例。

终端运行命令查看逃逸分析日志：

<pre>go build -gcflags=-m</pre>

输出

<pre><code class="lang-go hljs">./main.go:16:6: can inline StudentRegister ./main.go:25:6: can inline main ./main.go:26:17: inlining call to StudentRegister ./main.go:16:22: leaking param: name ./main.go:17:10: new(Student) escapes to heap ./main.go:26:17: new(Student) does not escape </code></code></pre>

可见在StudentRegister()函数中，也即代码第10行显示”escapes to heap”，代表该行内存分配发生了逃逸现象。

<h4>栈空间不足逃逸（空间开辟过大）</h4> <pre><code class="lang-go hljs">package main func Slice() { s := make([]int, 1000, 1000) for index, _ := range s { s[index] = index } } func main() { Slice() } </code></code></pre>

上面代码Slice()函数中分配了一个1000个长度的切片，是否逃逸取决于栈空间是否足够大。 直接查看编译提示，如下：

<pre><code class="lang-go hljs">./main.go:20:6: can inline main ./main.go:13:11: make([]int, 1000, 1000) does not escape </code></code></pre>

所以只是1000的长度还不足以发生逃逸现象。然后就x10倍吧

<pre><code class="lang-go hljs">./main.go:20:6: can inline main ./main.go:13:11: make([]int, 10000, 10000) escapes to heap </code></code></pre>

当切片长度扩大到10000时就会逃逸。

实际上当栈空间不足以存放当前对象时或无法判断当前切片长度时会将对象分配到堆中。

<h4>动态类型逃逸（不确定长度大小）</h4>

很多函数参数为interface类型，比如fmt.Println(a …interface{})，编译期间很难确定其参数的具体类型，也能产生逃逸。

如下代码所示：

<pre><code class="lang-go hljs">package main import "fmt" func main() { s := "Escape" fmt.Println(s) } </code></code></pre>

又或者像前面提到的例子：

<pre><code class="lang-go hljs">func F() { a := make([]int, 0, 20) // 栈 空间小 b := make([]int, 0, 20000) // 堆 空间过大 逃逸 l := 20 c := make([]int, 0, l) // 堆 动态分配不定空间 逃逸 } </code></code></pre> <h4>闭包引用对象逃逸</h4>

Fibonacci数列的函数：

<pre><code class="lang-go hljs">package main import "fmt" func Fibonacci() func() int { a, b := 0, 1 return func() int { a, b = b, a b return a } } func main() { f := Fibonacci() for i := 0; i < 10; i { fmt.Printf("Fibonacci: %d\n", f()) } } </code></code></pre>

Fibonacci()函数中原本属于局部变量的a和b由于闭包的引用，不得不将二者放到堆上，以致产生逃逸。

<h4>逃逸分析的作用是什么呢？</h4> <ol><li>逃逸分析的好处是为了减少gc的压力，不逃逸的对象分配在栈上，当函数返回时就回收了资源，不需要gc标记清除。</li> <li>逃逸分析完后可以确定哪些变量可以分配在栈上，栈的分配比堆快，性能好(逃逸的局部变量会在堆上分配 ,而没有发生逃逸的则有编译器在栈上分配)。</li> <li>同步消除，如果你定义的对象的方法上有同步锁，但在运行时，却只有一个线程在访问，此时逃逸分析后的机器码，会去掉同步锁运行。</li> </ol><h4>逃逸总结：</h4> <ul><li>栈上分配内存比在堆中分配内存有更高的效率</li> <li>栈上分配的内存不需要GC处理</li> <li>堆上分配的内存使用完毕会交给GC处理</li> <li>逃逸分析目的是决定内分配地址是栈还是堆</li> <li>逃逸分析在编译阶段完成</li> </ul><h4>函数传递指针真的比传值效率高吗？</h4>

传递指针相比值传递减少了底层拷贝，可以提高效率，但是拷贝的数据量较小，由于指针传递会产生逃逸，可能会使用堆，也可能增加gc的负担，所以指针传递不一定是高效的。

<h3>GC的bug</h3>

https://zhuanlan.zhihu.com/p/32686933

<h2>代码优化</h2>

减少对象分配 所谓减少对象的分配，实际上是尽量做到，对象的重用。 比如像如下的两个函数定义：

第一个函数没有形参，每次调用的时候返回一个 []byte，第二个函数在每次调用的时候，形参是一个 buf []byte 类型的对象，之后返回读入的 byte 的数目。

第一个函数在每次调用的时候都会分配一段空间，这会给 gc 造成额外的压力。第二个函数在每次迪调用的时候，会重用形参声明。

老生常谈 string 与 []byte 转化 在 stirng 与 []byte 之间进行转换，会给 gc 造成压力 通过 gdb，可以先对比下两者的数据结构：

两者发生转换的时候，底层数据结结构会进行复制，因此导致 gc 效率会变低。解决策略上，一种方式是一直使用 []byte，特别是在数据传输方面，[]byte 中也包含着许多 string 会常用到的有效的操作。另一种是使用更为底层的操作直接进行转化，避免复制行为的发生。

少量使用 连接 string 由于采用 来进行 string 的连接会生成新的对象，降低 gc 的效率，好的方式是通过 append 函数来进行。

append操作 在使用了append操作之后，数组的空间由1024增长到了1312，所以如果能提前知道数组的长度的话，最好在最初分配空间的时候就做好空间规划操作，会增加一些代码管理的成本，同时也会降低gc的压力，提升代码的效率。

---

https://www.cnblogs.com/maoqide/p/12355565.html

三色标记法 混合写屏障

https://mp.weixin.qq.com/s?__biz=MzAxMTA4Njc0OQ==&mid=2651439356&idx=2&sn=264a3141ea9a4b29fe67ec06a17aeb99&chksm=80bb1e0eb7cc97181b81ae731d0d425dda1e9a8d503ff75f217a0d77bd9d0eb451555cb584a0&scene=21#wechat_redirect

Golang内存分配逃逸分析

https://www.cnblogs.com/shijingxiang/articles/12200355.html

---

到此这篇关于“golang 的GC原理”的文章就介绍到这了,更多文章或继续浏览下面的相关文章，希望大家以后多多支持JQ教程网！

您可能感兴趣的文章：
golang gc实现分析（go1.14.4）
Golang GC原理
Golang中的垃圾回收算法
go gc原理
go-内存机制(4)
golang垃圾回收
Golang垃圾回收机制
golang gc机制学习
Golang 中使用 Slice 索引 Map 替代 Map 获得性能提升
golang 释放内存机制的探索