【go】go语言slice/map的产生背景，及原理理解-CSDN博客

本文链接：https://blog.csdn.net/m0_74282926/article/details/147522876

介绍一下Slice

先讲一下slice的产生背景，首先，go本身是有数组的，但是不会自动扩容，然而实际工作中会有很多场景是要求能自动扩容的，比如说你接用户的数据，你肯定要设置一个可以自动扩容的数组来接，因为你没办法预测他会传多大的数据，提前设置的数组过大或者过小都不合适，因此，go的slice应运而生
slice结构包含一个指向底层数组的指针，长度，容量。这样的设置就可以看出他是一个轻量级的容器，因为实际上只是一个对底层数组的引用。
slice的扩容机制，在长度超过容量的时候，如果容量<1024那么双倍扩容，而如果容量>1024进行1.25倍扩容，这种设计是为了平衡内存和性能。值得注意的是，扩容的时候底层数组会重新分配，内存地址发生变化。
slice还有一个优点是：nil切片可以直接作为空集合使用。主要用在函数返回值和延迟初始化

// 函数返回值
func GetIDs() []int {
    // 如果无数据，返回nil而非空切片，节省内存
    return nil
}

ids := GetIDs()
if ids == nil {
    fmt.Println("No data") // 可明确区分"无数据"和"空数据"
}

// 延迟初始化
var cache []string  // 初始为nil

func AddToCache(item string) {
    cache = append(cache, item) // 首次调用时自动初始化
}

var s []int          // nil切片

// 1. 遍历：不会panic（相当于遍历空集合）
for i, v := range s {
    fmt.Println(i, v) // 无输出
}

// 2. 读取：不会panic（返回零值）
fmt.Println(s[0])    // panic: runtime error（但len(s)=0时访问会panic）
fmt.Println(s[:])    // []（安全截取，返回空切片）

// 3. 追加元素：自动初始化底层数组
s = append(s, 1)     // 自动分配底层数组，s不再是nil
fmt.Println(s)       // [1]

在函数返回值中使用，可以直接返回nil，而不是空切片，节省内存。
延迟初始化中可以明白，与显示初始化切片相比空切片更加节省内存，并且append range操作空切片是安全的。

介绍一下map

先讲一下map的产生背景：主要是为了解决切片/数组的使用缺陷，实际场景更倾向于用键来索引值，而不是单纯的数字索引，比如通过用户id查用户信息。
map的结构，go中的map是一个8Byte的指针，指向hmap结构体（理解为哈希map），hmap又包含若干个bmap数组（俗称的桶bucket）每个bmap底层都采用链表结构。值得注意的是map不支持并发读写，hmap中会有一个字段flags标识写入状态。
通过工作过程理解存储原理：
首先定义的map变量指向hmap，hmap中字段buckets又指向n个bmap（桶），每一个桶存8个键值对（键和值是分开存的），在8个kv前面会有8个tophash，tophash存储key经过hash运算后的高8位，这玩意可以用来快速定位要查的key是否存在在桶里，最后会有一个bmap类型指针，指向溢出桶，溢出桶结构与bmap桶相同，主要是为了减少扩容次数引入的，当一个普通桶bmap存满时，链接的还有可用的溢出桶，就会往溢出桶里面存。在hash认为要分配的桶数目大于2^4就会预分配溢出桶

为什么要把bmap里的8个k-v对分开存？首先前面说了bmap底层是链表，如果连着存会出现[string1, int1, string2, int2]这样，你这个链表到底是string类型还是int类型呢，int是8Byte，string就是16Byte，会产生内存对齐的问题，导致内存空间浪费，所以用[string1, string2], [int1, int2]这样来存

负载因子：存储键值对数目 / 桶数目

扩容机制：当一个桶（bucket）填满，或者负载因子超过一定阈值时，Go 会启动扩容流程。
要扩容时会弄一组大小更大的 buckets并且用oldbuckets指针指向老的buckets数组，采用渐进式扩容。为什么要这样扩容而不是直接复制新桶呢？因为在存储数据比较多的时候直接一次迁移所有的桶花费很高，所以扩容时先弄一个合适大小的桶，通过oldbuckets指针指向旧数据，确保对旧数据的链接，再增加一个字段nevacuate记录迁移进度，当hash表每次读写时如果检测到当前处于扩容阶段，就完成一部分键值对迁移，一直到所有旧桶全部迁移成功。

这种，将键值对的迁移通过时间分配到多次hash操作的扩容方式，称之为渐进式扩容，可以避免一次性扩容带来的性能抖动

其实还有其他的扩容机制，比如等量扩容和小map扩容
等量扩容：一般发生情况是map中大量kv被删除，但是却没有超过设定的负载因子阈值（渐进式扩容没有触发），此时bucket会变得很稀疏，空间被浪费；这时会创建同样大小的新buckets数组，重新紧凑排列元素，压缩空间
小map扩容：当map很小的时候，go会直接一次性完成迁移，此时成本相较于渐进式扩容是很低的

map源码注解

// Hash map 的主结构
type hmap struct {
	count     int     // 当前存储的键值对数量（影响 len(map)）
	flags     uint8   // map 的状态标志（如只读标记）
	B         uint8   // 表示 2^B 个 bucket
	noverflow uint16  // 溢出 bucket 的近似数量（用于估算）
	hash0     uint32  // 哈希种子（防止哈希冲突攻击）

	buckets    unsafe.Pointer // 指向当前的 buckets 数组
	oldbuckets unsafe.Pointer // 若正在扩容，指向旧的 buckets
	nevacuate  uintptr        // 渐进式扩容时的迁移进度计数

	extra *mapextra // 一些可选字段（如 overflow 桶指针）
}

// 单个 bucket
type bmap struct {
	tophash [8]uint8 // 每个 key 哈希值的高位（加速查找）

	// 后面紧跟：
	// - bucket 内的所有 key（连续排放）
	// - bucket 内的所有 value（连续排放）
	// - 一个 overflow 指针（指向下一个溢出桶）
}

// 存储额外信息
type mapextra struct {
	overflow    *[]*bmap // 当前 buckets 的 overflow 桶列表
	oldoverflow *[]*bmap // 扩容时旧桶的 overflow 桶列表
	nextOverflow *bmap   // 下一个可用的空闲 overflow 桶
}