06 map：渐进式扩容与并发写崩溃之谜

开篇提问

先看一段几乎所有 Go 程序员都写过的代码：

m := make(map[string]int)
 
go func() {
    for {
        m["a"] = 1
    }
}()
 
go func() {
    for {
        _ = m["a"]
    }
}()
 
select {}

问题：这段代码会发生什么？

A. 正常运行，偶尔读到脏数据 B. 运行时 panic：concurrent map writes C. 数据竞争，结果不可预测 D. 死锁

你的直觉大概率是 A 或 C——“并发写 map 就是数据竞争嘛，最多读脏数据”。但 Go 的实际行为是 B：直接 panic。

为什么 Go 不选择”容忍数据竞争”，而要故意 panic？这背后是一个关于”检测 vs 容忍”的深刻设计决策。这一章，我们就从 map 的底层实现讲起，一直讲到这个决策。

子主题一：map 的底层结构——哈希表 + 桶

Go 的 map 底层是哈希表，核心结构是”桶（bucket）”。

每个 map 有一组桶，每个桶能装 8 个键值对。
计算 key 的哈希值，用哈希值的低位决定”落在哪个桶”，高位用作桶内的”指纹”加速比较。
一个桶装满了怎么办？通过**溢出桶（overflow bucket）**链式扩展——桶满了就链一个新桶。

这个设计是”开放地址法”和”链地址法”的混合：主桶是数组（用哈希低位定位），桶内 8 个槽位做线性探测，装不下再链溢出桶。这么设计是为了减少指针跳转、提升缓存局部性——8 个键值对挤在一个桶里，一次内存访问就能读到多个候选，比”每个键值对一个链表节点”要快得多。

这里有个非常关键的细节：key 必须是可比较的类型（能算哈希、能判相等）。map 的 key 不能是 slice、map、func，因为它们的哈希和相等性没有稳定的定义。而 string、整型、指针、含可比较字段的 struct 都可以。

子主题二：渐进式扩容——为什么 map 不一次性搬完

哈希表有个经典问题：扩容。当元素增多、负载因子（元素数/桶数）超过阈值，就要扩容，否则碰撞加剧、性能下降。

朴素的扩容是”一次性分配更大的新表，把所有旧元素 rehash 搬过去”。这有个致命问题：搬的过程很慢，而且搬的过程中 map 处于”两个表并存”的尴尬状态，如果此刻还有读写进来，逻辑就复杂了。

Go 的做法是渐进式扩容（incremental rehash），也叫增量搬迁：

触发扩容时，分配一个新的、更大的桶数组，但不立刻搬数据。
map 里记录”旧桶数组”和”新桶数组”，以及”搬迁进度”。
之后每一次对该 map 的读写操作，都顺带搬走一部分旧桶（比如当前访问到的那个桶及其相邻桶）。
当所有旧桶都搬完，释放旧数组，扩容完成。

这样，扩容的巨额成本被摊薄到每一次后续操作里，任何单次操作都不会因为扩容而出现”卡一下”的尖峰。这和第一章”连续栈翻倍摊还”、第五章”slice 扩容摊还”是同一套思想——把一次性的大成本，拆成无数次的微小成本，摊到持续的操作流里。

渐进式扩容是 Go map 设计里最精妙的一笔，也是为什么 Go 的 map 在”数据量大、持续写入”的场景下，能保持平滑性能的原因。

子主题三：为什么并发写 map 会 panic

现在回到开篇那个问题。为什么 Go 宁可 panic，也不容忍”并发写 map”的数据竞争？

答案藏在 map 的底层结构里：渐进式扩容让 map 有了”可变的内部状态”（两个桶数组、搬迁进度指针），并发写会把这个状态撕碎。

具体说，如果两个 goroutine 同时写：

一个 goroutine 正在搬迁桶，另一个 goroutine 往旧桶里写——旧桶正要被释放，写进去的数据就丢了；
两个 goroutine 同时搬迁同一个桶，搬迁进度指针会被双重移动，导致桶被搬两次或漏搬；
一个 goroutine 扩容分配了新数组，另一个 goroutine 还在用旧数组的哈希定位——两个 goroutine 看到的是两个不同的 map 内部世界。

这些不是”读到脏数据”这种温和的结果，而是内部状态被破坏、导致内存错乱、甚至程序崩溃的严重后果。数据竞争在这里的结果不是”结果不确定”，而是”结构被撕碎”。

所以 Go 团队的选择是：在 map 里加一个轻量级的”写标记”检测——发现并发写，直接 panic，把”不可预测的崩溃”变成”可预测的、带明确报错的 panic”。

这个设计决策的深层逻辑是：

当一个操作的错误后果是”结构损坏、不可恢复”时，宁可显式地、立刻地失败（fail fast），也不要在错误的道路上继续跑，留下一堆无法排查的脏状态。

“快速失败”远比”静默损坏”好——因为你至少知道”这里出了问题”，而且是在问题发生的那一刻知道，而不是在很久之后、在一个完全不相关的代码位置崩溃。

子主题四：那并发读呢？sync.Map 又是什么

并发读是安全的。 多个 goroutine 同时读同一个 map，只要没有同时写，就是安全的。这也是很多”读多写少”场景能直接用普通 map 的原因。

并发读 + 并发写，不 panic 但也是数据竞争。 注意一个细微但重要的点：Go 的 map 检测的是”并发写写”，它 不保证 检测到”一读一写”的竞争。也就是说：

// goroutine 1 写，goroutine 2 读

这可能触发 panic（如果检测器捕捉到了写竞争），也可能不 panic，但无论如何它都是数据竞争（data race）——是 bug。别以为”没 panic 就安全”。go test -race 能揪出这类问题，这才是权威裁判。

sync.Map：为特定负载优化的并发 map。

sync.Map 不是”把普通 map 加锁”这么简单，它是为一个非常具体的场景设计的：键的集合相对稳定、写入少（尤其是”写一次读多次”）、读远多于写。

它的内部是”读 map + 脏 map + 原子指针”的双层结构：读走无锁的读 map（原子读），写走加锁的脏 map，脏 map 攒够了再原子地替换。这种”读无锁、写有锁”的不对称设计，让它在”读多写少”场景下远快于”普通 map + RWMutex”。

但反过来，如果写入频繁，sync.Map 反而比普通 map + 锁更慢（因为双层结构的维护有开销）。所以官方文档明确建议：大多数情况下，直接用 map + sync.Mutex 或 sync.RWMutex 就够了，只有确定命中”读多写少、键集合稳定”的场景，才考虑 sync.Map。

这里又是一个 Go 设计哲学：没有银弹，只有为特定负载优化的专用工具，且工具本身会明明白白告诉你”什么时候别用我”。

子主题五：map 的遍历——无序是”故意的”

你有没有发现，Go 的 map 遍历顺序是不确定的，甚至两次遍历同一个 map，顺序都可能不同？

这不是 bug，是故意的。原因和前面讲的渐进式扩容有关：map 的遍历是从某个随机桶开始，且搬迁过程会打乱遍历的中间状态，遍历顺序天然不稳定。

Go 团队不仅没去”修复”这个无序，反而主动强化了它——每次遍历都从一个随机桶开始。为什么？因为如果遍历顺序稳定，程序员就会依赖它，写出”依赖 map 遍历顺序”的脆弱代码。主动随机化，是从根上掐断这种依赖，让你”根本没法依赖它”。

这是 Go 设计里非常有个性的一笔：它不只是”不承诺有序”，而是”故意无序”，用随机性来强迫开发者不要假设顺序。 类似的哲学，你在 Go 的很多角落都能看到——宁可少给一点确定性，也要避免你依赖一个不该依赖的东西。

子主题六：哈希函数与随机种子——为什么每次启动都不一样

先做个小实验。同一段代码，插入顺序完全固定，连跑两次：

m := map[string]int{}
for _, k := range []string{"alpha", "beta", "gamma", "delta", "epsilon"} {
    m[k] = len(k)
}
for k := range m {
    fmt.Print(k, " ")
}

你会说：顺序不同很正常啊，子主题五不是说了遍历起点是随机的吗？

那我把问题刁钻一点：假如我们把”遍历起点”固定住（假设有个内部开关），两次运行的顺序会一样吗？

还是不一样。因为还有第二层随机——哈希种子。

每个 map 在被创建时，运行时会从全局随机源里取一个随机数，塞进 map 头部结构里的一个字段（可以理解为 hash0）。此后这个 map 计算任何一个 key 的哈希值，都要拿这个种子参与运算。进程重启一次，种子换一次，于是所有 key 的哈希值全部改变，它们在桶里的分布也全部重排。

好端端的，为什么要给哈希加随机种子？

一次教科书级的攻击

想象你写了个 HTTP 服务，把请求参数塞进 map：

params := map[string]string{}
for k, v := range r.URL.Query() {
    params[k] = v[0]
}

或者更常见的：JSON 反序列化到 map[string]any。这时 map 的 key 完全由客户端控制。

如果哈希函数是确定的、公开可知的（某个语言里 hash("abc") 永远等于同一个值），攻击者就可以在自己电脑上离线穷举：算出成千上万个”哈希值落在同一个桶”的字符串。然后把这些字符串作为 query 参数、作为 JSON 的字段名，一次性发给你。

结果会怎样？

你的 map 本来是”平均 O(1)“的查找。现在几万个 key 全部落进同一个桶，这个桶装不下就链溢出桶，溢出桶再链溢出桶——这个 map 从哈希表退化成了一条链表。插入 n 个 key 的代价从 O(n) 变成 O(n²)。

攻击者只需要发一个几百 KB 的请求，就能让你的一个 CPU 核跑上几十秒。几个并发请求，整台机器就跪了。这不是理论推演——2011 年前后这一招打穿了当时几乎所有主流语言的 Web 框架，PHP、Java、Python、.NET、Ruby 都中招，各自发了安全公告。

这就是哈希碰撞攻击（Hash DoS）。

随机种子是怎么破这个局的

核心一句话：随机种子让攻击者无法离线预计算。

整条攻击链成立的前提是”攻击者能提前算好哪些 key 会碰撞”。而这个前提又依赖”哈希函数在攻击者机器和目标机器上是同一个函数”。随机种子把这个前提砸碎了：你每次启动进程，哈希布局都变一次；攻击者不知道种子，就算不出任何一对碰撞 key，只能靠运气。

这是安全工程里一个非常经典的权衡，值得你反复咂摸：

与其让攻击”不可能得手”，不如让攻击”无法预谋”。

彻底杜绝碰撞是不可能的——鸽笼原理摆在那儿，哈希一定有碰撞。但把”可预谋的确定性攻击”降级成”撞大运的随机事件”，威胁模型就完全变了。

顺带反问一句：那为什么不用加密级哈希？

你可能会问：既然要防攻击，直接上带密钥的强哈希（HMAC 那一类）不就一劳永逸了？

不。因为那样每一个 map 用户都要为安全买单——哈希计算变慢几倍，所有场景都变慢，包括那些 key 完全由自己生成、根本不可能被攻击的场景（比如 map[uint64]*Conn）。

Go 的选择是：快速哈希 + 运行时随机种子。安全成本几乎为零（种子只在创建 map 时取一次随机数，之后每次哈希只是多混进一个常数），却切断了”离线构造碰撞”这条路。

这也是 Go 一贯的取舍风格：不给所有人加税，而是用一个便宜的机制解决大部分问题，剩下的边界情况交给使用者自己判断。

这个设计给你的三条实战启示

永远不要依赖 map 的遍历顺序，也不要依赖”顺序看起来是稳定的”。 你本地跑一百次都一样，上线后重启一次就变了。测试里凡是断言 map 顺序的，迟早要挂。
不要用 map 的遍历顺序做”隐式优先级”。 比如”遍历 map，找到第一个满足条件的就用”——这个”第一个”是随机的，你的程序行为就不可复现。需要优先级就显式排序。
随机种子防的是恶意碰撞，不防善意碰撞。 你自己的 key 分布很烂（比如所有 key 都是同一前缀的长字符串），该碰撞还是碰撞，该慢还是慢。这时候要靠 key 设计，不能指望种子。

子主题七：桶（bucket）结构解剖——为什么偏偏是 8 个

（说明：以下结构描述的是 Go 长期以来的经典实现（哈希表 + bmap 桶）。Go 1.24 起运行时内部换用了基于 Swiss Table 的新实现，但”8 个槽位成组""渐进搬迁""随机种子""遍历随机化”这些设计思想被完整继承了下来，具体字段与阈值随版本持续演进。理解经典实现，仍然是理解这些权衡的最佳路径。）

先把问题问出来

子主题一里我们说”每个桶装 8 个键值对”。你当时有没有追问一句：为什么是 8？ 不是 4，不是 16，不是 32？

这个数字不是拍脑袋来的，它是内存层次结构逼出来的平衡点。我们把一个桶拆开看：

+----------------------------+
| tophash[8]  : 8 × 1 字节   |  <- 8 个"指纹"
+----------------------------+
| keys[8]     : 8 × key      |  <- 8 个键，连续存放
+----------------------------+
| values[8]   : 8 × value    |  <- 8 个值，连续存放
+----------------------------+
| overflow    : 1 个指针     |  <- 指向溢出桶
+----------------------------+

三个细节，每一个都有讲究。

细节一：tophash 是”门口的 8 个名牌”

tophash 是 8 个单字节指纹，每个槽一个，取的是该 key 哈希值的高位若干比特（哈希值的低位用来定位桶，高位用来当指纹，两者分工不冲突）。

它解决什么问题？解决昂贵的完整比较问题。

查找的完整流程本该是：定位桶 → 挨个槽位把 key 取出来 → 调相等函数比较 → 命中返回。但”取出 key 比较”可能很贵：key 是 string 要读字符串头、可能要跳到堆上逐字节比；key 是 struct 要逐字段比；key 是指针要解引用。每一次完整比较，都可能是一次 cache miss。

有了 tophash，流程变成：定位桶 → 一次性把 8 个指纹读进来 → 用一次位运算筛出”指纹可能匹配的槽” → 只对这几个槽做完整比较。

妙在哪儿？8 个字节正好是一个 64 位寄存器的宽度。这 8 个指纹在内存里连续，一次载入寄存器，配合位技巧能并行判断 8 个槽哪几个有可能命中。绝大多数情况下匹配的只有 0 个或 1 个，于是昂贵的完整比较一次都不用做。

生活化一点：**桶是一套 8 人合租的公寓，tophash 是门口信箱上的 8 个姓氏贴纸。**你要找”张三”，先在门口扫一眼贴纸（一个动作，8 个全看完），没有张姓就走人，不用挨个敲门问”请问您是张三吗”。敲一次门的代价，和扫一眼贴纸的代价，差一个数量级。

细节二：8 这个数字，是缓存行和利用率的拉锯

现在正面回答”为什么是 8”。

CPU 从内存取数据不是按字节取的，是按**缓存行（cache line，常见 64 字节）**整块取。你读桶里第 1 个字节，相邻几十字节也顺带被拉进缓存了。

于是有个极其诱人的想法：让”一次查找所需的全部信息”尽可能落在一两个缓存行里。

桶只有 1 个槽（退化成”每个键值对一个链表节点”）：每查一个节点都是一次指针跳转，节点在内存里散落各处，每次跳转一次 cache miss。这就是教科书里朴素链地址法在现代 CPU 上慢得离谱的原因——CPU 大部分时间在等内存。
桶有 64 个槽：缓存局部性确实好，但代价是浪费——只要一个槽被占用，这一大块内存就占着；哈希分布不均匀时，空槽浪费被放大几十倍。更要命的是，桶太大，“搬迁一个桶”的粒度就太粗，渐进式搬迁的摊薄效果就没了（搬一次 = 搬 64 个槽，那一刀下去照样卡顿）。
8 个槽：指纹 8 字节加上键值区，一个桶的”热数据”能挤进一两个缓存行；同时 8 是个足够小的粒度，搬迁一个桶的成本可以忽略；浪费也可控。

一句话总结：

桶的槽数，是”每次查找要扫多少”与”每个槽浪费多少内存”之间的拉锯；8 是 Go 团队在真实负载下压出来的甜蜜点。

这也顺带回应了”为什么不纯用开放地址法”：纯开放地址法（所有元素挤在一个大数组里，冲突就往后找空位）删除很麻烦，且负载因子一高就急剧退化。Go 的”8 槽一桶 + 溢出链”是开放地址（桶内线性探测）与链地址（溢出桶）的缝合体，取两者之长。

细节三：键值分开存，是为了少喂 padding

你注意到没有：图里 8 个 key 是连续存完再存 8 个 value，不是 key,value,key,value... 交替。

这不是随手写的。Go 的内存布局有对齐规则。假设 key 是 int64（8 字节），value 是 bool（1 字节）：

交替存：每对占 9 字节，按 8 字节对齐 → 实际 16 字节，8 对共 128 字节，其中 56 字节是纯 padding。
分开存：8 个 key 占 64 字节，8 个 value 占 8 字节 → 总共约 72 字节。

**省下的不是内存，是缓存行。**在 map 这种每秒查几百万次的结构里，缓存占用直接换算成响应时间。

细节四：槽位的”多态”和删除留下的坑

桶里的槽位不是简单的”占用/空闲”两态。为什么？

考虑：桶里 5 个元素 A B C D E，插在槽 0~4。现在删掉 B（槽 1）。

问题来了：查找 E 时，能不能扫到槽 1 发现是空的，就判定”E 不存在”？

不能。因为插入 E 的时候槽 1 被 B 占着，E 可能已经被挤到了后面的槽。你在槽 1 就停止探测，E 就”丢了”。

所以删除不能简单把槽标记成”空”，至少要区分三种状态：

从未使用过：这个槽以及它之后的所有槽都没用过 → 探测可以在这里提前终止。
用过但删掉了：这个槽空着，但后面可能还有元素 → 探测必须继续。
占用中：正常比较。

Go 用 tophash 的若干个保留值来编码这些状态（tophash 是 1 字节，能表示 0~255，扣掉当指纹用的值，剩下的特殊值正好用来标记槽位状态）。于是”槽位状态”和”指纹”共用同一块 8 字节内存，不用额外开数组——又是一处极致的内存抠门。

**这给你一个非常重要的实战认知：delete 不是”清空”，它只是把一个槽改成”已删除”状态。**而且：

map 删除元素后，内存不会归还，桶数组只增不减。

往 map 里塞 1000 万个键，再全删掉，内存占用依然停在 1000 万那个量级。这是长生命周期缓存的经典坑。解法只有一个思路：定期重建 map（换一个新 map，让旧的被 GC 回收），或者做分代轮转（两个 map 交替，定期整个丢掉一个）。

细节五：溢出桶是”局部救火”

一个桶装满了（8 个槽全占，或插入时探测不到空位），就在后面链一个溢出桶。

你可能会问：桶满了为什么不直接扩容？

因为哈希分布天然不均匀。即便哈希函数很理想，元素落进各个桶的过程也近似一个随机过程——总有些桶塞了 12 个，有些桶只塞了 2 个。如果”任何一个桶装满就整体扩容”，那你为了这 1 个爆满的桶要把整个表翻倍，内存利用率低到没法看。

溢出桶的思路是：**局部问题局部解决。**某个桶运气不好塞多了，就给它挂个小包间，不动全局。只有当”全局平均都挤了”才翻倍扩容；只有当”小包间挂得满地都是”才等量扩容（下下节讲）。

这个”局部救火 + 全局扩容”的分级处理，是 Go map 设计的精髓之一：不是所有问题都值得用同一个代价去解决。

但溢出链有代价：链一长，查找就退化成链表遍历，缓存局部性彻底丧失——你从”扫一眼 8 个名牌”退化成”沿着巷子一家家敲门”。所以溢出链必须被监控，这正是等量扩容存在的理由。

子主题八：负载因子——那个”约 6.5”背后的三元拉锯

先把概念钉死

负载因子（load factor）= 元素总数 / 桶数。

注意分子是”元素个数”，分母是”桶的个数”，不是”槽位总数”。所以一个装了 8 个元素的桶，对负载因子的贡献是 1，不是 100%。

Go 的扩容阈值大约是 6.5（注意是”约”，不同版本有微调，别当成常量背）。也就是说：平均每个桶装到约 6.5 个元素，就触发翻倍扩容。

第一问：负载因子凭什么能大于 1？

学过数据结构的人第一反应是懵的：拉链法的负载因子不该控制在 1 以内吗？超过 1 不就意味着”平均每个桶都装不下”？

对，也不对。Go 的桶有 8 个槽，平均装 6.5 个意味着还剩 1.5 个空槽——根本没溢出。溢出只发生在”某个桶超过 8 个”的时候。

所以 Go 的负载因子是以桶为单位的，它的隐含满值是 8，阈值约 6.5 相当于”八成满就扩容”。

第二问：为什么不干脆等到 8（装满了再扩）？

这就说到哈希分布的不均匀性了。

假设哈希理想随机，元素落进各个桶的过程近似泊松分布。平均值定在 6.5 时，大部分桶装 6~7 个，但仍有相当比例的桶会装到 9 个、10 个——这些桶就必须挂溢出桶。

（这里我不给具体的概率数字，不同资料给的近似值也不一样。重要的是趋势：平均值越接近 8，需要溢出的桶的比例上升得越快。）

如果阈值定成 8（平均每个桶塞满），溢出桶会多到什么程度？几乎一半的桶都要挂溢出链。查一个元素，先扫主桶 8 个槽，没中再跳溢出桶——平均探测路径被拉长，缓存局部性被稀释。

所以阈值必须留余量。留多少？6.5 就是”再往上溢出桶涨得太快、再往下内存浪费太多”的那个拐点。

第三问：那定低一点不是更安全吗？比如 3？

安全是安全了，但你付出了什么？

**内存。**负载因子 3 意味着你为 1000 万元素的 map 分配 300 多万个桶，而 6.5 只需要 150 多万个。桶不是免费的——每个桶有 8 个槽的键值区加一个溢出指针，平均只装 3 个的桶，等于浪费了大半容量。

还有第二重代价：**扩容次数变多。**从 1 个桶长到 N 个桶，每次翻倍，累计搬迁元素的次数约是 1 + 2 + 4 + … + N ≈ 2N。负载因子每降一半，这份”总搬迁量”和”GC 垃圾量”就要重来一轮。

于是得到一张三元拉锯表：

阈值	内存占用	溢出链 / 碰撞	扩容与搬迁次数
太低（如 2~3）	浪费严重	很少	很多
太高（如 8）	省	大量溢出链，局部性差	很少
约 6.5	尚可	可控	尚可

工程上没有最优解，只有最合适的平衡点。

用生活类比把这件事钉死

把负载因子想成停车场的平均停车率。

阈值定 100%（每片区域必须停满才开新区域）：听起来最省地。但车不是均匀来的——写字楼区爆满，车在过道里绕圈找位（溢出链），保安（CPU）忙得团团转；而郊区那片还空着一半。
阈值定 50%（停一半就开新区域）：永远有位停，但地皮成本翻倍，还得雇更多保安（内存 + 搬迁成本）。
阈值定八成：绝大多数时候一次就能停进去；偶尔爆满的区域多绕两步；地皮成本还能接受。

停车场的”八成”和 Go 的 6.5，是同一个判断。

一个反直觉的实战提醒

负载因子的分子是 count，也就是当前元素数。所以：

反复执行”插入 100 万 → 删除 100 万 → 再插入 100 万”的循环，永远不会触发翻倍扩容。

因为 count 一直在回落，负载因子上不去。这时候会不会有问题？会——溢出桶会越积越多，形成碎片。这就是下一节的主角。

子主题九：两种扩容——翻倍与等量，治的压根不是同一种病

很多人以为”map 扩容就是把桶数组翻倍”。**只对了一半。**Go 的扩容有两种，长得像，病因完全不同。

类型一：翻倍扩容（真的长大了）

触发：负载因子超过阈值（元素太多了）。
动作：分配一个两倍大的新桶数组。
目的：降低负载因子，让每个桶松快一点，减少溢出。
类比：公司从 50 人涨到 200 人，工位不够了，租一层两倍大的办公室整体搬过去。

这个好理解，前面铺垫够了。

类型二：等量扩容（房子没变大，只是重新码一遍）

触发：溢出桶太多了（相对主桶数量而言）。此时负载因子可能很低，元素根本不多。
动作：分配一个同样大的新桶数组，把所有元素重新放一遍。
目的：不是降低负载因子，而是整理碎片。
类比：公司还是 50 人，办公室还是那间。但三年下来纸箱堆满过道、文件散落各处、工位被杂物占着，找个东西要翻半天。于是周末请搬家公司来：东西全搬出去、清空、重新码整齐、再搬回来。人没变，房子没变，效率回来了。

等量扩容到底发生在什么场景？

把子主题七的”删除坑”和子主题八的”反直觉提醒”拼起来，你就得到一条清晰的因果链：

你往 map 里插入 100 万个键 → 撑出大量溢出桶（分布不均匀，很多桶挂了链）。
你删掉其中 90 万个 → count 掉到 10 万，负载因子很低，翻倍扩容永远不触发。
但那 100 万个键撑出来的溢出桶结构还在。剩下 10 万个键稀稀拉拉散落在主桶 + 长长短短的溢出链上。
现在查找一个键：定位主桶，扫 8 个槽没中；跳溢出桶，再扫 8 个；再跳……一条链走七八个桶，每个桶一次内存访问，全是 cache miss。

这时候翻倍扩容帮不了你——把桶数翻倍，这 10 万个键还是那 10 万个，只是变稀疏了。病根不是”太挤”，是”太乱”。

所以等量扩容：桶数不变，把散落在溢出链上的元素重新塞回主桶的空槽，把删除留下的空洞挤掉，让每个主桶的 8 个槽尽量紧凑、让空槽连续。

等等，桶数不变，哈希定位不就一样吗？重排有什么用？

这个问题问得太好了，必须正面回答。

桶数不变 → 决定”落在哪个桶”的哈希低位不变 → 每个元素重排后落进的还是同一个桶编号。看起来确实”什么都没变”？

不，变了两件事：

第一，溢出链上的元素被塞回主桶了。原来主桶 8 个槽满了，第 9 个元素只能去溢出桶。现在前面有些槽被删除空出来了（虽然被标记成”已删除”、探测还得继续走，但重排时这些槽可以重新放元素），于是那些溢出链上的元素就能直接占用主桶的槽，不用再挂溢出桶。

**第二，槽位状态被”压实”了。**重排后，主桶的槽位从”占用/已删除/占用/已删除/…”这种瑞士奶酪状态，变成”占用/占用/…/空/空/空”——空槽集中在尾部。尾部连续的空槽可以用”从未使用”标记，探测就能在那里提前终止。

所以等量扩容的收益不是”少碰撞”，而是：

更短的平均探测路径 + 更短的溢出链 + 更好的缓存局部性。

它治的是结构老化，不是容量不足。

怎么判断”溢出桶太多了”？

具体阈值随版本演进，我不给精确数字（给了也容易过时，而且不同版本确实调过）。你要记住的是判断思路，不是数字：

元素多 → 负载因子高 → 翻倍扩容
元素不多但溢出链多 → 结构碎片化 → 等量扩容

这两条路径的分工，是 Go map 设计里非常干净的一处：用不同的工具治不同的病，而不是拿”扩容”这一把锤子敲所有钉子。

顺带一个高价值推论

既然”大量插入 + 大量删除”会让 map 结构老化，那你的长生命周期缓存 map（比如一个跑了三个月的本地缓存）如果一直做增删，性能会缓慢劣化，直到某次触发等量扩容才回来。

如果你能预测这个模式，别指望等量扩容，直接定期重建 map（新建一个，把还活着的键拷过去，旧的丢掉）。这比等运行时自己整理更可控——你知道重建成本发生在哪一刻，而等量扩容的时机你控制不了。

子主题十：渐进式搬迁的魔鬼细节——以及遍历随机起点的第二层真相

子主题二讲了渐进式扩容的”大思路”。这一节钻进细节，看几个你在别处很难读到的设计决策。

细节一：搬迁的单位是”桶”，不是”元素”

每次搬迁，搬的是一个旧桶 + 挂在它后面的整条溢出链。为什么按桶搬，而不是”每次搬 10 个元素”？

因为翻倍扩容有一个优雅的性质：一个旧桶只会分裂成两个新桶，且只分裂成那两个。

桶数始终是 2 的幂：8 → 16 → 32 → 64。翻倍后，决定”落在哪个桶”的哈希低位多了一位。于是旧桶 i 里的所有元素，只需要看”新多出来的那一位”：

那一位是 0 → 去新桶 i
那一位是 1 → 去新桶 i + 老桶数

**哈希值完全不用重算，只看一个比特。**这就是为什么”按桶整体搬迁”是最自然的粒度：一个旧桶的全部元素（含溢出链）只有两个去处，一把梭搞定。

这个技巧叫分裂（split），是”桶数取 2 的幂”带来的红利。如果你把桶数设计成质数或任意增长，就没这个便宜——每次扩容都得完整重算哈希 + 重新取模，成本立刻翻倍。

一个”顺手”的约束（桶数取 2 的幂），换来了扩容路径上的巨大优化。这就是数据结构设计里”约束即优化”的典型。

代价是什么？代价是哈希函数必须把输出的低位也搅得足够均匀。如果低位有规律，桶数取 2 的幂就会把规律放大成碰撞。这也解释了为什么运行时要亲自实现各类型的哈希函数，而不是直接拿某种”原始哈希值”的低位来用。

细节二：搬迁进度就是一个游标

map 头部结构里有一个字段记录”下一个待搬迁的旧桶编号”（可以理解为 nevacuate）。搬迁就是把这个游标往前推。游标走完所有旧桶，旧数组释放，扩容结束。

细节三：读路径也会顺带搬迁

这一点很多人不知道：不只是写，读也会触发搬迁。

读取一个 key 时，如果发现 map 正在扩容且目标桶尚未搬迁，就会先把那个桶搬走，再去新表里查。

为什么读也要搬？不是为了”帮写操作分担”，而是为了保证读的正确性：如果目标桶已经搬到新表了，你还去旧桶里找，就找不到了。与其”判断一下该查新表还是旧表”，不如”先搬，再统一从新表查”——逻辑反而更简单。

细节四：为什么每次要”多搬一个”？——防止扩容永远完不成的补丁

这是本节最有意思的一个点。

假设搬迁只做”搬当前访问到的那个桶”，会发生什么？

考虑一个热点 key——比如 m["config"]，每秒被读一百万次，而 map 里其他几万个键一年也没人碰。

现在 map 触发了扩容。每次读 "config"，就搬迁它所在的那个桶。**其他桶永远不会被访问，永远不会被搬迁。**于是：

旧桶数组永远不能释放 → 事实上的内存泄漏
map 永远停留在”扩容中”状态 → 每次操作都多一次”是否在扩容”的判断
更糟：搬迁状态里存着旧数组引用，GC 也回收不了

**扩容永远完不成。**这是实实在在的 bug，不是假想。

解法：每次搬迁，除了搬”当前访问的目标桶”，再顺手从游标位置搬一个或多个桶。这份”顺手”的搬迁不依赖访问模式——不管你访问哪个 key，扩容进度都在稳定推进。

于是扩容完成有了一个不依赖访问分布的进度保底：只要还有持续访问，进度就一定在走，且推进速度与”访问了哪些 key”无关。

这是一个典型的”给摊还机制加一条不变量保底”的设计：渐进式摊还最怕的就是”摊还的触发条件永不满足”，那就不是摊还，是永久欠债。

（顺带剧透：Redis 的渐进 rehash 遇到的是同一个问题，它的解法不一样——用后台定时任务主动搬迁。两条路，同一个目标。下一节末尾讲。）

细节五：搬迁期间，新元素只写新表——一个漂亮的不变量

扩容进行中，如果有人插入一个新 key，写到哪儿？

只写新表。绝不写旧表。

为什么？因为它保证了一个至关重要的不变量：

旧桶里的元素只减不增。

有了这个不变量，搬迁就一定能结束——旧桶元素有限，每次搬走一批，不会再有新元素被塞回旧桶，进度单调推进，必然收敛。

如果允许往旧桶写，就可能出现”一边搬一边塞”的拉锯战，进度来回来回，理论上可以永远搬不完。用一条写入规则，换一个收敛性证明——这在增量算法和并发算法里是极其典型的手法。

删除同理：先搬迁目标桶，再在新表里删除。

细节六：搬迁期间怎么查找？

“新桶 i”与旧桶的对应关系：因为桶数是 2 的幂，取模就是按位与，新桶 i 对应的旧桶编号 = i & (老桶数 - 1)。翻倍后，新桶 i 和 i + 老桶数 都映射到同一个旧桶。

查找流程：

算出 key 的哈希，按新桶数定位到新桶 i。
检查这个新桶对应的旧桶是否已搬迁：
- 已搬迁 → 直接在新桶 i 里找；
- 未搬迁 → 去旧桶里找（元素还躺在那儿）。

判断”是否已搬迁”的技巧：搬迁时会给新桶的 tophash 区域留下标记，记录”这个新桶对应旧桶的搬迁状态”。细节随版本演进，思路都是用一个便宜的标记，避免一次额外哈希计算和范围判断。

细节七：遍历为什么必须随机起点——第二层、第三层真相

子主题五讲的是表层原因：防止程序员依赖顺序。现在我们有了足够的底子，可以看更深的两层。

第二层真相：扩容期间，遍历看到的根本不是一个”稳定的表”。

遍历过程中 map 可能正在扩容：旧表 + 新表并存，搬迁进度还在走。遍历器必须处理这种”半搬完”的状态。

Go 的做法是：遍历以旧桶为单位推进；对每个旧桶，如果它已经搬迁了，就去新表里读它分裂出来的那两个新桶（元素已经搬走了），否则在旧桶里读。

这意味着：遍历看到的是”搬迁进度的实时快照”。

现在设想：如果遍历起点固定为 0 号桶，那么在扩容期间，遍历顺序会呈现一种高度依赖”当前搬到哪了”的可预测模式——前一段读新表、后一段读旧表，而这个分界点随搬迁进度移动。遍历顺序就变成了一个泄露内部状态的信号。随机起点把这个信号搅碎了。

第三层真相（最狠的一层）：固定顺序会帮攻击者反推哈希种子。

回忆子主题六：哈希种子是防碰撞攻击的命根子，而它的安全性依赖”攻击者不知道种子”。

如果遍历顺序是确定的（总是从 0 号桶开始、桶内从 0 号槽开始），那么遍历顺序就直接反映了 key 在桶里的分布，也就反映了哈希值的相对大小关系。攻击者只要能触发一次遍历并观察顺序（比如你的 API 返回了一个由 map 遍历生成的列表），就能反推出大量关于哈希分布的信息——进而推断种子，进而构造碰撞 key。

随机起点（随机起始桶 + 桶内随机起始偏移）切断了这条信息泄漏通道：你观察到的顺序里混进了一个每次都不同的随机量，分布信息被彻底污染。

所以”遍历随机化”不是给开发者添堵的恶作剧，它是防碰撞攻击体系的第二道锁：第一道锁（随机种子）让攻击者构造不出碰撞；第二道锁（随机遍历）让攻击者偷不走构造碰撞所需的信息。

这个视角一旦建立，你再看 Go 里那些”故意不确定”的设计，感觉会完全不一样。

细节八：遍历期间修改 map，会发生什么？

一句话：未定义，别依赖。

遍历期间删除键（当前的或未来的）→ 可能出现在结果里，也可能不出现。
遍历期间新增键 → 可能被遍历到，也可能不被遍历到。
遍历期间修改已有键的值 → 通常能看到新值（读的是同一个槽），但这也不该依赖。
遍历期间并发写 → 直接 panic，和普通并发写一样。

唯一安全的做法：**遍历期间只读。**要改就先收集 key，遍历结束后再改。

子主题十一：map 性能调优——把”扩容”从热路径上摘掉

第一招：make 时给 hint

m := make(map[string]int, 1000000)  // 预分配

这个 1000000 是提示（hint），不是容量上限，也不是承诺。map 照样能超过它继续增长，只是不会在早期反复扩容。

为什么 hint 有用？算一笔账

假设最终要装 100 万个元素，不给 hint：

1 桶 → 2 → 4 → 8 → ... → 131072 桶

大约 17 次翻倍。每次翻倍都要把当时已有的所有元素重新搬迁一遍：

1 + 2 + 4 + 8 + ... + 524288 ≈ 100 万次元素搬迁

也就是说，除了”插入 100 万个元素”本身，你还额外付了约 100 万次元素搬迁。而且：

这 17 个旧桶数组都是垃圾，等着 GC 回收（其中最大的那个是几十万桶级别）。
每次搬迁期间 map 处于”双表并存”状态，内存占用临时翻倍。
每次搬迁都伴随大量 cache miss。

给了 hint：**直接分配够装 100 万的桶，零次搬迁。**搬迁次数从约 100 万次降到 0。

类比

从出租屋搬到一居室，再搬到两居，再搬到三居。每搬一次，所有东西都要打包、搬走、拆包、重新归位。搬三次，你整理四遍家。

预分配 hint = 一开始就告诉搬家公司”我要三居”，直接搬进去，只整理一遍。

搬运量没变（东西还是那些东西），但”重复整理”的次数从 4 变成 1。

什么时候该给 hint？

✅ 能估算最终规模：从数据库批量加载 N 条记录建索引、解析已知大小的配置文件、构建一张路由表。
✅ 构建过程在延迟敏感路径上：比如请求处理中间要建一个 map。
❌ 规模完全不可预测：hint 给小了没用，给大了浪费内存（桶数组是按 hint 一次性分配的，不是按需增长）。
❌ 小 map：几十个元素的 map，省下的搬迁还不够抵消多占的内存。

反问：hint 给太大有代价吗？

有。**hint 是按”你声称的规模”一次性分配内存的。**你 hint 给 1000 万，实际只装 100 个，那 1000 万桶的内存就一直占着——还记得吗，map 不会缩容。

所以规则是：hint 给”你确信会达到的量级”，不要给”万一的上限”。hint 的收益是”省搬迁”，成本是”占内存”，两者都随 hint 单调增长，你要找的是净收益最大的那个点，而不是”越大越安全”。

第二招：别让”小 map 频繁扩容”发生在循环里

这是个很常见的写法问题：

// 差：每次循环都新建一个 map，并从小长到大
for _, item := range items {
    m := make(map[string]int)   // 没有 hint
    for _, tag := range item.Tags {
        m[tag]++
    }
    results = append(results, m)
}

如果每个 item 平均有 50 个 tag，每个 map 都要经历约 6 次扩容。乘以 N 个 item，扩容次数就是 6N。

改法一：给 hint —— make(map[string]int, 64)。

改法二（更彻底）：复用一个 map，每轮循环前清空（Go 1.21 起有内置 clear）。复用的好处是桶数组一直不释放，扩容只发生在最开始几轮，之后永远在已分配好的容量里工作。

注意 clear 只清空槽位、重置 count，不释放内存——这恰恰是复用想要的：内存留着给下一轮用。

第三招：key 类型的选择，比你想象的更重要

map 的单次操作成本 = 哈希计算 + 定位桶 + 桶内比较。很多人只盯着后两项，忽略了第一项。

几条经验：

定长、无指针的 key 最快。map[int64]V、map[[16]byte]V 这类 key，哈希计算是几条指令，比较是一次机器字比较。而 map[string]V 每次都要遍历字符串字节来算哈希——字符串越长越慢。
**key 本质上是定长二进制时，别转成 string。**UUID 存成 map[[16]byte]V 比 map[string]V 又快又省：string 有头部 + 指向堆数据的指针，[16]byte 直接内联在桶里。
**struct 做 key，字段越多越慢。**哈希要遍历所有字段，比较也逐字段；里面有 string 字段还得跳指针。
**key 里尽量别含指针。**这条要和下一条连起来看。

第四招（硬核）：key 与 value 都不含指针时，GC 成本断崖式下降

这条很多人不知道，但在大 map 场景下极其关键。

Go 的 GC 在标记阶段要扫描堆上所有含指针的内存。一个装了 1 亿个键值对的 map[string]*User，GC 得逐个槽位去看那个 *User 还活着没——上亿次指针追踪，每次都可能是 cache miss。

而如果你的 map 是 map[int64]int64（key 和 value 都不含指针）：

运行时会为这个 map 采用特殊布局，把桶类型标记为”不含指针”，GC 直接跳过整个键值区；溢出桶的存活则由 map 头部的一个独立字段（溢出桶指针集合）保证，不依赖逐槽扫描。
GC 扫描成本从 O(元素数) 降到接近 O(1)。

所以当你有一个超大 map、且它在 GC 周期里占了显著成本时，请认真考虑：能不能把 key/value 都设计成不含指针的？比如把 map[string]*User 改成 map[uint64]uint32（ID → 数组下标），真正的对象存在一个 slice 里。

**这不只是”省内存”，是把 GC 的扫描工作量从”与 map 元素数相关”变成”与 map 元素数无关”。**在数 GB 级堆上，这是几十毫秒与几百毫秒 STW 的区别。

第五招：value 很大时，存指针

反过来，如果 value 是一个很大的 struct（比如 200 字节）：

map[K]BigStruct：每次赋值/读取/遍历都要拷贝整个 struct；桶里的 8 个 value 区也被撑得很大，一个桶要占好几个缓存行。
map[K]*BigStruct：桶里只存 8 个指针，操作只拷贝指针。代价是多一次指针跳转（一次潜在 cache miss）和 GC 要追踪这些对象。

取舍：**value 只有几个机器字 → 直接存值；value 很大且读取不极度频繁 → 存指针。**没有定论，测。

第六招：set 用 `map[K]struct{}` 而不是 `map[K]bool`

struct{} 大小是 0，桶里的 values 区不占空间；bool 占 1 字节，在 1000 万元素的 set 里就是 10MB 的差别，还白白占满缓存行。

语义上也更清晰：struct{} 明说”我只关心键在不在”。

调优的元方法

最后说方法论：**上面每一条都是”通常成立的趋势”，不是定律。**在你自己的负载下测，用 testing.B 写基准，重点看三个指标：

ns/op：单次操作耗时
B/op：单次操作分配的字节数（在 map 调优里它比 ns/op 更灵敏，因为它直接反映扩容与 GC 压力）
allocs/op：单次操作的分配次数

想看扩容的代价，B/op 是最好的探针。

子主题十二：sync.Map 拆解——read / dirty / misses 的三体问题

子主题四给了 sync.Map 一个”双层结构”的速写。这一节把螺丝拧到底，看清它怎么转，以及为什么”写多的时候它反而更慢”——这个问题答不上来，你就不算真的懂 sync.Map。

先问：为什么不直接用 map + RWMutex？

var mu sync.RWMutex
var m = map[string]int{}
 
// 读
mu.RLock(); v := m[k]; mu.RUnlock()
// 写
mu.Lock(); m[k] = v; mu.Unlock()

问题在哪？读也要写共享状态。

RWMutex 的 RLock() 要原子地给”读者计数”加一，RUnlock() 要减一。这个计数器是所有读者共享的一个内存位置。

在多核机器上，32 个核同时 RLock，就是在对同一个缓存行做 32 路并发的原子写。每次原子写都会让其他核上这份缓存行的副本失效（缓存一致性协议在背后疯狂地让缓存行在多核之间”乒乓”）。

结果是：你的”并发读”在 CPU 层面其实是串行化的，只是串行得比较隐蔽——不体现在锁等待上，而体现在缓存行争用上。核越多越亏。

sync.Map 的野心是什么？让读操作一次共享内存的写入都不做。

结构：三个零件

sync.Map 内部大致是这样（Go 1.20 之后用原子指针实现，早期版本用 unsafe 指针，思路完全一致）：

type Map struct {
    mu     Mutex                     // 只保护 dirty
    read   atomic.Pointer[readOnly]  // 无锁读快照
    dirty  map[any]*entry            // 受 mu 保护的完整表
    misses int                       // read 未命中计数
}
 
type readOnly struct {
    m       map[any]*entry
    amended bool   // true：dirty 里有 read 里没有的键
}
 
type entry struct {
    p atomic.Pointer[any]   // 指向真正的值
}

三个零件的职责：

零件	谁改它	谁读它	作用
`read`	从不原地修改，只整体原子替换	所有人，无锁	读快路径
`dirty`	受 `mu` 保护	写路径、read 未命中时	完整数据，写入目标
`misses`	只在加锁路径里累加	—	决定何时把 dirty 提升为 read

**最关键的设计：read 是一个不可变快照。**它一旦发布内容就不再改变，只能通过”整体替换指针”来更新。正因为不可变，读它才不需要锁——读的人永远不会看到”改了一半”的状态。

这就是”快照 + 原子替换”的思想（近似于读时复制 / 不可变数据），在函数式编程、数据库 MVCC、Linux 内核 RCU 里都是同一个套路。

entry 的三态：sync.Map 最绕的一处

entry.p 指向真正的值，它有三种状态：

指向一个值（正常）：键存在，值有效。
nil：键被删除了。
expunged（一个特殊哨兵指针）：键被删除，且已经从 dirty 里彻底抹掉了。

为什么要区分 nil 和 expunged？只有 nil 不够吗？

不够。这里有个微妙的状态一致性问题：

dirty 是从 read 重建出来的（当 dirty 为 nil 时的第一次新键写入，需要从 read 里把所有未删除的键浅拷贝过来）。
重建时，read 里那些已删除的键不会拷进 dirty，而且它们会被标记为 expunged。

expunged 的作用是：永久性地记录”这个键不在 dirty 里”。

有了这个记录，后续处理就干净了：

对 p == nil 的 entry 做 Store：说明”删了又写回来”，若 dirty 不为 nil，直接加回 dirty 即可。
对 p == expunged 的 entry 做 Store：说明这个键连 dirty 里都没有，必须先恢复成 nil、插进 dirty，再写值。
Load 时看到 nil 或 expunged，都返回”不存在”。

**expunged 是”已从 dirty 抹除”这个事实的唯一记录方式。**没有它，你就无法在”只读 read、不加锁”的情况下判断一个已删除的键是否还在 dirty 里——而一旦需要加锁判断，读快路径就废了。

**用一个额外状态，换读路径的完全无锁。**这是 sync.Map 里最精妙、也最容易被一眼跳过的设计。

读路径（Load）：为什么它快

func (m *Map) Load(key any) (value any, ok bool) {
    read := m.read.Load()          // ① 一次原子读指针
    e, ok := read.m[key]           // ② 在快照 map 里查
    if !ok && read.amended {       // ③ 快照里没有，但 dirty 可能有新键
        m.mu.Lock()                //    慢路径：加锁
        read = m.read.Load()       //    双重检查：加锁期间 read 可能已被替换
        e, ok = read.m[key]
        if !ok && read.amended {
            e, ok = m.dirty[key]
            m.missLocked()         //    misses++，必要时提升 dirty
        }
        m.mu.Unlock()
    }
    if !ok {
        return nil, false
    }
    return e.load()                // ④ 从 entry 原子读值
}

命中快路径的读，只做了两件事：一次原子指针读 + 一次普通 map 查找。

对比 map + RWMutex 的读：原子写读者计数 → 加锁语义 → 查 map → 原子写读者计数。

sync.Map 赢在哪？**它一次共享内存的写入都不做。**没有缓存行乒乓，32 个核读起来是真正的 32 路并行，扩展性接近线性。

这就是”读多写少”场景下 sync.Map 碾压 RWMutex 的全部秘密。

再注意一个细节：**read.amended 这个布尔量，是”我可以跳过加锁”的门票。**如果 amended == false，说明 dirty 里没有任何 read 里没有的键——那么 read 里查不到就等于整个 map 里没有，可以直接返回，一次锁都不用加。

一个布尔量，省掉了绝大多数”查一个不存在的键”场景下的加锁。这个优化非常聪明：缓存场景下”查未命中”恰恰是高频操作。

写路径（Store）：为什么它慢

func (m *Map) Store(key, value any) {
    read := m.read.Load()
    if e, ok := read.m[key]; ok && e.tryStore(&value) {
        return    // ① 快路径：键已在 read 里且未被删除 → 直接 CAS 换值，无锁！
    }
 
    m.mu.Lock()   // 慢路径
    //   双重检查 + 分支处理：
    //   - read 里有且 p == expunged → 恢复成 nil、加进 dirty、再写
    //   - read 里有且 p == nil      → 加进 dirty、再写
    //   - dirty 里有                → 改 dirty
    //   - 都没有                    → amended = true，插进 dirty
    //        （若 dirty == nil，先从 read 全量重建 dirty）
    m.mu.Unlock()
}

**注意第 ① 条：覆写一个已存在的键，是可以无锁的！**因为 entry 本身是个原子指针，直接 CAS 换掉 p 就行，不动 map 结构。

这解释了 sync.Map 的一个关键画像：“写一次读多次”（write-once-read-many）场景下，连写都是快的——第一次写入走慢路径建好 entry，之后所有覆写都走无锁 CAS。

慢路径上真正的地雷：dirty 重建

现在看慢路径里最要命的一行：dirty == nil 时，要从 read 全量重建 dirty。

这什么时候发生？走一遍循环：

初始：read 为空，dirty 为 nil。
写入一批键 → 慢路径 → dirty 为 nil → 重建 dirty（此时 read 是空的，重建很便宜）→ 写进 dirty。
读这些键 → read 里没有 → 慢路径加锁 → misses 累加。
misses 达到 len(dirty) → dirty 提升为 read，dirty = nil，misses = 0。
此时 dirty 是 nil 了。若再写入一个新键 → 慢路径 → dirty 为 nil → 从 read 全量重建 dirty，一次 O(n) 的浅拷贝！

于是：如果你的写模式是”不断新增键”，就会反复触发 O(n) 的 dirty 重建。

有多糟？假设 read 里有 100 万个键，你每写一个新键，就要重新拷贝 100 万个 entry 指针。写 10 个新键，就是 10 次 100 万的拷贝。这就是”写多时 sync.Map 反而更慢”的真正爆炸点——不是”慢一点”，而是在写路径上埋了周期性 O(n) 尖峰。

对比 map + Mutex 的写：一次加锁 + 一次哈希表插入，O(1)，没有尖峰。

那为什么还要设 `dirty = nil`？

因为”提升”的语义就是”dirty 的内容已被 read 全盘继承”。既然 read 已经等于 dirty，dirty 就没必要留着占两份内存。

这个设计在”写完一批、之后长期只读”的负载下是对的——一次性拷贝，换之后所有读都无锁，是笔划算的买卖。

它崩在”写写停停、夹杂新键”的负载上——每次停下来的代价，都是下次开动时要全量重建。

sync.Map 本质上是把”写入”的成本后移并批量化，赌的是”批量之后会有一段很长的只读期”。如果你的负载不遵守这个赌约，你就输了。

提升的触发条件：misses 达到 len(dirty)

为什么是这个条件？

misses = “read 里没查到、不得不加锁去 dirty 查”的次数。
每发生一次，你就付了一次加锁的成本。
当 misses 累计到 len(dirty)，意思是：你为查这些键付出的加锁次数，已经达到”把整个 dirty 拷贝成一份新 read”的规模了。

翻译一下：继续这么拖下去的成本，已经超过一次性整理的成本了。那就整理。

这是一次典型的摊还决策——和第五章 slice 扩容、本章的渐进式搬迁，是同一套思维：用”累计欠账达到阈值”来触发一次性结清。

生活类比：桌上散着一堆文件，每次找都要翻一遍抽屉。翻了 50 次之后你受不了了，花 5 分钟归类归档，之后秒找。归档时机，取决于”翻找的痛苦”是否已超过”归档的辛苦”。

提升时顺带发生的事：amended 复位

提升时，read 被整个替换成新的 readOnly{m: dirty, amended: false}，dirty = nil，misses = 0。amended 复位成 false，于是下一次”查不存在的键”又能走无锁路径了。

**整个替换靠的是一次原子指针写。**读的人要么看到老快照，要么看到新快照，绝不会看到中间态。这就是”不可变快照 + 原子替换”的威力。

那 sync.Map 到底该什么时候用？

官方文档给了两条，第二条经常被忽略：

**① 键写入一次、之后读取很多次。**典型场景：

全局配置表 / 注册表（启动时建好，之后只读）
连接池 / 路由表
命中率高、键相对稳定的缓存

**② 多个 goroutine 各写各的键，键集合不相交。**典型场景：

每个 goroutine / 连接 / 请求只更新自己的状态项
按 ID 分片的状态表，每个 worker 只碰自己那片

为什么第二种也行？因为”覆写已存在的键”走的是无锁 CAS 快路径。只要键已经在 read 里，多个 goroutine 写不同的键，各自 CAS 各自的 entry，互不干扰，也不需要锁。只有”键不在 read 里”时才需要加锁——所以只要键集合稳定，写也能做到几乎无锁。

明确不该用的场景

高频新增键的缓存（每次新增都可能触发 O(n) 重建）
计数器类场景（同一个键被反复递增：Load → 加一 → CAS 的循环在争用下退化，不如用原子计数器或分片计数）
需要 Range 提供一致性快照的业务逻辑（sync.Map 的 Range 不保证与其他操作的一致性）
键集合持续流动（增删频繁，read 与 dirty 反复同步）

第三种选择：分片 map

如果你的场景是”写也多、读也多”，标准答案往往不是 sync.Map，而是分片加锁：

type ShardedMap[K comparable, V any] struct {
    shards []shard[K, V]
}
 
type shard[K comparable, V any] struct {
    mu sync.RWMutex
    m  map[K]V
}
 
// 用 key 的哈希 & (N-1) 选分片

把一把全局锁拆成 N 把（N 通常取 CPU 核数的若干倍），锁争用概率降到约 1/N。读多的话每片用 RWMutex，写多的话用 Mutex。

这个思路和 Java LongAdder 的 Cell[]、和数据库的分库分表，是同一个套路：把单点热点，哈希打散成多个独立热点。

有意思的是，sync.Map 其实也是一种”分片”——只不过它分的是”读 / 写”这两片，而不是”键空间”。选哪种分片维度，取决于你的负载在哪一维上不均匀。

业界对照

Java HashMap： 非线程安全（和 Go map 一样），并发写不是 panic 而是”数据竞争 + 可能死循环/结构损坏”。线程安全版是 ConcurrentHashMap（分段锁/CAS，读写都并发安全）。Java 的做法是”提供专门的并发容器，让用户自己选”，而不是像 Go 那样”检测并发写直接 panic”。

C++ std::unordered_map： 非线程安全，迭代器会因 rehash 失效。并发问题完全交给用户。C++ 的哲学是”零开销抽象，安全你自己负责”。

Redis Hash： 单线程模型，天然无并发问题，rehash 也是渐进式的（dict 的渐进 rehash），和 Go 的思想同源——大表搬迁摊薄到每次操作。

Rust HashMap： 借助所有权和借用检查，编译器在编译期就拒绝”同一个 map 被两个线程同时可变借用”，把并发写的问题从”运行时 panic”提前到了”编译不过”。这是 Rust 一贯的”编译期消灭问题”路线。

子主题十三：业界对照补强——Java ConcurrentHashMap 与 Redis dict

上面的对照是”横向速览”。这一节我们挑两个最有代表性的实现，钻深一点——因为只有在具体实现上对比，你才能看出 Go 的每个选择到底放弃了什么。

一、Java ConcurrentHashMap：从分段锁到 CAS + 锁单桶

Java 7 时代：分段锁（Segment）

Java 7 的 ConcurrentHashMap 内部是一个 Segment[] 数组，每个 Segment 本质上是一个小的、自带 ReentrantLock 的 HashMap。

写入时，先按 key 的哈希定位到某个 Segment，只锁那一个 Segment。
不同 Segment 之间完全并发。
并发度 = Segment 数（构造时指定，之后不可变）。

这其实就是我们在上一节末尾讲的分片 map，只不过 Java 把它做进了标准库。

问题在哪？**粒度太粗且不可调。**Segment 数建表时就定了，你设 16，那第 17 个并发写就得等；你设 1024，又白白多出 1024 个锁对象的内存。而且跨 Segment 的操作（如 size()）要锁所有 Segment，代价高昂。

Java 8 之后：CAS + 只锁一个桶

Java 8 彻底重写，扔掉了 Segment，改为：

桶数组 + 链表/红黑树（和 HashMap 同构）。
插入时空桶 → CAS 写入（无锁）。
插入时桶非空 → synchronized 锁住桶头节点，只锁一个桶。
查找完全无锁：Node 的 val 和 next 都是 volatile，读路径一次写共享内存都不做。

读到这里你有没有一种强烈的既视感？

“查找完全无锁、写入只锁局部”——这和 sync.Map 的”read 无锁 / dirty 加锁”，是同一个设计目标的两种实现。

只不过 Java 把”无锁”做在桶的粒度（读任何桶都不加锁，写只锁一个桶），Go 的 sync.Map 把”无锁”做在快照的粒度（读整个 read 快照不加锁，写走另一份结构）。

粒度不同，适用负载就不同：CHM 的读写都是 O(1) 且写不引发全局结构拷贝，所以在”读写都多”的场景下比 sync.Map 稳健得多；而 sync.Map 在读路径上更极致（连 volatile 读的语义开销都省了，且在键稳定时连写都无锁）。

扩容：多线程协作搬迁——比 Go 更激进

CHM 扩容时，不是”每次操作顺带搬一点”，而是所有写线程一起帮忙搬：

搬迁以”桶区间”为单位分配给线程（从尾部往前领任务，用一个全局游标协调）。
一个线程搬完自己领的那段，回来再领下一段。
正在搬迁的桶会被标记为”已转移”（ForwardingNode），其他线程遇到这个标记就知道”数据在 newTable 里”，并且可以主动加入帮忙搬迁。

对比 Go：Go 是单线程顺带搬迁（谁操作谁搬，外加一个强制推进的保底），CHM 是多线程协作搬迁（人越多搬得越快）。

哪个更好？看场景：

Go 的方案更简单，不需要处理”两个线程搬同一段”的复杂协调，代价是搬迁总时长取决于访问频率。
CHM 的方案搬迁更快，大表扩容时不会被单个线程拖累，代价是引入了复杂的协作协议（ForwardingNode、sizeCtl 状态机、搬迁任务分配）。

这是一个典型的”简单 vs 快”的取舍。Go 选了简单，Java 选了快——因为 Java 面向的是”几十核的大服务器 + 千万级大表”，Go 面向的是”云原生的轻量服务 + 中等规模数据”。

计数：CounterCell 分片——又一处”打散热点”

CHM.size() / 内部的元素计数，不是一个全局 int，而是 baseCount + CounterCell[]：

无争用时，直接 CAS 累加 baseCount。
有争用时，把线程哈希到某个 CounterCell 上去累加。
求总和时把所有 Cell 加起来。

这和 LongAdder 是同一套机制，本质还是那句话：**把单点热点打散成多个独立热点。**上一节的分片 map 也是它。

红黑树化——防碰撞攻击的”另一条路”

这是本节最值得你记住的一个对照。

CHM（以及 Java 8 的 HashMap）有一条规则：当单个桶里的链表长度超过某个阈值，且哈希表的容量达到某个规模时，把这个桶的链表转成红黑树。

为什么？把最坏情况的查找复杂度从 O(n) 降到 O(log n)。

这就是防哈希碰撞攻击的第二种哲学：

	Go 的策略	Java 的策略
思路	让你构造不出碰撞	让你构造出来也打不死我
手段	运行时随机种子，攻击者无法离线预计算	碰撞了就树化，最坏 O(log n) 兜底
性质	预防（prevention）	缓解（mitigation）
代价	几乎为零	树化有额外内存与旋转成本，且 key 需要可比较

注意这两条路并不互斥，是可以叠加的。它们的取舍非常有意思：

Go 的路子便宜但依赖”种子不泄露”——所以才有了子主题十讲的”遍历随机化”作为第二道锁，防止种子信息被侧信道偷走。整个安全体系建立在一个假设上，于是要用额外机制去保护这个假设。
Java 的路子昂贵但无条件——不管攻击者多聪明、哈希函数多烂，最坏情况都被 O(log n) 兜住了。代价是每个用户都要背负树化的复杂度和内存开销。

便宜的方案，需要更多的辅助机制去堵漏洞；昂贵的方案，贵在它不依赖任何假设。

这个对照值得你在做自己的架构设计时反复拿出来用。

顺带一提，Java 的 String.hashCode() 是语言规范写死的、确定的（s[0]*31^(n-1) + ...），不可能随机化——因为哈希值要跨 JVM、跨版本保持一致（序列化、分布式缓存都依赖它）。**所以 Java 只能走”缓解”这条路，走不了 Go 的”预防”这条路。**一个历史包袱，决定了整个安全策略的走向。

二、Redis dict：和 Go 同源的渐进 rehash

Redis 的字典（dict）结构里有两个哈希表：

typedef struct dict {
    dictht ht[2];        // 两张表
    long rehashidx;      // 搬迁进度，-1 表示未在进行
    // ...
} dict;

是不是很眼熟？

ht[0] / ht[1] ↔ Go 的旧桶数组 / 新桶数组
rehashidx ↔ Go 的搬迁游标
渐进 rehash：每次对 dict 的增、删、改、查，都顺带把 ht[0] 在 rehashidx 位置上的那个桶搬到 ht[1]，然后 rehashidx++
搬迁期间新增只写 ht[1] ↔ Go 的”新元素只写新表”
查找先查 ht[0] 再查 ht[1]

**这几乎是同一套设计的两个独立实现。**为什么这么像？因为它们要解决的是同一个物理约束：**大表搬迁不能造成毫秒级卡顿。**Redis 是单线程的，一次卡 100ms 就意味着 100ms 内所有客户端都在等——这在 Redis 的延迟预算里是不可接受的。Go 虽然多线程，但对于”一次操作突然卡 100ms”，同样是要在 GC 之外尽量避免的。

差异点：Redis 用后台任务兜底，Go 用强制推进

还记得子主题十”细节四”那个问题吗？如果某些桶一直没人访问，搬迁就永远完不成。

Redis 的解法：**后台定时搬迁。**服务器的时间事件循环（serverCron / databasesCron）里有一段逻辑，在 CPU 空闲时主动搬迁一批桶（有时间和步数上限，避免自己把自己卡住）。

Go 的解法：每次搬迁时顺手多搬一个，强制推进进度。

两条路，同一个目标，取舍不同：

Redis 的方案：搬迁进度与访问模式完全解耦，但需要一个”后台时钟”——这在 Redis 里是现成的（事件循环），在 Go 的 map 里没有（map 是个纯数据结构，没有自己的 goroutine）。
Go 的方案：不需要任何后台设施，纯靠调用方驱动；代价是”没人用这个 map，扩容就永远停在那儿”（但这通常无所谓，因为没人用也就没人关心）。

约束决定设计：Redis 有事件循环这个”免费的时钟”，Go 的 map 什么都没有，只能借调用方的手。

另一个差异：Redis 会在持久化时推迟 rehash

Redis 在做 BGSAVE / BGREWRITEAOF 时，会 fork 子进程，靠操作系统的**写时复制（COW）**来生成快照。此时如果父进程大量修改内存，COW 会把被修改的页全部复制一份，内存占用可能瞬间翻倍。

于是 Redis 有一个专门的开关：有子进程在做持久化时，尽量推迟（甚至禁止）dict 的 rehash，把负载因子阈值临时放宽；只有负载因子高到”再不扩就出事了”的程度，才强制执行。

这是”数据结构层面对系统级约束的让步”——rehash 本身没错，但它触发的 COW 内存放大可能压垮机器，所以宁可忍受一段时间的高负载因子。

对照 Go：Go 的 map 从来不考虑”我在 GC 的哪个阶段”，因为它没有 fork 这种机制。但 Go 有自己的约束——map 里如果有大量指针，GC 扫描成本会很高，于是有了子主题十一第四招那条优化。

每个数据结构的”怪癖”，都是它在向某个外部系统让步。看懂让步的对象，就看懂了这个结构。

三、一张对照表收尾

维度	Go map	Java ConcurrentHashMap	Redis dict
并发策略	不加锁，并发写直接 panic	CAS + 锁单桶，读写全并发	单线程，无需并发控制
读路径	有锁（用户加）	无锁（volatile 读）	无锁
扩容方式	渐进式搬迁，单线程顺带搬	渐进式搬迁，多线程协作搬	渐进式 rehash，事件循环兜底
扩容触发	负载因子超阈值 / 溢出桶过多	元素数超阈值	负载因子超阈值（可因持久化推迟）
防碰撞攻击	随机哈希种子 + 遍历随机化	链表树化，最坏 O(log n)	随机哈希种子
最坏查找	O(n)（长溢出链，理论上）	O(log n)（树化兜底）	O(n)（长链，理论上）
遍历	随机起点，顺序不稳定	弱一致性迭代器，不抛异常	顺序由桶序决定

看这张表你会发现一件事：**没有一行是”全面最优”的。**每一列的设计都由它所在生态的约束塑造——Java 的大内存多核服务器、Redis 的单线程 + fork、Go 的轻量并发与小对象。

真正的设计能力，不是记住”哪个更好”，而是拿到一个新场景时，能问出”这里的约束是什么”，然后推出”这里该选哪一列”。

版本演进小结

早期 map：结构相对简单，遍历有序（早期版本遍历是稳定的）。
后来：为打断”依赖遍历顺序”的坏习惯，主动引入遍历随机化。
持续优化：桶结构、溢出桶管理、哈希种子随机化（防哈希碰撞攻击）、渐进式扩容细节。
sync.Map：Go 1.9 引入，为”读多写少”负载提供专用并发 map。
Go 1.24 起：map 的运行时内部实现换成了基于 Swiss Table 的新实现，槽位依然成组组织、渐进搬迁与随机种子等机制依然保留，具体字段与阈值随版本持续演进。本章讲的思想，是这些实现的共同内核。

一条主线贯穿：Go 的 map 始终在”性能”和”安全”之间做明确取舍——用渐进式扩容保性能平滑，用并发写检测保结构安全，用遍历随机化防坏习惯，用 sync.Map 覆盖特定负载。每一步都目标清晰、代价明确。

本章思考题

【思考题】

为什么并发写 map 的后果是”结构损坏”而不是”读脏数据”？请结合渐进式扩容解释。
Go 为什么不把 map 设计成”内部加锁、天然并发安全”，而要用户自己加锁或改用 sync.Map？
sync.Map 在什么场景快、什么场景反而慢？它的”读无锁、写有锁”双层结构是怎么工作的？
为什么 Go 故意让 map 遍历无序？这体现了什么设计哲学？
什么是哈希碰撞攻击（Hash DoS）？Go 的”运行时随机哈希种子”为什么能防住它？它防不住什么？
tophash 指纹解决的是什么问题？为什么”8 个槽”这个数字不是随便选的？请从缓存行的角度解释。
桶里 8 个 key 连续存放、8 个 value 连续存放，为什么不按 key,value,key,value 交替存放？
负载因子约 6.5 意味着什么？为什么不能定成 8（装满再扩）？又为什么不定成 3？
翻倍扩容和等量扩容的触发条件、动作、目的分别是什么？“等量扩容”为什么在桶数不变的情况下仍然有意义？
渐进式搬迁中，为什么要”除了搬当前访问的桶，再顺手多搬一个”？如果只搬访问到的桶会怎样？
搬迁期间，为什么新插入的元素只能写新表、绝不写旧表？这条规则保证了什么？
delete 一个键之后，map 的内存会释放吗？长生命周期的缓存 map 会因此遇到什么问题？怎么解？
make(map[K]V, hint) 的 hint 有什么用、有什么代价？什么场景下不该给 hint？另外，key/value 都不含指针的 map 为什么对 GC 特别友好？
sync.Map 的 entry.p 为什么要区分 nil 和 expunged 两种”已删除”状态？只用一个 nil 会出什么问题？
为什么 sync.Map 在”写多”时反而比 map + Mutex 慢？请指出写路径上那个 O(n) 的地雷是怎么被触发的。
防哈希碰撞攻击，Go 和 Java 走了两条不同的路。请说明这两条路分别是什么、各自的代价是什么，以及为什么 Java 走不了 Go 那条路。
Redis 的渐进 rehash 和 Go 的渐进式扩容几乎一模一样，但它们解决”没人访问就永远搬不完”这个问题的方式不同。请说明两者的解法差异，以及为什么会有这种差异。

【参考答案】

因为渐进式扩容让 map 有了可变内部状态：新旧两个桶数组 + 搬迁进度指针。并发写时，可能一个 goroutine 在搬迁桶、另一个往即将被释放的旧桶写（数据丢失）；或两个 goroutine 同时搬同一个桶（进度指针双重移动，漏搬/重搬）；或一个扩容了、另一个还按旧哈希定位（看到两个不同的 map 世界）。这些都会撕碎 map 的内部结构，导致内存错乱甚至崩溃——不是”读到旧值”那么温和。
因为”内部加锁”会把锁的成本强加给所有用户，包括那些”单 goroutine 用 map、或已有外层锁”的场景——这是不必要的开销。Go 的哲学是”零成本默认”：map 默认零锁，需要并发时由用户选择加锁粒度（Mutex/RWMutex）或专用结构（sync.Map），把决策权交给最了解自己负载的人。这和 C++“零开销抽象”一脉相承。
sync.Map 在”键集合稳定、写一次读多次、读远多于写”的场景快——读走无锁的原子读 map，写才加锁进脏 map，脏 map 攒够再原子替换。但写入频繁时，双层结构的维护（脏 map 与读 map 的同步、替换）开销超过收益，反而比 map+RWMutex 慢。所以官方建议：默认用 map+锁，只有确认命中”读多写少”才用 sync.Map。
因为 Go 团队观察到：一旦遍历顺序稳定，程序员就会依赖它，写出”依赖 map 顺序”的脆弱代码；而渐进式扩容本来就使遍历顺序不稳定。于是他们主动强化无序——每次遍历从随机桶开始，用随机性强迫开发者”根本没法依赖顺序”。这体现了”宁可少给一点确定性，也要从根上掐断对不该依赖之物的依赖”的设计哲学，同样的哲学还体现在随机化的哈希种子上（防碰撞攻击）。
攻击原理：如果哈希函数确定且公开，攻击者可以离线穷举出大量”哈希值落在同一个桶”的 key，把它们作为请求参数 / JSON 字段名一次性提交。服务端建 map 时这些 key 全落进同一个桶，哈希表退化成链表，插入 n 个 key 从 O(n) 变成 O(n²)，一个几百 KB 的请求就能打满一个核——这就是 Hash DoS。随机种子的作用：每个 map 创建时取一个运行时随机种子参与哈希，进程重启就换，攻击者不知道种子就无法离线预计算碰撞 key，攻击从”可预谋”降级为”撞运气”。它防不住的：鸽笼原理下的正常碰撞（仍由溢出桶处理），以及你自己 key 分布很烂导致的性能问题——那是设计问题，不是安全问题。核心思想是”与其让攻击不可能得手，不如让攻击无法预谋”。
tophash 解决的是”昂贵的完整比较”问题：完整比较 key 可能要读字符串、跳指针、逐字段比，每次都可能是 cache miss；而指纹是 1 字节、8 个连续共 8 字节，正好一个 64 位寄存器宽度，一次载入就能并行筛掉绝大多数不匹配的槽，只对指纹命中的槽做完整比较。8 这个数字是缓存行与内存利用率的拉锯：槽太少（如 1）退化成链表，每步一次指针跳转即一次 cache miss；槽太多（如 64）缓存局部性虽好，但空槽浪费被放大几十倍，且”搬迁一个桶”的粒度太粗，渐进搬迁的摊薄效果就没了。8 个槽能让一个桶的热数据落进一两个缓存行，同时搬迁粒度足够小、浪费可控。
因为内存对齐会吃 padding。以 map[int64]bool 为例：交替存时每对占 9 字节但要按 8 字节对齐，实际 16 字节，8 对共 128 字节，其中 56 字节是纯 padding；分开存时 8 个 key 占 64 字节、8 个 bool 占 8 字节，总共约 72 字节。省下的不是内存，是缓存行——在每秒查几百万次的 map 里，缓存占用直接换算成响应时间。
负载因子 = 元素总数 / 桶数，阈值约 6.5 意味着”平均每个桶装到八成满就翻倍”（桶有 8 个槽，6.5 还留 1.5 个空槽，尚未溢出）。定成 8 不行：元素落桶近似泊松分布、天然不均匀，平均值越接近 8，需要挂溢出桶的桶越多，查找要跳长链、缓存局部性被稀释。定成 3 也不行：内存浪费（为 1000 万元素分配 300 多万桶，大半容量闲置），且翻倍次数变多、累计搬迁量（约 2N 次元素搬迁）和 GC 垃圾量都要重来一轮。6.5 是”再往上溢出桶涨太快、再往下内存浪费太多”的拐点——工程上没有最优解，只有最合适的平衡点。
翻倍扩容：触发于负载因子超阈值（元素太多）；动作是分配两倍大的桶数组；目的是降低负载因子、减少溢出。等量扩容：触发于溢出桶相对主桶过多（此时负载因子可能很低）；动作是分配同样大的桶数组并重排所有元素；目的是整理碎片，不是降低负载因子。等量扩容在桶数不变时仍有意义，因为它改变了两件事：一是把散落在溢出链上的元素重新塞回主桶里被删除空出来的槽，不用再挂溢出桶；二是把”占用/已删除/占用/已删除”的瑞士奶酪状态压实成”占用…/空/空/空”，让空槽集中在尾部、探测能提前终止。收益是更短的探测路径、更短的溢出链、更好的缓存局部性——它治的是”结构老化”，不是”容量不足”。典型场景：先插入 100 万撑出大量溢出桶，再删掉 90 万，count 很低所以翻倍永不触发，但碎片留下了。
如果只搬”当前访问到的桶”，那么一个被百万次访问的热点 key 只会搬迁它所在的那个桶，其余几万个没人碰的桶永远不会被搬迁。后果：旧桶数组永远不能释放（事实上的内存泄漏，GC 也回收不了）；map 永远停在”扩容中”状态，每次操作多一次判断；搬迁进度永不收敛。所以 Go 在每次搬迁时，除了搬目标桶，还从游标位置顺手搬一个或多个桶——这份推进不依赖访问模式，保证只要有持续访问，进度就稳定前进。本质上是给摊还机制加一条”进度保底”的不变量：渐进摊还最怕触发条件永不满足，那就不是摊还，是永久欠债。
因为这条规则保证了”旧桶里的元素只减不增”这个不变量。旧桶元素有限、每次搬走一批、又不会有新元素被塞回来，进度单调推进，搬迁必然收敛。若允许写旧桶，就会出现”一边搬一边塞”的拉锯，进度来回摆动，理论上永远搬不完。用一条写入规则换一个收敛性证明，这在增量算法和并发算法里是极其典型的手法。删除同理：先搬迁目标桶，再在新表里删。
不会。delete 只是把槽位状态改成”已删除”，桶数组只增不减，往 map 里塞 1000 万键再全删掉，内存占用仍停在那个量级。长生命周期缓存（跑了几个月的本地缓存）如果持续增删，还会因溢出桶碎片导致性能缓慢劣化，直到某次触发等量扩容才回来。解法：定期重建 map（新建一个、把活着的键拷过去、旧的丢给 GC），或者做分代轮转（两个 map 交替，定期整个丢掉一个）。这比等运行时自己整理更可控——重建时机由你掌握。
hint 的作用：按预估规模一次性分配好桶，避免早期连续多次翻倍扩容。不给 hint 时，装到 N 个元素大约要经历 log₂N 次翻倍，累计搬迁约 2N 次元素，还产生十几个等待 GC 的旧数组、每次搬迁期间内存临时翻倍；给了准确 hint 则零次搬迁。代价：hint 是一次性按规模分配的内存，给太大就白白占着（map 不会缩容）。所以不该给的场景：规模完全不可预测（给小没用、给大浪费）、小 map（省下的搬迁还不够抵消多占的内存）。规则是给”确信会达到的量级”，不是”万一的上限”。GC 友好的原因：当 key 和 value 都不含指针时，运行时会使用特殊布局把桶类型标记为无指针，GC 直接跳过整个键值区（溢出桶的存活由 map 头部的独立字段保证），扫描成本从 O(元素数) 降到接近 O(1)。在数 GB 级堆上，这是几十毫秒与几百毫秒 STW 的差别——可考虑把 map[string]*User 改成 map[uint64]uint32（ID → 下标），对象另存 slice。
nil 表示”键被删除了”，expunged 表示”键被删除，且已经从 dirty 里彻底抹掉了”。区分它们的必要性来自 dirty 的重建：dirty 为 nil 时的第一次新键写入，需要从 read 里把所有未删除的键浅拷贝过来，已删除的键不拷进 dirty 并被标记为 expunged。expunged 是”这个键不在 dirty 里”这一事实的唯一记录方式。有了它，Store 时就能区分”删了又写回来（p nil，加回 dirty 即可）"和"连 dirty 里都没有（p expunged，须先恢复成 nil 再插进 dirty）“；Load 时两者都返回”不存在”。如果只用一个 nil，就无法在不加锁、只读 read 的情况下判断一个已删除的键是否还在 dirty 里——一旦需要加锁判断，读快路径就废了。一句话：用第三个状态，换读路径的完全无锁。
地雷是”dirty 为 nil 时要从 read 全量重建 dirty”。触发链条：写入一批键 → dirty 重建并填满 → 读时 misses 累加 → misses 达到 len(dirty) 时 dirty 提升为 read、dirty 置为 nil → 此时再写入一个新键，就必须从 read 全量浅拷贝重建 dirty，这是 O(n)。于是”不断新增键”的写模式会反复触发 O(n) 重建：read 里有 100 万个键时，写 10 个新键就是 10 次 100 万的拷贝，写路径上出现周期性尖峰。而 map + Mutex 的写是一次加锁 + 一次哈希表插入，O(1)，没有尖峰。此外每次 read 未命中走 dirty 都要 misses++ 和加锁，还多出双层结构的同步开销与两倍 map 桶结构的内存。所以 sync.Map 本质上是”把写入成本后移并批量化，赌批量之后有一段很长的只读期”；负载不遵守这个赌约（高频新增键、计数器场景、键集合持续流动）就会输。
Go 走”预防”：运行时随机哈希种子，让攻击者无法离线预计算碰撞 key；代价几乎为零，但安全性依赖”种子不泄露”，所以还要用遍历随机化堵住”通过遍历顺序反推哈希分布、进而推断种子”的侧信道——整个安全体系建立在一个假设上，需要额外机制保护。Java 走”缓解”：单桶链表过长时转成红黑树，把最坏查找从 O(n) 降到 O(log n)，不管攻击者多聪明都被兜住；代价是每个用户都要背负树化的复杂度、内存开销和旋转成本，且 key 需要可比较。Java 走不了 Go 那条路的原因：String.hashCode() 是语言规范写死的确定性算法（s[0]*31^(n-1) + ...），因为哈希值必须跨 JVM、跨版本保持一致（序列化、分布式缓存都依赖它），不可能加随机种子——一个历史包袱决定了整个安全策略的走向。核心对照：便宜的方案需要更多辅助机制堵漏洞，昂贵的方案贵在它不依赖任何假设。
相同点：都有新旧两张表 + 搬迁进度游标；每次增删改查顺带搬一个桶；搬迁期间新增只写新表；查找先查旧表再查新表——几乎同一套设计的独立实现，动因都是”大表搬迁不能造成毫秒级卡顿”。差异在”没人访问就永远搬不完”的解法：Redis 用后台定时搬迁——服务器时间事件循环（serverCron / databasesCron）在空闲时主动搬一批（有时间与步数上限，避免自己卡住自己）；Go 用强制推进——每次搬迁除目标桶外，还从游标位置顺手多搬一个，使进度不依赖访问模式。原因是约束不同：Redis 有事件循环这个”免费的时钟”，而 Go 的 map 是一个纯数据结构，没有自己的 goroutine 和后台时钟，只能借调用方的手驱动。代价也对应：Redis 的搬迁完全不受访问模式影响，Go 的方案在”没人用这个 map”时扩容会一直停在中途（但没人用也就没人关心）。一句话：约束决定设计，Redis 有事件循环，Go 的 map 什么都没有。

徐术挺-漫思录

探索

06-map