go语言1.15 go语言117

Go 语言三色标记扫描对象是 DFS 还是 BFS?

最近在看左神新书 《Go 语言设计与实现》的垃圾收集器时产生一个疑惑，花了点时间搞清楚了记录一下。

成都创新互联公司提供做网站、成都网站建设、网页设计，高端网站设计，广告投放等致力于企业网站建设与公司网站制作，10年的网站开发和建站经验,助力企业信息化建设，成功案例突破上1000家,是您实现网站建设的好选择.

Go 语言垃圾回收的实现使用了标记清除算法，将对象的状态抽象成黑色（活跃对象）、灰色（活跃对象中间状态）、白色（潜在垃圾对象也是所有对象的默认状态）三种，注意没有具体的字段标记颜色。

整个标记过程就是把白色对象标黑的过程：

1.首先将 ROOT 根对象（包括全局变量、goroutine 栈上的对象等）放入到灰色集合

2.选一个灰色对象，标成黑色，将所有可达的子对象放入到灰色集合

3.重复2的步骤，直到灰色集合中为空

下图是书上的插图，看上去是一个典型的深度优先搜索的算法。

下图是刘丹冰写的《Golang 修养之路》的插图，看上去是一个典型的广度优先搜索的算法。

我疑惑的点在于这个标记过程是深度优先算法还是广度优先算法，因为很多文章博客对此都没有很清楚的说明，作为学习者这种细节其实也不影响对整个 GC 流程的理解，但是这种细节我非常喜欢扣：）

对着书和源码摸索着大致找到了一个结果是深度优先。下面看下大致的过程，源码基于1.15.2版本：

gcStart 是 Go 语言三种条件触发 GC 的共同入口

启动后台标记任务

为每个处理器创建用于执行后台标记任务的 Goroutine

上面休眠的 G 会在调度循环中检查并唤醒执行

执行标记

gcw 是每个 P 独有的所以不用担心并发的问题 和 GMP、mcache 一样设计，减少锁竞争

尝试在全局列表中获取一个不为空的 buf

这是官方实现的无锁队列：）涨见识了，for 循环加原子操作实现栈的 pop

到这里从灰色集合中获取待扫描的对象逻辑说完了。找到对象了接着就是 scanobject(b, gcw) 了，里面有两段逻辑要注意

根据索引位置找到对象进行标色

尝试存入 gcwork 的缓存中，或全局队列中

无锁队列，for 循环加原子操作实现栈的 push

到这里把灰色对象标黑就完成了，又放回灰色集合接着扫下一个指针。

Go 语言设计与实现 垃圾收集器

Golang三色标记+混合写屏障GC模式全分析

Go语言使用 map 时尽量不要在 big map 中保存指针

不知道你有没有听过这么一句：在使用 map 时尽量不要在 big map 中保存指针。好吧，你现在已经听过了：）为什么呢？原因在于 Go 语言的垃圾回收器会扫描标记 map 中的所有元素，GC 开销相当大，直接GG。

这两天在《Mastering Go》中看到 GC 这一章节里面对比 map 和 slice 在垃圾回收中的效率对比，书中只给出结论没有说明理由，这我是不能忍的，于是有了这篇学习笔记。扯那么多，Show Your Code

这是一个简单的测试程序，保存字符串的 map 和 保存整形的 map GC 的效率相差几十倍，是不是有同学会说明明保存的是 string 哪有指针？这个要说到 Go 语言中 string 的底层实现了，源码在 src/runtime/string.go里，可以看到 string 其实包含一个指向数据的指针和一个长度字段。注意这里的是否包含指针，包括底层的实现。

Go 语言的 GC 会递归遍历并标记所有可触达的对象，标记完成之后将所有没有引用的对象进行清理。扫描到指针就会往下接着寻找，一直到结束。

Go 语言中 map 是基于 数组和链表 的数据结构实现的，通过 优化的拉链法 解决哈希冲突，每个 bucket 可以保存 8 对键值，在 8 个键值对数据后面有一个 overflow 指针，因为桶中最多只能装 8 个键值对，如果有多余的键值对落到了当前桶，那么就需要再构建一个桶（称为溢出桶），通过 overflow 指针链接起来。

因为 overflow 指针的缘故，所以无论 map 保存的是什么，GC 的时候就会把所有的 bmap 扫描一遍，带来巨大的 GC 开销。官方 issues 就有关于这个问题的讨论， runtime: Large maps cause significant GC pauses #9477

无脑机翻如下：

如果我们有一个map [k] v，其中k和v都不包含指针，并且我们想提高扫描性能，则可以执行以下操作。

将“ allOverflow [] unsafe.Pointer”添加到 hmap 并将所有溢出存储桶存储在其中。 然后将 bmap 标记为noScan。 这将使扫描非常快，因为我们不会扫描任何用户数据。

实际上，它将有些复杂，因为我们需要从allOverflow中删除旧的溢出桶。 而且它还会增加 hmap 的大小，因此也可能需要重新整理数据。

最终官方在 hmap 中增加了 overflow 相关字段完成了上面的优化，这是具体的 commit 地址。

下面看下具体是如何实现的，源码基于 go1.15，src/cmd/compile/internal/gc/reflect.go 中

通过注释可以看出，如果 map 中保存的键值都不包含指针（通过 Haspointers 判断），就使用一个 uintptr 类型代替 bucket 的指针用于溢出桶 overflow 字段，uintptr 类型在 GO 语言中就是个大小可以保存得下指针的整数，不是指针，就相当于实现了 将 bmap 标记为 noScan， GC 的时候就不会遍历完整个 map 了。随着不断的学习，愈发感慨 GO 语言中很多模块设计得太精妙了。

差不多说清楚了，能力有限，有不对的地方欢迎留言讨论，源码位置还是问的群里大佬 _

我为什么放弃Go语言

有好几次，当我想起来的时候，总是会问自己：我为什么要放弃Go语言？这个决定是正确的吗？是明智和理性的吗？其实我一直在认真思考这个问题。

开门见山地说，我当初放弃Go语言（golang），就是因为两个“不爽”：第一，对Go语言本身不爽；第二，对Go语言社区里的某些人不爽。毫无疑问，这是非常主观的结论。转载

1.1 不允许左花括号另起一行

1.2 编译器莫名其妙地给行尾加上分号

1.3 极度强调编译速度，不惜放弃本应提供的功能

1.4 错误处理机制太原始

1.5 垃圾回收器（GC）不完善、有重大缺陷

1.6 禁止未使用变量和多余import

1.7 创建对象的方式太多令人纠结

1.8 对象没有构造函数和析构函数

1.9 defer语句的语义设定不甚合理

1.10 许多语言内置设施不支持用户定义的类型

1.11 没有泛型支持，常见数据类型接口丑陋

1.12 实现接口不需要明确声明

1.13 省掉小括号却省不掉花括号

1.14 编译生成的可执行文件尺寸非常大

1.15 不支持动态加载类库