Go 1.5 相比 Go 1.4 有哪些值得注意的改动？

本系列旨在梳理 Go 的 release notes 与发展史，来更加深入地理解 Go 语言设计的思路。

https://go.dev/doc/go1.5

Go 1.5 值得关注的改动：

1. 自举（Bootstrapping） ：编译器和运行时现在完全由 Go 语言（和少量汇编）实现，不再依赖 C 语言编译器进行构建。
2. 垃圾回收器（Garbage Collector, GC） ：新的 GC 采用并发设计，通过尽可能与其他 goroutine 并行运行，显著降低了“卡顿”（STW, Stop-The-World）时间。
3. GOMAXPROCS 默认值 ：Go 程序现在默认将 GOMAXPROCS 设置为可用的 CPU 核心数，以充分利用多核处理能力；而在之前的版本中，该值默认为 1。

下面是一些值得展开的讨论：

再无 C 语言：编译器、运行时与自举

Go 1.5 最具里程碑意义的变化之一是 彻底移除了构建过程中对 C 语言的依赖 。编译器和运行时现在完全由 Go 语言和少量汇编语言实现。源代码树中仅存的 C 代码主要与 Cgo 或测试相关。

在此之前（Go 1.4 及更早版本），Go 的工具链（如编译器 6g, 8g 等）源于 Plan 9 的工具链，并且是用 C 语言编写的。运行时也需要一个定制的 C 编译器来构建，部分原因是为了确保 C 代码能与 Go 的 goroutine 栈管理机制协同工作。

转向 Go 实现编译器的主要动机包括 ：

• 开发效率与正确性 ：用 Go 编写和调试 Go 编译器比用 C 更容易、更安全。
• 知识统一 ：开发 Go 编译器只需深入理解 Go，无需同时精通 C。
• 并发优势 ：Go 原生支持并发，简化了利用多核资源进行编译优化的实现。
• 生态支持 ：Go 在模块化、代码重构、单元测试和性能分析方面拥有更好的标准库和工具支持。
• 开发体验 ：用 Go 编写代码通常被认为比 C 更“有趣”。

实现过程 ：

• 这个转变并非完全重写，而是借助了 自动化工具将原有的 C 代码转换成了 Go 代码 。这在很大程度上保证了编译器逻辑的一致性，减少了引入新 Bug 的风险。

引入自举（Bootstrapping） ：

• 由于编译器现在由 Go 编写，就产生了一个“鸡生蛋，蛋生鸡”的问题：如何构建一个 Go 编译器，如果你还没有一个可用的 Go 编译器？
• Go 1.5 的解决方案是： 构建 Go 1.5（及后续版本）需要一个已存在的、旧版本的 Go 环境 （最初是 Go 1.4）。这个旧环境被称为 Bootstrap Toolchain ，其路径由环境变量 $GOROOT_BOOTSTRAP 指定（默认为 $HOME/go1.4）。

新的构建流程（Go 1.5 及以后）大致如下 ：

1. 使用 Go 1.4 构建 Go 1.5 的 cmd/dist 工具。
2. 使用 cmd/dist 和 Go 1.4 工具链构建 Go 1.5 的编译器、汇编器、链接器。
3. 使用 cmd/dist 和 刚刚在步骤 2 中构建出的 Go 1.5 工具链 重新构建 Go 1.5 工具链自身。
4. 使用 cmd/dist 和 步骤 3 中最终生成的 Go 1.5 工具链 构建 Go 1.5 的 cmd/go（作为 go_bootstrap）。
5. 使用 go_bootstrap 构建剩余的标准库和命令。

对比旧流程，主要变化在于：

• 用 Go 1.4 替代了原本的系统 C 编译器（gcc 或 clang）。
• 增加了步骤 3 的自举环节 。这一步确保最终的工具链是完全由 Go 1.5 自身编译和链接的，可以应用 Go 1.5 可能引入的二进制格式变化、性能或稳定性改进。

对新平台移植的影响 ：

• 自举过程使得向一个全新的、尚不支持 Go 的系统移植 Go 变得稍微复杂。开发者需要先在已有 Go 支持的系统上交叉编译出目标平台的测试二进制文件，然后在目标系统上运行调试。当工具链能在目标系统运行后，可以通过 bootstrap.bash 脚本准备一个用于新系统的 $GOROOT_BOOTSTRAP 目录。

工具和文件命名 ：

• 伴随着编译器从 C 转向 Go，工具的命名也统一了。之前的架构特定名称（如 6g, 8g, 6l, 8l, 6a, 8a 等）被移除。
• 现在只有一个编译器 go tool compile，一个链接器 go tool link，和一个汇编器 go tool asm。它们会根据环境变量 $GOOS 和 $GOARCH 生成对应平台的代码。
• 相应的，编译和汇编产生的中间目标文件后缀也从 .6, .8 等统一为 .o。

并发垃圾回收器：显著降低延迟

Go 1.5 对垃圾回收器（Garbage Collector, GC）进行了彻底的重新设计和工程实现，其核心目标是 大幅降低 GC 导致的程序暂停（STW）时间 ，提升 Go 应用的响应能力和实时性。

核心目标与设计：

• 低延迟 ：目标是将绝大多数 GC 暂停时间控制在 10 毫秒以下 。
• 高吞吐 ：在满足低延迟的同时，保证用户程序（Mutator）在每 50 毫秒的时间窗口内至少有 40 毫秒的有效运行时间。
• 资源假设 ：这些目标基于“合理配置”的硬件，通常意味着内存大小至少是活跃数据（Reachable Memory）的两倍，并能提供约 25% 的 CPU 资源（典型如 4 核中的 1 核）给 GC 任务。
• 混合并发模型 ：采用了一种混合 STW 和 并发（Concurrent） 的 GC 策略。GC 周期开始时会有一个短暂的 STW 阶段，如果在此阶段内完成回收则结束；否则，GC 将转入并发阶段，与用户 goroutine 并行执行大部分回收工作（如标记和清扫）。

Go 1.5 实现的关键技术与变化：

• 并发标记（Concurrent Marking） ：GC 的标记阶段大部分时间可以与用户 goroutine 并行执行。这需要 写屏障（Write Barrier） 技术来跟踪在标记过程中用户 goroutine 对指针的修改。
• 并发清扫（Concurrent Sweeping） ：与标记类似，清扫阶段也可以并发进行。
• GC Pacing 算法（GC Pacing Algorithm） ：这是一个关键的控制器，用于决定何时触发下一次 GC。它基于当前的堆大小、目标堆大小（通常是上次 GC 后活跃内存的两倍，由 GOGC 控制）以及程序分配内存的速度来动态调整。
• 辅助标记（Mutator Assists） ：为了防止在 GC 并发标记期间，用户 goroutine 分配内存过快导致堆大小超出目标，引入了辅助标记机制。当 goroutine 分配内存时，它会根据需要被要求“帮助” GC 完成一部分标记工作，然后才能继续分配。这种辅助工作的量与分配量成正比，相当于对分配行为施加了“反压”。如果 GC 工作落后太多，分配甚至可能需要让出 CPU 等待 GC 跟上。
• 辅助清扫（Sweep Assists） ：类似于辅助标记，Go 1.5 引入了 比例清扫（Proportional Sweeping） 。用户 goroutine 在分配内存时，也需要承担一部分清扫上一轮 GC 遗留的垃圾内存的工作。这确保了在下一次 GC 的标记阶段开始前，整个堆的清扫工作一定能完成，避免了因集中完成清扫而导致的延迟。
• 扫描工作量估算（Scan Work Estimator） ：为了准确进行 GC Pacing 和分配辅助标记的工作量，需要估算标记阶段扫描对象所需的工作量。Go 1.5 最终采用了一种相对保守的方法：使用当前 总的可扫描堆大小 作为估算依据，而不是依赖历史数据。这有助于防止因程序行为突变导致 GC 进度落后和堆大小显著超出目标。
• CPU 调度 ：Go 1.5 采用了一个简单而健壮的策略：默认 将 GOMAXPROCS 所代表 CPU 资源的 25% 专门用于后台并发 GC 工作 。这避免了早期设计中复杂且可能不稳定的动态调度策略，确保了 GC 有稳定的 CPU 资源可用。
• 触发器比例控制器（Trigger Ratio Controller） ：计算下一次 GC 触发阈值的具体实现。增加了上下限约束（如触发比例最高 0.95，触发时的堆大小至少比上次标记结束时的活跃堆大 1MB），以保证辅助标记和辅助清扫机制有足够的时间和空间发挥作用，防止比例因子变得过大或过小。同时，计算基于 预估的活跃堆大小 ，而非标记结束时的堆大小，以消除 浮动垃圾（Floating Garbage） （标记开始时存活，但结束时已死亡的对象）对触发决策造成的正反馈影响。

这些改进共同使得 Go 1.5 的 GC 在延迟方面取得了显著进步，对于需要低延迟响应的服务（如 Web 服务）尤其重要。

运行时调整：调度器与默认并行度

Go 1.5 在运行时（Runtime）层面也有两项重要的变更：

1. Goroutine 调度顺序变更 ：

   • Go 1.5 更改了内部 goroutine 的调度顺序实现。需要强调的是，Go 语言规范从未定义过 goroutine 的执行顺序 。任何依赖特定调度顺序的程序都属于 未定义行为（undefined behavior） 。
   • 虽然官方预期影响不大，但确实发现有少量（错误的）程序因依赖旧的调度顺序而在此版本中出现问题。如果你的代码隐式地依赖了 goroutine 的执行顺序，需要进行修改，例如使用明确的同步机制（如 channel、sync 包中的锁或等待组）来保证逻辑的正确性。

2. GOMAXPROCS 默认值调整 ：

   • 这是一个更显著的变化：运行时现在将 GOMAXPROCS 的默认值设置为 当前机器可用的 CPU 核心数 （通过 runtime.NumCPU() 获取）。而在 Go 1.4 及之前的版本中，该值默认为 1 。
   • 调整原因 ：
     早期的 Go 版本中，当 GOMAXPROCS > 1 时，频繁进行 goroutine 切换的程序性能会下降，因为跨 OS 线程切换 goroutine 的成本远高于在同一线程内切换。
     随着 Go 调度器自身的改进（例如引入了 亲和性调度（affinity scheduling） ，倾向于将相互通信的 goroutine 保持在同一个线程上运行），上述性能问题已大大缓解。
     现代 CPU 的核心数不断增加，继续默认单核运行无法充分利用硬件能力，使 Go 在与其他语言的性能对比中处于不利地位。
   • 预期影响 ：
     对于绝大多数 Go 程序，这是一个 积极的改动 ，有望带来性能提升。
     即使是只有一个业务 goroutine 的程序，也可能因为运行时的并行能力（尤其是并发 GC）而受益。
     具有真正并行逻辑的程序，其性能理论上可以随 GOMAXPROCS 的增加而扩展。
     对于历史上担心的 goroutine 切换密集型程序，Go 1.5 的调度器优化已经能较好地处理这种情况，性能不会像早期版本那样受到严重影响。
   • 潜在风险 ：如果程序中存在未正确同步的并发访问，或者隐式地假设了单线程执行模型，那么在 GOMAXPROCS > 1 时可能会暴露竞态条件或其他并发问题。遇到问题的程序可以通过显式设置 GOMAXPROCS=1 来恢复旧的行为，但这通常意味着代码需要修复以支持并发。

这项 GOMAXPROCS 的默认值改动是 Go 拥抱多核并行计算的重要一步。