5.1 数组、切片与字符串

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

5.1 数组、切片与字符串

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

5.1.1 三种内存布局

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

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

1
2
3
4
5
6


// 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 散列表

本节内容对标 Go 1.26。Go 的 map 在 2024 年随 Go 1.24 完成了一次罕见的彻底重写，从沿用十四年的经典桶式散列表换成了基于 Swiss Table 的实现。本节在讲清散列表的一般原理之后，会同时交代旧设计与这次重写的来龙去脉（见 5.2.4）。

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

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

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

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

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

5.1 数组、切片与字符串

5.1 数组、切片与字符串

5.1.1 三种内存布局

5.2 散列表

5.2 散列表

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

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