Go map 底层原理

- [1. 一语戳破哈希表](#1. 一语戳破哈希表)
- [2. 经典版：Go map 到底长什么样](#2. 经典版：Go map 到底长什么样)
- - [2.1 `hmap` 解决什么问题](#2.1 hmap 解决什么问题)
  - [2.2 `bmap` 解决什么问题](#2.2 bmap 解决什么问题)
  - [2.3 `tophash[8]` 到底在干什么](#2.3 tophash[8] 到底在干什么)
  - [2.4 `overflow bucket` 是怎么来的](#2.4 overflow bucket 是怎么来的)
- [3. 扩容不是"多加几个桶"那么简单](#3. 扩容不是“多加几个桶”那么简单)
- - [3.1 为什么旧桶必须搬](#3.1 为什么旧桶必须搬)
  - [3.2 为什么 Go 要做渐进式扩容](#3.2 为什么 Go 要做渐进式扩容)
  - [3.3 增量扩容和等量扩容](#3.3 增量扩容和等量扩容)
- [4. 并发安全：原生 map 为什么不能裸奔](#4. 并发安全：原生 map 为什么不能裸奔)
- [5. 现版本的Go Map-Go 1.24版本之后](#5. 现版本的Go Map-Go 1.24版本之后)
- [6. 回顾 / 自测](#6. 回顾 / 自测)
- [7. 总结](#7. 总结)

虽然大家天天都在用 map，但很多人对它的理解只停在" 查得快"" 底层是哈希表"" 桶里有 8 个槽位"这几句。或许跟别人吹牛的时候，还有几分用处；但真到线上排查延迟抖动、锁竞争、内存占用、热点键冲突，这点认识往往是不够的。

所以这篇文章不准备把 map 写成 runtime 源码导读，也不想把它变成一份机械八股。主线只抓三件事：

它为什么能这么快；
它为什么会冲突；
它为什么需要扩容和同步；

再此声明下，文章主体采用经典 Go map 来讲，也就是大家最熟悉的 hmap / bmap / overflow bucket 这种；

只会在关键处补上 Swiss Table 风格Go从 1.24 开始，就优化为了Swiss Table 方案

1. 一语戳破哈希表

哈希表解决的问题很直接：给我一个 key，我不想从头遍历到尾，我想尽快知道它大概率应该放在哪，查的时候也直接去那个位置附近找。

map[string]int 之所以平均查找复杂度能做到 O(1)，靠的从而不是魔法，而是以下两步：

对 key 做哈希，得到一个哈希值。
用哈希值去定位存储位置。

可真正麻烦的地方不在 "定位" ，而在 "冲突" 。不同 key 经过哈希后，完全可能落到同一个位置。于是，任何一个成熟的哈希表实现都得回答三个问题：

冲突来了怎么放
数据变多了怎么扩
并发访问时怎么保住一致性

Go map 的底层设计，本质上就是围着这三件事在做权衡。

2. 经典版：Go map 到底长什么样

go1.24之前，用的都是经典版本

再此我先强调一句：本模块讲解的是 hmap / bmap / overflow bucket 这套设计。

2.1 `hmap` 解决什么问题

hmap 不负责一条一条存业务数据，它更像整个 map 的总控结构。它关心的是：

现在总共有多少元素
现在有多少个桶
当前桶数组在哪
如果正在扩容，旧桶数组在哪
旧桶搬迁到哪一步了

把源码结构体简化一下，大概就长这样：

go 复制代码

hmap
├── count       // 元素个数
├── B           // 桶数量的对数，桶数约等于 2^B
├── buckets     // 当前桶数组
├── oldbuckets  // 扩容中的旧桶数组
└── nevacuate   // 渐进式迁移进度

如果你把 map 想成一家公司，hmap 不是一线员工，它更像调度层。真正存 key/value 的，是下面的桶。

一句话总结：

hmap 是经典 Go map 实现里的总控结构，真正的 key/value 主要放在 bucket 里，hmap 负责管理桶数组、元素数量和扩容状态。

2.2 `bmap` 解决什么问题

bmap 可以理解成单个桶的结构。一个桶里最多放 8 组 key/value，这也是很多人记住的那个点。

把源码简化一下，大概长这样：

text 复制代码

bmap
├── tophash[8]
├── key[0] ... key[7]
├── value[0] ... value[7]
└── overflow *bmap

这里有两个常见误区。

第一个误区是：

一些新手可能认为一个桶里的元素的完整哈希值都是一样？！

NO！当然不是。更准确的说法是，这些 key 的哈希结果里，用来"选桶"的那一部分相同，所以它们落进了同一个桶；完整哈希值可以不同。

我举个简化例子。

假设当前一共只有 8 个桶，也就是只看哈希结果的低 3 位来选桶：

text 复制代码

keyA 的 hash = 10101100
keyB 的 hash = 01111100

这两个完整哈希值显然不一样，但它们低 3 位同样是 100，于是还是会进入同一个 bucket。冲突的本质从来都不是"哈希值完全一样"，而是"映射到了同一个桶"。

第二个误区是：

桶就是个小链表。

这也不对。经典 Go map 的主路径还是连续内存里的桶，overflow bucket 只是桶满之后的补救手段，不是把链表当成主存储结构。

原因也很现实，链表节点分散，指针跳转多，对现代 CPU cache 不友好。

2.3 `tophash[8]` 到底在干什么

很多人都了解过 tophash[8]，但没真理解它解决了什么问题。

它解决的问题是：进了桶以后，不想每个槽位都直接拿真实 key 去做重比较。尤其 key 是字符串、长结构体的时候，直接比 key 就会很费劲。

所以经典实现会先做一层粗筛：

哈希值的低位先拿去选桶
哈希值里再取一小段高位摘要，存进 tophash[i]
桶内查找时先比 tophash
只有摘要对上了，才继续比真正的 key

也就是说，tophash[8] 不是完整哈希值，它更像 8 个槽位各自的"门牌号缩写"。

另外它还会兼任一些状态位，比如标记空槽位或搬迁状态。

一句话总结：

tophash[8] 是桶内 8 个槽位对应的哈希摘要数组，作用是先粗筛，再做真实 key 比较，减少无效比较成本。

2.4 `overflow bucket` 是怎么来的

一个桶最多就 8 组 key/value。那第 9 个、10 个怎么办？经典实现的做法是挂 overflow bucket。

这也是经典版 Go map 中最容易被记成一段死知识的话：超过 8 个后通过 overflow bucket 处理。这个结论本身没错，但如果只记到这里，基本只是停留在记忆层面。

更有价值的理解其实是：
overflow bucket 只是冲突压力的缓冲区，不是最终解法。

因为一旦同一个桶后面挂了很多 overflow，查找路径就会变长，插入和删除也都会更慢。它能救场，但不适合长期背锅。

所以真正的解法还是扩容和重新分布数据。

如果想要一个更直观的例子，可以这样想。

下面这个示例不是 Go runtime 的真实哈希过程，只是为了说明"多个 key 进同一个桶"的现象：

go 复制代码

m := map[int]string{
    1:  "a",
    9:  "b",
    17: "c",
}

如果把整数的低位简化成选桶依据，在只有 8 个桶的时候，1、9、17 都可能落到同一个桶里。桶内位置先用完，后来的冲突元素就只能先挂到 overflow bucket。

然后越来越长...

3. 扩容不是"多加几个桶"那么简单

大家经常会有这样一个疑问：

为什么旧桶里的数据要搬到新桶里？为什么不能以后新数据放新桶，旧数据继续留在旧桶？

这个问题其实很有价值，因为它正好卡在很多人"只会背结论，但没想通原因"的地方。

3.1 为什么旧桶必须搬

因为桶数量一变，key 到桶的映射规则也会变。

假设原来有 4 个桶，某个 key 按旧规则落在桶 1。现在扩容成 8 个桶，同一个 key 按新规则再算，可能就不在 1，而是到了 5。

可以用一个二进制例子理解：

text 复制代码

某 key 的 hash = 0101

原来 4 个桶，只看低 2 位：01 -> 桶 1
扩容成 8 个桶，看低 3 位：101 -> 桶 5

如果旧数据不搬，新查找逻辑会按 8 个桶的规则去桶 5 找，但数据还躺在旧桶 1 里，结果就是查不到。

问题不是"老数据懒得搬"，问题是映射规则已经变了。

所以扩容的本质不是"以后多几个位置可用"，而是"整张表的分布规则变了，旧数据也得跟着重分布"。

3.2 为什么 Go 要做渐进式扩容

如果一次性把整张大 map 全量搬完，单次写操作的延迟会很难看。

对于后端服务来说，这种抖动很危险，尤其是在高峰流量下。

经典 Go map 里的做法正是渐进式搬迁：

先分配新桶数组
旧桶数组暂时保留
后续的插入、删除、更新过程中，顺手搬一点旧数据(一般是两个)
搬完以后，oldbuckets 不再被引用，后续交给 GC 回收

这样单次操作的成本更平滑，不容易在某一个请求上突然炸出大延迟。

3.3 增量扩容和等量扩容

经典实现里，扩容不止一种。

增量扩容 出现在整体装载因子上来了，桶数真的不够用了。这时桶数量会翻倍，旧桶里的元素搬迁后，通常只会落到两个位置之一：原位置，或者原位置加上旧桶数。

等量扩容 则更像一次"整理内务"。桶总数不变，但 overflow 太多了，说明历史冲突、删除留下的空洞、桶内分布不紧凑，已经把链拉长了。这时运行时会分配一套同样大小的新桶，把旧桶和 overflow 里的有效数据重新压实。它不一定让理论容量变大，但会把历史包袱清掉。

一句话概括：

增量扩容是在加容量
等量扩容是在去包袱

4. 并发安全：原生 map 为什么不能裸奔

Go 原生 map 并不保证并发安全。

虽然这句话大家都知道，但最好不要只停在"官方就是这么规定"上。

更实在的理解是：

map 内部会维护桶、搬迁状态、溢出结构这些运行时不变量。多个 goroutine 一边读一边写，或者同时写，很容易把这些状态搞乱。轻则数据竞争，重则运行时直接报 concurrent map writes。

工程上最常见的做法还是 map + sync.RWMutex：

go 复制代码

type SafeMap struct {
    mu sync.RWMutex
    m  map[string]int
}

它的优点很朴素：

强类型，编译期友好
复合逻辑容易放进同一个临界区
业务不变量也能一起保护

它的代价也很明确：锁粒度 通常就是整张 map。

sync.Map 不是"语法更高级的 map"，它是标准库提供的并发专用结构。

当前 Go 版本里，sync.Map 底层已经基于 internal/sync.HashTrieMap，不是很多旧文章里那套 read + dirty 的双层结构了。

它更适合两类场景：

某个 key 写入一次，之后被大量读取，比如只增不改的缓存
不同 goroutine 主要操作不同 key 集合，锁竞争能被明显摊薄

如果你的场景是复杂业务状态、强类型、多个字段需要一起维护，map + sync.RWMutex 往往还是更稳的选择。
sync.Map 的价值不在于"它更高级"，而在于它是一个为并发访问模式 做过专门优化的结构。

如果再往下看一层，HashTrieMap 的思路也值得知道：

它不是一张大表外面套一把大锁，而是一棵并发哈希 Trie 。读路径大量依赖原子读，写入时只锁局部节点。这也是它在高并发、读多写少场景里更容易把争用压下去的原因。
(锁局部，而非全局)

5. 现版本的Go Map-Go 1.24版本之后

上方大部分文章采用的都是经典 Go map。虽然这些依旧适合学习，也非常适合大多数面试场景。但毕竟是旧版本了。

如果别人追问的是"当前新版本 Go 的 map 实现"，我们就不能把 hmap + bmap + overflow bucket 说成唯一答案了。

因为从 Go 1.24 开始，官方内置 map 已经切到基于 Swiss Table 的实现。新版本中：

group，每组 8 个 slot
control word，用来并行检查组内槽位状态
open addressing / probing，也就是开放寻址和探测
为了保住增量增长的延迟特性，Go 自己又做了适配，不是直接照搬 C++ 版本

这里最容易被问到的一个小坑是"为什么有人说 16 个槽位"。

那通常是在说别的 Swiss Table 实现，比如 Abseil 的一些设计讨论；

Go 当前内置 map 的 group 大小仍然是 8，不是 16。

总结：

Go map 本质上一直都是哈希表。经典实现可以用 hmap / bmap / overflow bucket 解释；如果按 Go 1.24+ 之后的实现，更准确的说法就要基于 Swiss Table 的 group + control word + probing了。

6. 回顾 / 自测

对于Go Map你更应该了解什么？

在读完本篇文章之后，希望你可以打破：

Go map 底层是哈希表，核心结构是 hmap，桶是 bmap，一个桶 8 个 key/value，超过了走 overflow bucket。

不只是知道这样的表层认知。你也可以在琢磨以下问题：

同一个桶里的元素不要求完整哈希值一样，只是选桶那部分结果一样
tophash 是桶内快速筛选，不是完整哈希值
overflow bucket 不是终局方案，overflow 多了会拖慢查找，所以需要扩容
扩容后旧数据必须搬，因为映射规则变了
Go 做的是渐进式扩容，目的是控制单次操作延迟
原生 map 不并发安全，sync.Map 也不是所有场景都比 map + RWMutex 更适合
如果再补一句 Go 1.24+ 已经切到 Swiss Table，这个回答就更完整

希望你可以把这些设计背后的"为什么"给琢磨出来。

7. 总结

如果只给你 40 秒，可以这么说：

Go map 本质上是哈希表。按经典实现方式来说，顶层是 hmap，下面维护 bucket，也就是 bmap。一个桶最多放 8 组 key/value，key 先通过哈希定位到桶，桶内再借助 tophash 做快速筛选；如果桶满了，会先挂 overflow bucket。但 overflow 多了会影响性能，所以 Go 会触发扩容，并通过渐进式迁移把旧桶数据逐步搬到新桶里。原生 map 不支持读写并发安全，工程上通常用 map + sync.RWMutex，特定读多写少场景可以考虑 sync.Map。如果按 Go 1.24+ 的之后版本的实现，则内置的 map 已经演进到 Swiss Table 风格了。`

如果你是为了优化项目而来，则本篇文章真正值得带走的就不是上方那一段标准答案了，而是下面这四个判断：

map 快，是因为先算哈希再定位，不是因为它"天然免费"
冲突不可避免，桶、摘要和扩容都是围着冲突成本做优化
扩容的难点从来不是"申请更多空间"，而是"低延迟地重分布旧数据"
并发安全不是 map 自己送的能力，什么时候该锁、什么时候该用 sync.Map，要按访问模式判断

1、新版本：(hashtriemap.go)

Go map 底层原理

Go map 底层原理

1. 一语戳破哈希表

2. 经典版：Go map 到底长什么样

2.1 hmap 解决什么问题

2.2 bmap 解决什么问题

2.3 tophash[8] 到底在干什么

2.4 overflow bucket 是怎么来的

3. 扩容不是"多加几个桶"那么简单

3.1 为什么旧桶必须搬

3.2 为什么 Go 要做渐进式扩容

3.3 增量扩容和等量扩容

4. 并发安全：原生 map 为什么不能裸奔

5. 现版本的Go Map-Go 1.24版本之后

6. 回顾 / 自测

7. 总结

2.1 `hmap` 解决什么问题

2.2 `bmap` 解决什么问题

2.3 `tophash[8]` 到底在干什么

2.4 `overflow bucket` 是怎么来的