关键字段#

为什么是 8 个？#

8 是精心选择的平衡值：

• 太小：溢出桶太多，查找效率下降
• 太大：桶太大，缓存局部性差
• 8 个键值对 + tophash 刚好适合 CPU 缓存行（64 字节）

tophash 的作用#

tophash 存储每个键哈希值的高 8 位，用于快速过滤不匹配的槽位：

tophash 的特殊值：

触发条件#

1
func mapassign(t *maptype, h *hmap, key unsafe.Pointer) {
2
    // ... 赋值逻辑
3

4
    // 触发条件 1：负载因子超过 6.5
5
    if !h.growing() && overLoadFactor(h.count+1, h.B) {
6
        hashGrow(t, h)  // 增量扩容（翻倍）
7
    }
8

9
    // 触发条件 2：溢出桶太多
10
    else if tooManyOverflowBuckets(h.noverflow, h.B) {
11
        hashGrow(t, h)  // 等量扩容（整理）
12
    }
13
}

增量扩容（翻倍）#

等量扩容（整理）#

当溢出桶太多但负载因子不高时（大量删除后重新插入），等量扩容不增加桶数，只是重新排列数据，消除空槽和溢出桶：

1
扩容前（B=1, 2个桶，但有很多空槽和溢出桶）：
2
  桶 0: [A, _, C, _, E, _, G, _] → 溢出桶: [I]
3
  桶 1: [B, _, D, _, F, _, H, _] → 溢出桶: [J]
4

5
等量扩容后（B=1, 2个桶，紧凑排列）：
6
  桶 0: [A, C, E, G, I, _, _, _]
7
  桶 1: [B, D, F, H, J, _, _, _]

扩容期间的查找#

扩容期间，查找需要同时检查新旧桶：

1
func mapaccess1(t *maptype, h *hmap, key unsafe.Pointer) unsafe.Pointer {
2
    hash := t.hasher(key, h.hash0)
3
    bucket := hash & bucketMask(h.B)
4

5
    b := (*bmap)(add(h.buckets, bucket*uintptr(t.bucketsize)))
6

7
    // 如果正在扩容，还要检查旧桶
8
    if h.growing() {
9
        oldBucket := hash & bucketMask(h.B - 1)
10
        oldB := (*bmap)(add(h.oldbuckets, oldBucket*uintptr(t.bucketsize)))
11
        // 如果旧桶还没搬迁，在旧桶中查找
12
        if !evacuated(oldB) {
13
            b = oldB
14
        }
15
    }
16
    // ... 在 b 中查找
17
}

预分配大小#

1
// 不预分配：多次扩容
2
m := make(map[string]int)
3
for i := 0; i < 10000; i++ {
4
    m[key(i)] = i  // 触发约 14 次扩容
5
}
6

7
// 预分配：一次分配
8
m := make(map[string]int, 10000)  // B = 14, 2^14 = 16384 > 10000

key 类型的选择#

常见陷阱#

1
// 陷阱 1：不能取 map 元素的地址
2
// m["key"] 是不可寻址的（因为扩容时地址会变）
3
// _ = &m["key"]  // 编译错误
4

5
// 陷阱 2：nil map 可以读但不能写
6
var m map[string]int
7
_ = m["key"]  // 返回 0，不 panic
8
m["key"] = 1  // panic: assignment to entry in nil map
9

10
// 陷阱 3：遍历时修改
11
for k, v := range m {
12
    m[k] = v * 2  // 修改已有 key 是允许的
13
    m["new"] = 1  // 添加新 key → 运行时 panic
14
}

为什么需要 Swiss Tables？#

原有的溢出桶链表设计存在几个问题：

1. 缓存不友好：溢出桶通过指针链接，遍历时缓存命中率低
2. 内存开销：每个溢出桶都有独立的 bmap 头部，小对象分配开销大
3. GC 扫描成本：溢出桶链表增加了 GC 需要扫描的指针数量

Swiss Tables 通过**开放寻址（open addressing）和元数据字节（metadata bytes）**解决了这些问题。

Swiss Tables 核心设计#

元数据字节（ctrl） 是 Swiss Tables 的关键创新：

1
// 每个槽的元数据字节编码了哈希的高 7 位
2
const (
3
    emptyCtrl    = 0b10000000  // 空槽
4
    deletedCtrl  = 0b11111110  // 已删除（墓碑标记）
5
    // 其他值：hash(key) >> 57 的结果（高 7 位 + 最低位设为 1）
6
)

查找过程#

关键优化：Swiss Tables 使用 SIMD 指令（如 SSE2 的 _mm_cmpeq_epi8）一次比较 16 个元数据字节，大幅加速查找。

与旧实现的对比#

渐进式迁移#

Go 1.25 通过构建标签（build tag）实现了渐进式迁移：

• runtime/map.go → 旧实现（保留用于不支持 Swiss Tables 的架构）
• runtime/map_noswiss.go → 旧实现的辅助文件
• runtime/map_swiss.go → Swiss Tables 的运行时胶水层
• internal/runtime/maps/ → Swiss Tables 核心实现

在默认情况下，Go 1.25 在支持的架构上使用 Swiss Tables。可以通过 GOEXPERIMENT=noswiss 环境变量回退到旧实现。

源码参考#

Swiss Tables 的核心实现位于 internal/runtime/maps/，主要文件包括：

• table.go — 表结构和核心操作
• group.go — 组（Group）抽象
• runtime.go — 运行时集成

Q1：map 的负载因子为什么是 6.5？#

6.5 是经过大量基准测试得出的经验值。每个桶 8 个槽，负载因子 6.5 意味着平均每个桶约 81% 满，在查找效率和内存利用率之间取得平衡。Java HashMap 的负载因子是 0.75，但它的桶结构不同（每个桶 1 个元素 + 链表/红黑树）。

Q2：为什么 map 遍历顺序是随机的？#

Go 团队认为：如果开发者依赖固定遍历顺序，会在不同 Go 版本间产生不可移植的代码。随机化强制开发者不依赖顺序，提高代码的健壮性。

Q3：sync.Map 和 map+mutex 怎么选？#

• 读多写少：sync.Map 更优（读操作无锁）
• 写多读少：map + sync.RWMutex 更优（sync.Map 的写操作开销大）
• key 相对固定：sync.Map 更优

Q4：map 扩容时性能会下降吗？#

渐进式扩容将开销分摊到每次操作中，单次操作的性能下降很小（最多搬迁 2 个桶）。但在极端情况下（大量数据需要搬迁），整体吞吐量会暂时下降。

Q5：为什么不能对 map 元素取地址？#

因为扩容时，所有键值对会被搬迁到新的内存位置，之前的地址会失效。如果允许取地址，就会产生悬垂指针。