go map的桶数组初始为连续内存块，但溢出桶离散分配且无地址规律，导致遍历局部性差、缓存命中率低；单个bucket内key与value分段紧凑布局以避免对齐填充。
桶数组不是连续内存块，但初始分配时大概率落在相邻页内
Go 的 buckets 指针指向的是一整块 malloc 分配的连续内存，用于存放所有主 bucket（数量为 2^B）。这点容易误解为“每个 bucket 单独 malloc”，其实不是——运行时一次性申请足够空间，按固定结构体布局填充。但要注意：这块内存的物理地址是否真正连续，取决于底层 malloc 实现和当前内存碎片状况。实测中，小容量 map（如 make(map[string]int, 100)）的桶数组常落在 1–2 个连续内存页（4KB/页）内；而经历多次扩容后，新桶数组与旧数组地址毫无关联，甚至跨 NUMA 节点。
单个 bucket 内部是紧凑分段布局，无 key-value 交错
每个 bucket 固定最多存 8 对键值对（bucketCnt = 8），但内存排布是「tophash 数组 + 所有 key 连续排列 + 所有 value 连续排列 + overflow 指针」。这种设计直接规避了因类型对齐导致的 padding 浪费。例如 map[int64]int8：如果 kv 交错，int64（需 8 字节对齐）后紧跟 int8，编译器必须插入 7 字节 padding；而分段排布后，key 区域整体按 int64 对齐，value 区域按 int8 自由紧贴，节省显著。
常见错误现象：unsafe.Sizeof 查单个 bucket 结构体大小 ≠ 实际内存占用 —— 因为运行时会根据 key/value 类型动态计算偏移，不生成固定 struct。
桶之间没有固定步长，CPU 预取器难以建模
遍历 map 时，CPU 无法像遍历切片那样预测下一个 bucket 地址。原因有三：
- 桶索引由哈希值低 B 位决定，分布随机，无地址步进规律
- 溢出 bucket 是单独 malloc 分配、链表连接，地址完全离散
- 扩容期间同时扫描
buckets[i]和oldbuckets[i]，物理地址跳跃加剧
这导致 L1/L2 cache miss 率上升，尤其在老款 Intel CPU（如 Skylake）上，实测扩容后立即遍历百万级 map，平均每次 miss 延迟增加 12–18 ns。预分配能缓解，是因为它让桶数组长期稳定、地址局部性更好，但无法消除哈希本质带来的随机性。
overflow 桶破坏局部性，且无法被编译器优化掉
当某个 bucket 插入第 9 个元素时，运行时 malloc 一个新 bucket，并用指针链到原 bucket 的 overflow 字段。这个新 bucket 不在主桶数组内，地址完全独立，且后续溢出桶可能分散在堆各处。即使你只用 make(map[string]*struct{}, n) 预分配，只要哈希冲突多（比如大量 key 的 hash 低 B 位相同），就会触发溢出链，彻底打乱访存局部性。
性能影响比想象中更重：value 是指针类型时，一次 map 访问要先读 bucket → 再读 overflow 指针 → 再解引用跳转到另一内存页 → 最后读 value。三次非顺序内存访问，预取器基本失效。
真正的坑不在“怎么算桶地址”，而在假设“地址有规律可循”。Go 的 map 就是故意打散局部性来防 DOS 攻击，任何试图靠地址步长做优化的逻辑，都会在扩容、溢出、或不同 Go 版本间失效。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
