第 5 章数据结构 on Go 语言原本

5.1 数组与切片

Mon, 01 Jan 0001 00:00:00 +0000

5.1 数组与切片

数组与切片是 Go 里最基础的两种序列类型。它们看起来相似，内存模型却各不相同，理解这点能一举解释 append 的种种「惊喜」与切片别名的陷阱。两者共享一个主题：一个小小的头部描述一段连续的后备内存。差异全在头部里装了什么、谁拥有那段内存。本节先把布局摆清楚，再从「动态数组」这一经典抽象出发，看 Go 的 append 如何在摊还意义下做到 $O(1)$ ，最后落到别名与跨语言对照这些日常会撞上的角落。字符串虽与切片同源，但它不可变、自成一类，留到 5.2 专门讨论。

5.1.1 三种内存布局

数组是值。 [5]int 就是连续排布的 5 个 int，长度是类型的一部分：[5]int 与 [6]int 是两个不同的类型。赋值、传参、作为 struct 字段，数组都整份拷贝。正因如此，大数组在 Go 里反而少用，传来传去太贵，真要传通常传它的切片或指针。

切片是对某段底层数组的视图。 运行时里它就是一个三字的头部，可对照 runtime/slice.go：

// runtime: 切片的运行时表示（slice.go）
type slice struct {
    array unsafe.Pointer // 指向底层数组中本切片的首元素
    len   int            // 长度：可见元素个数
    cap   int            // 容量：从 array 起到底层数组末尾的元素个数
}

len 是你能索引到的范围，cap 是「在不重新分配的前提下还能涨到多大」。两者分离正是切片能做「视图」的关键：s[1:3] 只是改头部里的三个字段，不碰底层数组。

5.2 字符串与零拷贝转换

Mon, 01 Jan 0001 00:00:00 +0000

5.2 字符串与零拷贝转换

字符串与切片同源，运行时里都是「头部 + 别处的内存」（布局见 5.1.1），但它只读、不可变，自成一类。不可变换来共享与免拷贝的好处，也带来一个直接代价：string 与 []byte 互转默认要拷贝一份字节。本节剖开这份拷贝，看编译器在哪些场景下能把它省掉，再到 Go 1.20 给出的手动零拷贝工具，以及由此而来的安全契约。

5.2.1 字符串与 []byte 的转换

字符串不可变带来一个直接代价：string 与 []byte 互转默认要拷贝一份字节。原因正是不可变, []byte 可写，若让它直接指向某个字符串的底层字节，改 []byte 就等于改了那个「不可变」的字符串，破坏了一切共享假设。所以运行时老老实实 memmove 一份：

// runtime: []byte → string（string.go，节选）
func slicebytetostring(buf *tmpBuf, ptr *byte, n int) string {
    // ...
    p := mallocgc(uintptr(n), nil, false) // 分配新内存
    memmove(p, unsafe.Pointer(ptr), uintptr(n)) // 拷贝字节
    return unsafe.String((*byte)(p), n)
}

这份拷贝在热路径上可能可观。好在编译器认得几类「转换后字节立刻被读、不可能被改」的模式，把拷贝省掉。最常见的两个是用 []byte 临时当 map 键查询，与对 []byte(s) 直接 range：

5.3 散列表：原理与安全

Mon, 01 Jan 0001 00:00:00 +0000

5.3 散列表：原理与安全

Go 的 map 在 2024 年随 Go 1.24 完成了一次罕见的彻底重写，从沿用十四年的经典桶式散列表换成了基于 Swiss Table 的实现。本节先讲清散列表的一般原理与攻防，重写的来龙去脉留到 5.4 专门交代。

map 是 Go 仅有的两种泛型容器之一（另一种是 slice）。它由运行时实现、编译器辅助布局，本质是一张散列表。读者写下 m[k] 时，编译器把它翻译成对 runtime.mapaccess、 runtime.mapassign 一族函数的调用，真正的存储、查找、扩容都发生在 internal/runtime/maps 包里。这一节先把散列表的一般原理与攻防讲清楚，为下一节落到 Go 自己的两代实现（1.0 至 1.23 的经典桶式设计，以及 1.24 起的 Swiss Table 设计）打底。理解了这里的取舍，才能看清后者为何值得一次伤筋动骨的重写。

5.3.1 散列表的两条路线：链地址与开放定址

散列表要解决的核心矛盾，是把一个几乎无穷大的键空间压进一段有限的连续内存。哈希函数 $h$ 把键映射到 $[0, m)$ 的槽位下标，理想情况下一次访存即可定位。但映射不可能单射，两个键算出同一下标即是「碰撞」，如何安置碰撞的键，分出了两条历史悠久的路线。

链地址法（chaining）让每个槽位挂一条链表，碰撞的键依次串在链上。它实现简单、删除干净、对哈希质量不敏感，代价是每个元素多一个指针、缓存局部性差（链表节点散落在堆上）。设装填因子 $\alpha = n/m$ （元素数比槽位数），在均匀哈希假设下，一次不成功查找平均要比较 $\approx \alpha$ 个元素，成功查找 $\approx 1 + \alpha/2$ 个。链地址法允许 $\alpha > 1$ ，性能随 $\alpha$ 线性退化。

5.4 Swiss Table 与 Go 1.24 实现

Mon, 01 Jan 0001 00:00:00 +0000

5.4 Swiss Table 与 Go 1.24 实现

5.3 讲清了散列表的一般原理与攻防：两条碰撞处理路线，以及哈希洪水的防御。本节落到 Go 自己的两代实现，先剖开 Swiss Table 这一现代开放定址设计，再看 Go 1.24 如何把它落地、为此取代了什么，以及由实现倒推出的两条语言规则，最后把 Go 放进各家散列表的更大图景里对照。

5.4.1 Swiss Table 设计（abseil）

Swiss Table 由 Google 的 abseil 团队提出，Kulukundis 在 CppCon 2017 上公开。它是开放定址法的现代化身，核心创新是把「哪个槽是空的、哪个槽该比较」这件事，从逐槽试探变成一次并行操作。

它把哈希值劈成两段：高 57 位 H1 决定从哪一组（group）开始探测，低 7 位 H2 作为该键的「指纹」。槽位以 8 个为一组排列，每组配一个 8 字节的控制字（control word），其中每个控制字节对应组内一个槽：

空槽    empty    1000 0000   （0x80）
墓碑    deleted  1111 1110   （0xfe）
占用    full     0hhh hhhh   （最高位 0，低 7 位即该键的 H2 指纹）

最高位区分「空/墓碑」与「占用」，占用槽的低 7 位直接存指纹。查找一个键时，先算 H1 定位到起始组，再拿 H2 与整组 8 个控制字节并行比较：在支持 SIMD 的机器上，这是一条 PCMPEQB 指令（16 字节甚至能比 16 个槽），一步完成本应 8 步的探测。比较结果是一个位掩码，标出哪些槽的指纹匹配；逐个核对这些候选槽的真实键即可。指纹只有 7 位，约 $1/128 \approx 0.7\%$ 的概率假阳性，但既然匹配后总要做一次完整键比较，假阳性只是偶尔多比一次，不影响正确性。

第 5 章 数据结构 on Go 语言原本

5.1 数组与切片

5.1 数组与切片

5.1.1 三种内存布局

5.2 字符串与零拷贝转换

5.2 字符串与零拷贝转换

5.2.1 字符串与 []byte 的转换

5.3 散列表：原理与安全

5.3 散列表：原理与安全

5.3.1 散列表的两条路线：链地址与开放定址

5.4 Swiss Table 与 Go 1.24 实现

5.4 Swiss Table 与 Go 1.24 实现

5.4.1 Swiss Table 设计（abseil）

第 5 章数据结构 on Go 语言原本