Go 1.3 相比 Go1.2 有哪些值得注意的改动？

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

https://go.dev/doc/go1.3
Go 1.3 版本在 Go 1.2 发布六个月后推出， 该版本重点在于实现层面的改进，没有包含语言层面的变更。 主要改进包括：实现了精确的垃圾回收（GC），对编译器工具链进行了大规模重构以加快编译速度（尤其对于大型项目），全面的性能提升，增加了对 DragonFly BSD、Solaris、Plan 9 和 Google Native Client（NaCl）的支持。此外，还对内存模型在同步方面进行了重要优化。
Go 1.3 值得关注的改动：

• 内存模型的变更： Go 1.3 内存模型增加了一条关于缓冲通道（buffered channel）发送和接收的新规则，明确了缓冲通道可以用作简单的信号量（semaphore）。 这并非语言层面的改动，而是对预期通信行为的澄清。
  
• 栈（Stack）实现的变更： Go 1.3 将 goroutine 栈的实现从旧的“分段栈”模型改为了“连续栈”模型。 当 goroutine 需要更多栈空间时，其整个栈会被迁移到一个更大的连续内存块，消除了跨段边界调用时的“热分裂”性能问题。
  
• 垃圾收集器（Garbage Collector）的变更： Go 1.3 将精确 GC 的能力从堆（heap）扩展到了栈（stack），避免了非指针类型（如整数）被误认为指针而导致内存泄漏，但同时也对 unsafe 包的使用提出了更严格的要求。
  
• Map 迭代顺序的变更： Go 1.3 重新引入了对小容量 map（元素个数小于等于 8）迭代顺序的随机化。 这是为了修正 Go 1.1 和 1.2 中未能对小 map 实现随机迭代的问题，强制开发者遵循“map 迭代顺序不保证固定”的语言规范。
  
• 链接器（Linker）的变更： 作为工具链重构的一部分，编译器的指令选择阶段通过新的 liblink 库被移动到了编译器中。 这使得指令选择仅在包首次编译时进行一次，显著提高了大型项目的编译速度。
  

下面是一些值得展开的讨论：
内存模型：明确缓冲通道可作信号量

https://codereview.appspot.com/75130045
Go 1.3 对内存模型进行了一项重要的澄清，而非语言层面的改动。它正式确认了使用缓冲通道（buffered channels）作为同步原语（例如信号量或互斥锁）的内存保证。具体来说，内存模型增加了一条规则（或者说，明确了一条长期以来的隐含规则）：对于容量为 C 的缓冲通道 ch，从通道进行的第 k 次接收操作的完成 happens-before 第 k+C 次发送操作的开始 。
要理解这条规则的重要性，首先需要明白什么是 内存同步 (memory synchronization) 。在 Go 的并发模型中，内存同步指的是确保一个 goroutine 对 共享内存 (shared memory)（即多个 goroutine 可能访问的变量）所做的修改，能够被其他 goroutine 以可预测的方式观察到。这种保证是通过 happens-before 关系建立的。如果操作 A happens-before 操作 B，那么 A 对内存的所有副作用（如写入变量）必须在 B 开始执行之前完成，并且对 B 可见。Channel 操作、sync.Mutex 的 Lock/Unlock 等都是用来建立这种 happens-before 关系的同步原语。
对于互斥锁 (Mutex) 的场景 (C=1):
当缓冲通道的容量 C = 1 时，它可以被用作一个互斥锁：
<ul>limit