Go 使用什么样的垃圾收集？

Question

Go 是一种垃圾收集语言：

http://golang.org/doc/go_faq.html#garbage_collection

在这里说它是一个标记和清除垃圾收集器，但它没有深入研究细节，并且替代品正在开发中......然而，自从 Go 发布以来，这一段似乎没有更新太多。

仍然是标记和清除吗？是保守的还是精确的？是一代人的吗？

Answer 1

Go 1.4+ 垃圾收集器的计划：

• 混合 stop-the-world/并发收集器
• stop-the-world 部分受 10ms 截止时间限制
• CPU 核心专用于运行并发收集器
• 三色标记和清除算法
• 非分代非
• - 压缩
• ，那么完全精确的
• 如果程序正在以较低的延迟移动指针
• 会产生很小的成本，但很可能也会降低吞吐量，而不是 Go 1.3 GC

Go 1.3 垃圾收集器在 Go 1.1 之上进行更新：

• 并发扫描（导致更短的暂停时间）
• 完全精确

Go 1.1 垃圾收集器：

• 标记和扫描（并行实现）
• 非分代
• 非压缩
• 大部分精确（堆栈帧除外）
• 停止世界
• 基于位图的
• 表示零成本程序不分配内存（即：混洗指针与 C 中一样快，尽管实际上运行速度比 C 慢一些，因为 Go 编译器不像 GCC 等 C 编译器那么先进）
• 支持终结器对象
• 不支持弱引用

Go 1.0 垃圾收集器：

• 与 Go 1.1 相同，但垃圾收集器不是最精确的，而是保守的。保守的GC能够忽略诸如[]byte之类的对象。

用不同的GC替换GC是有争议的，例如：

• 除了非常大的堆之外，不清楚分代GC是否会更快整体
• 包“不安全”使得很难实现完全精确的GC和压缩GC

Answer 2

（对于 Go 1.8 - 2017 年第一季度，请参阅下文）

下一个 Go 1.5 并发垃圾收集器涉及gc 说，能够“步调”。
这是本文中提出的一项提案，可能会适用于 Go 1.5，但也有助于理解中的 gc去。

您可以看到 1.5 之前的状态（Stop The World：STW）

在 Go 1.5 之前，Go 使用了并行 stop-the-world (STW) 收集器。
虽然 STW 收集有很多缺点，但它至少具有可预测且可控的堆增长行为。

^{（照片来自 GopherCon 2015 演示文稿“Go GC：解决 Go 中的延迟问题1.5")}

STW 收集器的唯一调节旋钮是“GOGC”，即收集之间的相对堆增长。默认设置 100% 每当堆大小比上次收集时的实时堆大小增加一倍时就会触发垃圾收集：

^{STW 收集器中的 GC 计时。}

Go 1.5 引入了并发收集器。
与 STW 收集相比，这具有许多优点，但它使堆增长更难以控制，因为应用程序可以在垃圾收集器运行时分配内存。

^{（照片来自 GopherCon 2015 演示文稿“Go GC：解决 Go 中的延迟问题1.5")}

为了达到相同的堆增长限制，运行时必须提前开始垃圾收集，但提前多少取决于许多变量，其中许多变量无法预测。

• 过早启动收集器，应用程序将执行过多的垃圾收集，浪费 CPU 资源。
• 太晚启动收集器，应用程序将超过所需的最大堆增长。

要在不牺牲并发性的情况下实现正确的平衡，需要仔细调整垃圾收集器的节奏。

GC 节奏旨在沿着两个维度进行优化：堆增长和垃圾收集器使用的 CPU。

GC 节奏的设计由四个部分组成：

1. GC 周期所需的扫描工作量的估算器，
2. 一种机制，供变异器在堆分配达到堆目标时执行估计的扫描工作量，
3. 当 mutator 未充分利用 CPU 预算时用于后台扫描的调度程序，以及
4. GC 触发器的比例控制器。

该设计平衡了两种不同的时间视图：CPU 时间和堆时间。

• CPU 时间类似于标准挂钟时间，但速度比 GOMAXPROCS 倍快。
  也就是说，如果 GOMAXPROCS 为 8，则每墙秒经过 8 个 CPU 秒，GC 每墙秒获得两秒的 CPU 时间。
  CPU 调度程序管理 CPU 时间。
• 堆时间的流逝以字节为单位，并随着变元分配而向前移动。

堆时间和挂机时间之间的关系取决于分配率，并且可以不断变化。
Mutator 协助管理堆时间的流逝，确保在堆达到目标大小时已完成估计的扫描工作。
最后，触发器控制器创建一个反馈循环，将这两个时间视图联系在一起，从而优化堆时间和 CPU 时间目标。

Answer 3

这是 GC 的实现：

https://github.com /golang/go/blob/master/src/runtime/mgc.go

来自源中的文档：

GC 与 mutator 线程同时运行，类型准确（又称精确），允许多个 GC 线程并行运行。它是使用写屏障的并发标记和清除。它是非分代和非压缩的。分配是使用每个 P 分配区域的大小隔离来完成的，以最大限度地减少碎片，同时消除常见情况下的锁。

Answer 4

Go 1.8 GC 可能会再次发展，提案“消​​除 STW”堆栈重新扫描”

从 Go 1.7 开始，剩余的一个无限且可能不平凡的世界停止 (STW) 时间来源是堆栈重新扫描。

我们建议通过切换到结合了 Yuasa 式删除写入屏障 [Yuasa '90] 和 Dijkstra 式插入写屏障 [Dijkstra '78]。< /p>

初步实验表明，这可以将最坏情况下的 STW 时间减少到 50μs 以下，并且这种方法可以使完全消除 STW 标记终止变得可行。

公告在此，您可以查看相关来源提交是d70b0fe 及更早版本。

Answer 5

我不确定，但我认为当前（提示）GC 已经是并行的，或者至少是一个 WIP。因此，停止世界属性不再适用或在不久的将来也不会适用。也许其他人可以更详细地澄清这一点。