Go语言 on 你怂你mua

Go Map 1.24新实现

Fri, 12 Dec 2025 00:00:00 +0000

底层结构

源码：src/internal/runtime/maps

使用Directory管理多个table，Directory是 Table的数组 ，大小为2^globalDepth。如果globalDepth=2，那Directory最多有4个表，分为0x00、0x01、0x10、0x11。Go通过key的hash值的前 globalDepth 个bit来选择table。这是一种“extendible hashing”，这是一种动态哈希技术，其核心特点是通过动态调整使用的哈希位数(比如上面提到的globalDepth)来实现渐进式扩容。比如：初始可能只用1位哈希值来区分，需要时可以扩展到用2位，再需要时可以扩展到用3位，以此类推。

关键源码：

type Map struct {
	// 已填充槽位的数量（即所有表中的元素总数）。
    // 不包含已删除的槽位。
    // 必须放在结构体的第一个字段
    //（编译器已知，用于 len() 内建函数）。
	used uint64

	// 哈希种子
	seed uintptr

	// 通常dirPtr指向一个tables数组
    // directory [] *Table
    // 该数组的长度（dirLen）为 `1 << globalDepth`。
    // 多个目录项可能指向同一个表。
    // 小 map 优化：如果 map 中的元素数量始终不超过abi.SwissMapGroupSlots=8，则可以完全放入一个单独的 group 中。
    // 在这种情况下，dirPtr 直接指向一个 group。
    // 此时，dirLen 为 0。used 表示该 group 中已使用的槽位数量。
    // 注意：小 map 永远不会有已删除的槽位
    //（因为不存在需要维护的探测序列）。
	dirPtr unsafe.Pointer  
	dirLen int

	// 用于表目录（table directory）查找的比特数。
	globalDepth uint8

	// 在进行目录（directory）查找时，需要从哈希值中右移（丢弃）的比特数。
    // 在 64 位系统上，该值为 64 - globalDepth。
	globalShift uint8

	// writing 是一个标志位，在 map 被写入时通过异或 1（XOR 1）来翻转。
    // 通常在写入期间它被置为 1；
    // 但如果存在多个并发写入者，持续翻转该标志
    // 可以提高双方检测到竞争条件（data race）的概率。
	writing uint8

	// clearSeq 是对 Clear 调用次数的序列计数器。
    // 用于在迭代过程中检测 map 是否被清空（clear）。
	clearSeq uint64
}

type table struct {
	// 已填充槽位的数量（即表中元素的数量）。
	used uint16

	// 槽位的总数量（始终为 2 的 N 次幂）。
    // 等于 `(groups.lengthMask + 1) * abi.SwissMapGroupSlots`。
	capacity uint16

	// 在无需 rehash 的前提下仍可使用的槽位数。
    // 当 used + tombstones > loadFactor * capacity 时触发 rehash，
    // 计入 tombstones，以防止哈希表被墓碑项过度填充。
    // 该字段表示距离下一次 rehash 还剩余的空槽位数量。
	growthLeft uint16

	// 用于定位到该表的目录查找所需的比特位数。
    // 注意：当目录已经增长但该表还未被分裂时，
    // 该值可能小于 globalDepth。
	localDepth uint8

	// 该表在 Map 目录中的索引。这里指的是目录中指向该表的
    // 第一个索引位置；该表可能对应目录中的多个连续索引。
    // 若该表已过期（不再存在于目录中），则 index 取值为 -1。
	index int

	// groups 为槽位组数组。每个组包含 abi.SwissMapGroupSlots = 8 个
    // 键/值槽位及其控制字节。表的 groups 数组大小固定，
    // 当需要扩容时，会在 rehash 时用新表替换。
    // TODO(prattmic)：键和值交错存储可提高缓存局部性，
    // 但对某些类型会浪费空间（如 uint8 键 + uint64 值）。
    // 可考虑在这些情况下将键集中存放以节省空间。
	groups groupsReference
}

type groupsReference struct {
    data unsafe.Pointer //group数组
    lengthMask uint64 //len(group)-1，方便快速求模
}

type group struct {
    ctrl  ctrlGroup        // 8 字节
    slots [8]slot
}

// 控制字
type ctrlGroup uint64
// 每个control byte 包含状态(1byte---空、删除、占用)+h2(哈希低7位)

特性

多个 directory index 可以指向同一个 table
directory 里存的只是指针

初始化流程

关键源码：

func NewMap(mt *abi.SwissMapType, hint uintptr, m *Map, maxAlloc uintptr) *Map {
	if m == nil {
		m = new(Map)
	}

	m.seed = uintptr(rand())

	if hint <= abi.SwissMapGroupSlots {
		// A small map can fill all 8 slots, so no need to increase
		// target capacity.
		//
		// In fact, since an 8 slot group is what the first assignment
		// to an empty map would allocate anyway, it doesn't matter if
		// we allocate here or on the first assignment.
		//
		// Thus we just return without allocating. (We'll save the
		// allocation completely if no assignment comes.)

		// Note that the compiler may have initialized m.dirPtr with a
		// pointer to a stack-allocated group, in which case we already
		// have a group. The control word is already initialized.

		return m
	}

	// Full size map.

	// Set initial capacity to hold hint entries without growing in the
	// average case.
	targetCapacity := (hint * abi.SwissMapGroupSlots) / maxAvgGroupLoad
	if targetCapacity < hint { // overflow
		return m // return an empty map.
	}

	dirSize := (uint64(targetCapacity) + maxTableCapacity - 1) / maxTableCapacity
	dirSize, overflow := alignUpPow2(dirSize)
	if overflow || dirSize > uint64(math.MaxUintptr) {
		return m // return an empty map.
	}

	// Reject hints that are obviously too large.
	groups, overflow := math.MulUintptr(uintptr(dirSize), maxTableCapacity)
	if overflow {
		return m // return an empty map.
	} else {
		mem, overflow := math.MulUintptr(groups, mt.GroupSize)
		if overflow || mem > maxAlloc {
			return m // return an empty map.
		}
	}

	m.globalDepth = uint8(sys.TrailingZeros64(dirSize))
	m.globalShift = depthToShift(m.globalDepth)

	directory := make([]*table, dirSize)

	for i := range directory {
		// TODO: Think more about initial table capacity.
		directory[i] = newTable(mt, uint64(targetCapacity)/dirSize, i, m.globalDepth)
	}

	m.dirPtr = unsafe.Pointer(&directory[0])
	m.dirLen = len(directory)

	return m
}

源码解读：初始化时会根据 hint 的值进入不同的初始化逻辑：

hint<=8，小map

对于小map，指定容量hint<=8，做了优化，不再分配一个table数组，dirPtr直接引用分配 一个group
hint>8

a> 首先计算目标容量 targetCapacity，算出需要多少slot，才能在“平均负载”下容纳 hint 个元素

b> 计算 directory 大小dirSize（table 数）（需要多少个 table，才能容纳 targetCapacity ）

c> 计算总的 group 数量和总内存。

d> 设置 globalDepth / globalShift

e> 分配directory并 创建table（初始化时table内部的localdepth=globalDepth）

f> directory 写入Map（unsafe），最后返回Map。

添加流程

关键源码：

func (m *Map) PutSlot(typ *abi.SwissMapType, key unsafe.Pointer) unsafe.Pointer {
	if m.writing != 0 {
		fatal("concurrent map writes")
	}

	hash := typ.Hasher(key, m.seed)

	// Set writing after calling Hasher, since Hasher may panic, in which
	// case we have not actually done a write.
	m.writing ^= 1 // toggle, see comment on writing

	if m.dirPtr == nil {
		m.growToSmall(typ)
	}

	if m.dirLen == 0 {
		if m.used < abi.SwissMapGroupSlots {
			elem := m.putSlotSmall(typ, hash, key)

			if m.writing == 0 {
				fatal("concurrent map writes")
			}
			m.writing ^= 1

			return elem
		}

		// Can't fit another entry, grow to full size map.
		//
		// TODO(prattmic): If this is an update to an existing key then
		// we actually don't need to grow.
		m.growToTable(typ)
	}

	for {
		idx := m.directoryIndex(hash)
		elem, ok := m.directoryAt(idx).PutSlot(typ, m, hash, key)
		if !ok {
			continue
		}

		if m.writing == 0 {
			fatal("concurrent map writes")
		}
		m.writing ^= 1

		return elem
	}
}

源码解读：

首先进行并发写检测，保障线程安全。
然后计算key的hash，并标记写入状态，防止并发写。
判断当前map是否已经分配了，如果没有分配，会先分配一个group（小map）。

a. 如果当前map是小map
1. 如果是小表且未满，直接插入，返回元素槽指针。
2. 如果小表已满，升级为大表（分配table并迁移数据）
b. 如果当前map是大map
1. 根据H1计算目录索引，定位table（与查找相同）
2. 调用大map的插入函数，若table扩容则重试
3. 插入成功返回与元素槽指针
再次检测并发写，防止并发写破坏数据。

小map写入细节

首先获取group的引用，并结合H2对所有控制字进行比对。
若存在相同的，比对是否存在相同key，如果存在则返回对应value槽指针。
不存在相同的，查找空槽，准备写入新key，如果没有空槽，说明并发写入或者逻辑错误。
写入key和value。
更新控制字和used计数。
返回value槽指针。

大map写入细节

首先根据hash的高位H1和group的数量定位探查序列。
定义变量，记录第一个已删除槽，以便后续使用。
探查循环，遍历group，查找与H2匹配的槽。
若有匹配的槽，对比key，若key需要更新，则拷贝新key
无匹配槽，查找空槽或已删除槽（tombstone）。若有空槽且growthleft>0，优先复用空槽，设置控制字，更新计数。若growthleft耗尽（表已满），触发rehash（扩容或分裂），返回nil，false，提示上层重试。

搜索流程

关键源码：

// Get performs a lookup of the key that key points to. It returns a pointer to
// the element, or false if the key doesn't exist.
func (m *Map) Get(typ *abi.SwissMapType, key unsafe.Pointer) (unsafe.Pointer, bool) {
	return m.getWithoutKey(typ, key)
}

func (m *Map) getWithoutKey(typ *abi.SwissMapType, key unsafe.Pointer) (unsafe.Pointer, bool) {
	if m.Used() == 0 {
		return nil, false
	}

	if m.writing != 0 {
		fatal("concurrent map read and map write")
	}

	hash := typ.Hasher(key, m.seed)

	if m.dirLen == 0 {
		_, elem, ok := m.getWithKeySmall(typ, hash, key)
		return elem, ok
	}

	idx := m.directoryIndex(hash)
	return m.directoryAt(idx).getWithoutKey(typ, hash, key)
}

func (m *Map) directoryIndex(hash uintptr) uintptr {
	if m.dirLen == 1 {
		return 0
	}
	return hash >> (m.globalShift & 63)
}

func (t *table) getWithoutKey(typ *abi.SwissMapType, hash uintptr, key unsafe.Pointer) (unsafe.Pointer, bool) {
	seq := makeProbeSeq(h1(hash), t.groups.lengthMask)
	for ; ; seq = seq.next() {
		g := t.groups.group(typ, seq.offset)

		match := g.ctrls().matchH2(h2(hash))

		for match != 0 {
			i := match.first()

			slotKey := g.key(typ, i)
			if typ.IndirectKey() {
				slotKey = *((*unsafe.Pointer)(slotKey))
			}
			if typ.Key.Equal(key, slotKey) {
				slotElem := g.elem(typ, i)
				if typ.IndirectElem() {
					slotElem = *((*unsafe.Pointer)(slotElem))
				}
				return slotElem, true
			}
			match = match.removeFirst()
		}

		match = g.ctrls().matchEmpty()
		if match != 0 {
			// Finding an empty slot means we've reached the end of
			// the probe sequence.
			return nil, false
		}
	}
}

源码解读：

根据map的 used 字段快速判断，如果是空map，直接返回nil。
其次对map的 并发读写 进行检测，存在并发读写直接报错。
计算key的hash（H1-高57位，用于定位group。H2-低7位，用于对比控制字）值。
根据dirLen判断是否是小map。

a. 如果是小map
1. 进入小map的搜索流程，直接从初始化中的单个group中进行查找
2. 获取当前hash的H2，然后遍历group，逐个对比控制字中的H2部分
3. 不匹配就继续下一个，匹配之后，再继续对key校验（只用7位进行校验，存在hash冲突的可能性，虽然很低，1/128）
4. 若key相同，找到val直接返回，若遍历结束也没有匹配项，返回nil结束。
b. 如果不是小map
1. 先根据key的hash的高位（globalDepth）计算出当前 map 的“目录数组”(directory)中的索引，从而定位到应该查找或操作的 table（分表）。（如果目录长度为 1，说明 map 只有一个 table（未分表），所有 key 都在这一个 table 里。否则说明已经分表，用hash的高位来选择table。例如globalDepth = 3，则目录长度为8，globalShift = 61，目录索引为hash»61，即hash的最高3位）
2. 根据hash的 H1 部分计算出table内部遍历的 group的起始位置。（起始位置offset：uint64(H1) & mask，用 h1(hash) 的低若干位（由 mask 决定）作为 group 的初始索引。其中mask = group 数量 - 1。例如group数量为8，mask=0b111，则只取H1的最低3位。）
3. 然后开始查找group内的元素，通过H2与group的8个控制字做并行匹配（复制H2为8份），如果存在匹配的，则继续对key进行比较，如果遇到空槽，说明key不存在，返回nil,false，如果没有找到且没有空槽，继续查找下一个group。

关键点

q：为什么遇到空槽代表不存在key？
a：在插入新key时会沿着探查序列查找第一个空槽或者已删除的空槽，查找时同样沿着探查序列查找，如果key曾经被插入过，一定会在遇到空槽之前被找到（插入时遇到空槽就插入了）

删除过程

关键源码：

func (m *Map) Delete(typ *abi.SwissMapType, key unsafe.Pointer) {
	if m == nil || m.Used() == 0 {
		if err := mapKeyError(typ, key); err != nil {
			panic(err) // see issue 23734
		}
		return
	}

	if m.writing != 0 {
		fatal("concurrent map writes")
	}

	hash := typ.Hasher(key, m.seed)

	// Set writing after calling Hasher, since Hasher may panic, in which
	// case we have not actually done a write.
	m.writing ^= 1 // toggle, see comment on writing

	if m.dirLen == 0 {
		m.deleteSmall(typ, hash, key)
	} else {
		idx := m.directoryIndex(hash)
		m.directoryAt(idx).Delete(typ, m, hash, key)
	}

	if m.used == 0 {
		// Reset the hash seed to make it more difficult for attackers
		// to repeatedly trigger hash collisions. See
		// https://go.dev/issue/25237.
		m.seed = uintptr(rand())
	}

	if m.writing == 0 {
		fatal("concurrent map writes")
	}
	m.writing ^= 1
}

源码解读：

判断当前map是否为空，如果为空，则删除操作无效。同时检查key的类型是否合法，如果不合法直接 panic。
检测并发写状态，保证线程安全。
计算key的hash，如果key类型不匹配则panic。
设置并发写标志。
判断map的大小。

a. 如果是小map
1. 获取group引用，匹配H2。
2. 若有匹配的，再对比key。
3. 找到之后，计数-1，然后清理key和value。
4. 标记slot为空，小map没有探查序列，不需要tombstone直接将控制字设为empty。
5. 如果没有匹配的key，则什么都不做。
b. 如果是大map
1. 通过H1和表容量构造探查序列。
2. 结合H2遍历group，若存在H2匹配的，再对比key。
3. 清理key和value。
4. 设置控制字，如果当前group还有空槽，直接将ctrl（控制字）设置为empty，并回收growthleft（可插入槽数）。否则，设置为deleted（墓碑），墓碑会在rehash时被清理。
5. 如果group没找到目标key，遇到空槽则终止。如果group有空槽，说明key不存在，直接返回。

扩容过程：

小map扩容

扩容节点：小map只能存放8个元素，当插入第9个元素时会触发扩容。调用growToTable

关键源码：

func (m *Map) growToTable(typ *abi.SwissMapType) {
	tab := newTable(typ, 2*abi.SwissMapGroupSlots, 0, 0)

	g := groupReference{
		data: m.dirPtr,
	}

	for i := uintptr(0); i < abi.SwissMapGroupSlots; i++ {
		if (g.ctrls().get(i) & ctrlEmpty) == ctrlEmpty {
			// Empty
			continue
		}

		key := g.key(typ, i)
		if typ.IndirectKey() {
			key = *((*unsafe.Pointer)(key))
		}

		elem := g.elem(typ, i)
		if typ.IndirectElem() {
			elem = *((*unsafe.Pointer)(elem))
		}

		hash := typ.Hasher(key, m.seed)

		tab.uncheckedPutSlot(typ, hash, key, elem)
	}

	directory := make([]*table, 1)

	directory[0] = tab

	m.dirPtr = unsafe.Pointer(&directory[0])
	m.dirLen = len(directory)

	m.globalDepth = 0
	m.globalShift = depthToShift(m.globalDepth)
}

源码解读：

分配新表，新表容量为16，原来2倍，localdepth\globaldepth都为0，index为0。
遍历原来的8个slot，如果非空，重新计算hash，插入到新表。
构建目录指向新表，长度为1。
map进入表模式，后续插入查找都走table逻辑。

大map扩容

扩容节点：在插入流程中，如果当前为大表，且在插入时发现没有空槽，就会出发rehash。

关键源码：

func (t *table) rehash(typ *abi.SwissMapType, m *Map) {
	newCapacity := 2 * t.capacity
	if newCapacity <= maxTableCapacity {
		t.grow(typ, m, newCapacity)
		return
	}
	t.split(typ, m)
}


func (t *table) grow(typ *abi.SwissMapType, m *Map, newCapacity uint16) {
	newTable := newTable(typ, uint64(newCapacity), t.index, t.localDepth)

	if t.capacity > 0 {
		for i := uint64(0); i <= t.groups.lengthMask; i++ {
			g := t.groups.group(typ, i)
			for j := uintptr(0); j < abi.SwissMapGroupSlots; j++ {
				if (g.ctrls().get(j) & ctrlEmpty) == ctrlEmpty {
					// Empty or deleted
					continue
				}

				key := g.key(typ, j)
				if typ.IndirectKey() {
					key = *((*unsafe.Pointer)(key))
				}

				elem := g.elem(typ, j)
				if typ.IndirectElem() {
					elem = *((*unsafe.Pointer)(elem))
				}

				hash := typ.Hasher(key, m.seed)

				newTable.uncheckedPutSlot(typ, hash, key, elem)
			}
		}
	}

	newTable.checkInvariants(typ, m)
	m.replaceTable(newTable)
	t.index = -1
}

func (t *table) split(typ *abi.SwissMapType, m *Map) {
	localDepth := t.localDepth
	localDepth++

	// TODO: is this the best capacity?
	left := newTable(typ, maxTableCapacity, -1, localDepth)
	right := newTable(typ, maxTableCapacity, -1, localDepth)

	// Split in half at the localDepth bit from the top.
	mask := localDepthMask(localDepth)

	for i := uint64(0); i <= t.groups.lengthMask; i++ {
		g := t.groups.group(typ, i)
		for j := uintptr(0); j < abi.SwissMapGroupSlots; j++ {
			if (g.ctrls().get(j) & ctrlEmpty) == ctrlEmpty {
				// Empty or deleted
				continue
			}

			key := g.key(typ, j)
			if typ.IndirectKey() {
				key = *((*unsafe.Pointer)(key))
			}

			elem := g.elem(typ, j)
			if typ.IndirectElem() {
				elem = *((*unsafe.Pointer)(elem))
			}

			hash := typ.Hasher(key, m.seed)
			var newTable *table
			if hash&mask == 0 {
				newTable = left
			} else {
				newTable = right
			}
			newTable.uncheckedPutSlot(typ, hash, key, elem)
		}
	}

	m.installTableSplit(t, left, right)
	t.index = -1
}

func (m *Map) installTableSplit(old, left, right *table) {
	if old.localDepth == m.globalDepth {
		// No room for another level in the directory. Grow the
		// directory.
		newDir := make([]*table, m.dirLen*2)
		for i := range m.dirLen {
			t := m.directoryAt(uintptr(i))
			newDir[2*i] = t
			newDir[2*i+1] = t
			// t may already exist in multiple indicies. We should
			// only update t.index once. Since the index must
			// increase, seeing the original index means this must
			// be the first time we've encountered this table.
			if t.index == i {
				t.index = 2 * i
			}
		}
		m.globalDepth++
		m.globalShift--
		//m.directory = newDir
		m.dirPtr = unsafe.Pointer(&newDir[0])
		m.dirLen = len(newDir)
	}

	// N.B. left and right may still consume multiple indicies if the
	// directory has grown multiple times since old was last split.
	left.index = old.index
	m.replaceTable(left)

	entries := 1 << (m.globalDepth - left.localDepth)
	right.index = left.index + entries
	m.replaceTable(right)
}

源码解读：

首先判断预期的新容量（旧容量的两倍）是否达到了单表的最大group容量（maxTableCapacity=1024）
如果没超过，则进入扩容流程（grow）
如果超过了，则进入分裂流程（split）

扩容流程详解（grow）

首先创建新table（但还未替换）。
判断旧table是否为空，迁移所有元素（新建table时capacity=0，判断避免空表扫描）。
遍历所有group，遍历每个group内的8个slot，遇到delete或者empty的直接跳过，获取存活的key\elem，重新计算hash。
插入新table（unchecked）（新table是一定有足够空间的）。
完整性校验（checkInvariants）（used数量、ctrl状态、 growthLeft 、 map.used 一致性）。
替换旧table（replaceTable）。
标记旧table失效（t.index = -1）。

分裂流程详解（split）（ Extendible Hashing ）

当一个table已经到达最大容量（ maxTableCapacity ），但还是要继续插入时会进入split。
table的localdepth加1（localdepth表示当前table负责的hash范围，区别globaldepth表示当前directory使用的hash的范围）。
创建左右两个新table。
计算分流掩码mask（用于后续决定元素流向哪个table）。
扫描旧table，逐个slot进行分流。跳过delete\empty，取key\elem并重新hash。
根据mask，用新增的那一位hash来决定该slot流入哪个table（见上方源码）。
插入新table，不需要检查，保证成功。
将split的结果加入到directory中（如果directory的globalDepth位数不够用会扩容）。
废弃当前table。

分裂过程中第8步详解

判断当前directory的globalDepth位数是否够用。（split会使得localdepth+1，如果超过的globalDepth位数则需要扩容directory）

如果需要翻倍，创建新的dir数组，原来的2倍容量。

a. 复制并维护index。

b. 更新 globalDepth / globalShift 。

c. 原子替换 directory（将原来的dir指针指向新的数组）。

left覆盖原来old table负责的起始位置。

计算right table的index偏移量并设置right index。

Go内部锁

Fri, 12 Dec 2025 00:00:00 +0000

Mutex

Mutex由 state 和 sema 两个字段组成，state表示当前互斥锁的状态，sema是用于控制锁状态的信号量。

type Mutex struct {
	state int32		// 状态
	sema  uint32  // 信号量
}

互斥锁的状态的 低三位 分别表示互斥锁 是否锁定（mutexLocked）（1是锁定）、 是否有唤醒的goroutine(mutexWoken)（1是有）、当前线程 是否是饥饿状态(mutexStarving)（1是饥饿）。前面的就表示当前互斥锁上等待的goroutine的个数。

Mutex的状态

Mutex有两种模式，正常模式和饥饿模式。

在正常模式下，锁的等待者会按照 先进先出 的顺序去获取锁，但是刚被唤醒的goroutine与新创建的goroutine竞争时，大概率获取不到锁。为了减少这种情况的发生，一旦goroutine超过1ms没有获取到锁，他就会将当前互斥锁切换到饥饿模式，防止部分goroutine被饿死。

在饥饿模式下，互斥锁会直接交给 等待队列最前面 的goroutine。新的goroutine在该状态下不能获取锁，也不会进入自旋状态，他只会在 队列末尾 等待。如果一个goroutine获得了互斥锁并且他在队列末尾或者他等待的时间少于 1ms ，那么当前互斥锁就会切换为 正常状态。

正常状态能提供更好的性能，饥饿模式能够避免goroutine由于陷入等待无法获取锁造成的高延时。

加锁和解锁

加锁：在lock方法中，他会先通过CAS（CompareAndSwapInt32方法）去判断能否获取到锁，获取到的话就会将mutexLocked设置为1。如果获取时他的状态不是0，也就会获取不到锁，他会调用lockslow方法来尝试通过 自旋 来等待锁的释放。当前线程进入自旋的话会一直 保持CPU的占用，持续检查某些条件是否为真。处理完自旋相关的逻辑之后，互斥锁会根据上下文计算当前互斥锁的最新状态。然后使用CAS（CompareAndSwapInt32方法）更新状态，如果获取不到会通过 信号量 来保证资源不被两个goroutine获取。

解锁：解锁会先使用atomic.addint32()方法来快速解锁，如果成功就释放，不成功的话会进行慢速解锁（unlockslow方法），他会先 校验锁的状态，如果已经解锁了，会报错。然后正常情况下分为正常模式和饥饿模式处理，正常模式下如果有等待者，会唤醒等待者并移交锁的所有权，没有等待者的话直接返回。在饥饿模式下，他会将当前锁交给下一个正在尝试获取锁的等待者，然后依然是饥饿状态。

RWMutex

RWMutex结构体中共有5个字段。

type RWMutex struct {
    w           Mutex  // 控制 writer 在 队列 排队
    writerSem   uint32 // 写信号量，用于等待前面的 reader 完成读操作
    readerSem   uint32 // 读信号量，用于等待前面的 writer 完成写操作
    readerCount int32  // reader 的总数量，同时也指示是否有 writer 在队列中等待
    readerWait  int32  // writer 前面 reader 的数量
}

// 允许最大的 reader 数量
const rwmutexMaxReaders = 1 << 30

w：主要提供写锁相关的功能

readerCount：存储了正在执行的读操作的数量

readerWait：表示当前写操作被阻塞时前方等待的读操作的数量

写锁

加锁Lock()：

首先会先调用w.Lock() 阻塞后续的写操作 。因为锁已经被获取，当其他的goroutine获取写锁时会进入 自旋或者休眠。
然后通过 原子操作 (调用atomic.AddInt32方法)将readerCount设置为负数， 阻塞后续的读操作。
然后判断如果有其他的goroutine持有读锁的话，当前goroutine会进入 休眠状态，等待所有读锁读完之后释放writerSem信号量唤醒当前goroutine。
先阻塞写锁后阻塞读锁避免读操作因为连续的写操作饿死。

释放UnLock():

先通过 原子操作 将(调用atomic.AddInt32方法)readerCount设置为正数，释放读锁。
然后通过for循环释放所有因为获取 读锁 而陷入等待的goroutine。
然后调用w.UnLock()释放写锁。

读锁

加锁RLock()：

该方法会通过 原子操作 将(调用atomic.AddInt32方法)readerCount加一。
然后如果返回负数，说明其他goroutine获得了写锁，当前goroutine就会陷入 休眠 等待锁的释放。
如果返回非负数，说明没有goroutine获得写锁，该方法会返回成功。

释放RUnLock():

该方法会通过原子操作将(调用atomic.AddInt32方法)readerCount减一。
如果返回值大于零，直接解锁成功。
如果小于零，说明有一个写操作正在执行。这时会调用rUnlockSlow()方法，他会减少写操作前面等待的读操作的数量readerWait，并在 所有读操作完成之后 触发写操作的信号量writerSem唤醒写线程。

Go语言GMP模型

Fri, 12 Dec 2025 00:00:00 +0000

简介

G 是调度器中待执行的任务，在运行时用 runtime.g 结构体表示（内有_defer字段表示defer链表）。他可以分为三种状态（等待中、可运行、运行中（状态非常多））。结构体中也有m指针字段，跟m进行动态绑定。

M 是操作系统线程，调度器最多可以创建10000个线程，但是最多会有GOMAXPROC（默认当前机器的核数）个线程能够正常运行（可以手动改变）。在go中使用runtime.m表示。他有一个 g0 字段和一个 curg 字段，g0是持有调度栈的goroutine，curg是在当前线程上运行的用户的goroutine。g0他会深度的参与到运行时的调度过程（goroutine的创建、大内存分配）。还有关于处理器 P 的字段

P 是调度器中的处理器，是线程和goroutine的中间层，他可以提供线程需要的上下文，也会负责调度线程上的等待队列。还有处理器的数量是跟线程数相等的。然后在运行时go中使用runtime.p结构体来表示。他存储了处理器持有的运行队列、等待执行的goroutine列表、下个需要执行的goroutine等信息。P中最多存储 256 个g。

g的状态

刚开始创建时为_Gidle状态，初始化完成之后为_Gdead状态。当环境都准备就绪后会进入_Grunnable就绪态，当被调度器调度到时进入_Grunning运行态，当运行时代码中越过用户态进入内核态发生一些系统调用时会进入_Gsyscall状态，当执行完成之后会重新进入_Grunnable就绪态，等待被重新调度。当在用户态视角下发生一些阻塞时（加锁时的阻塞，channel的阻塞）会进入_Gwaiting状态，当某些条件达成之后会被切换成_Grunnable就绪态。当正常的调度完成之后会进入_Gdead被销毁回收。

g0

g0是与m绑定的特殊的goroutine，用于其他的g之间的调度管理。当g0找到要执行的g之后会调用gogo函数将执行权交给当前g，当 g 需要主动让渡或被动调度时会调用m_call函数来把执行权重新交给g0

四种调度类型

主动调度：由 用户 主动发起，通过 runtime.Gosched 方法来实现主动让出当前P的执行权。当前g会由_Grunning状态切换成_Grunnable状态，然后被投递到 全局队列 中。然后执行权回归到g0，g0会继续寻找下一个可执行的g
被动调度：由于一些客观的因素导致当前的g不得不 陷入阻塞 的状态（加锁，channel）。当前g通过 gopark 方法由_Grunning状态切换成_Gwaiting状态，这个G会由 网络轮询器 接手，同时将执行权交给g0。goready方法会将当前g从阻塞状态中恢复，重新进入等待执行的状态。然后这个g会被优先加入到 唤醒这个g 的P的本地队列当中同时优先被调度。
正常调度：执行完成当前g之后会将这个g置为_Gdead状态，并发起下一轮的调度。
抢占调度：当某一个g发生 系统调用 时并超过了一定的时长就会被感知到，然后这个g会和P进行解绑留下g和m绑定（hand off），然后P去寻找其他的空闲m，若没有空闲的就会创建一个新的M。抢占这个动作不再由g0完成，而是有一个全局监控者（monitor g）完成的。因为发起系统调用时需要打破用户态的边界进入内核态，此时 m 也会因系统调用而陷入僵直，无法主动完成抢占调度的行为。

findRunnable函数（寻找可执行的g）

首先P如果执行到了第61次，会从全局队列中获取一个g来执行，并将一个全局队列中的g填充到P的本地队列中。如果本地队列已经满了，会将本地的一半g放回到全局队列中缓解本地压力。
然后从本地队列中尝试寻找可执行的g，如果有，会尝试加锁获取。由于窃取动作发生的频率不是很高，所以一般都能拿到锁，所以说P的本地队列是接近无锁化的。
如果本地队列没有可执行的g，会尝试加锁从全局队列中获取。
如果本地和全局都没有，会获取准备就绪的网络协程。
最后才会尝试去窃取其他P的一半的g（work-stealing机制），会进行4次尝试，其中某次成功获取到之后就会直接返回

Go语言sync.Map

Fri, 12 Dec 2025 00:00:00 +0000

源码版本1.22

数据结构

关键源码：

type Map struct {
	_ noCopy

    // 互斥锁
	mu Mutex

    // 只读map
	read atomic.Pointer[readOnly]

    // 有锁的读写map
	dirty map[any]*entry

    // 只读map的miss次数
	misses int
}

type readOnly struct {

    // 无锁化的只读map
	m       map[any]*entry
	
    // 标记只读map是否缺失数据
    amended bool
}

通过read map（只读）和dirty map + 互斥锁两个map来实现读写分离（空间换取时间） entry的三种状态：

存活态：正常指向元素
软删除态：指向nil（向软删除的数据插入或者更新时会直接通过read map的一个CAS操作进行更新）
硬删除态：指向固定的全局变量expunged（在dirty map中已经物理上删除了）

读流程

首先读取read map，如果amended状态为false，表示read map中已经是全量数据，这时就看能不能再read map中找到数据，然后如果找到的数据他的entry对应为nil或者expunged也表示没找到。
如果read map中没找到并且amended为true时，表示read map中没找到并且read map中不是全量数据时。这时会去dirty map中查找（会加锁），在查找之前会进行一个对read map的 二次检查 （防止在此期间其他goroutine的操作让read map的数据覆盖了），如果read中的amended为false时，就会去read中查找并判断返回。如果read map不可用，就读取dirty中的数据判断返回，并把misses++（到达阈值（跟dirty长度相等）时将read中数据进行覆盖）。

覆盖流程

关键源码misslocked：

func (m *Map) missLocked() {
    m.misses++
    if m.misses < len(m.dirty) {
        return
    }
    m.read.Store(readOnly{m: m.dirty})
    m.dirty = nil
    m.misses = 0
}

如果misses大于等于dirty中数据的数量时，会使用dirty覆盖read并将amended变为false。此时dirty为nil，misses计数器清零。

写流程（插入或更新）

如果read中存在key并且entry不是expunged，就可以通过CAS的操作来进行一个更新（直接将entry指向新插入的数据）
如果read中不存在或者是硬删除态，就会进入dirty中，同样会先进行一个read的二次检查，如果read中没有，就看dirty中是否存在，存在就进行更新操作（修改dirty），不存在就进行插入操作。插入时要判断amended，如果为false，就会执行dirtyLocked流程，并将amended置为true。

dirtyLocked流程

关键源码dirtyLocked：

func (m *Map) dirtyLocked() {
    if m.dirty != nil {
        return
    }


    read, _ := m.read.Load().(readOnly)
    m.dirty = make(map[any]*entry, len(read.m))
    for k, e := range read.m {
        if !e.tryExpungeLocked() {
            m.dirty[k] = e
        }
    }
}

当将dirty覆盖给read之后，dirty应该为nil，如果执行时为nil说明已经执行过了，可以直接返回。如果不是nil，就通过for循环线性的将read中的非删除态数据拷贝回dirty中，并将其中的软删除态的数据更新为硬删除态。

dirtyLocked的拷贝是线性的，性能不好。

诱发dirtyLocked的原因：写多读少 ，大量的新数据的插入，同时很多读操作在read中未命中。造成misslocked，然后又一次写操作越过了read和dirty，就会进入dirtyLocked流程。

删除流程

如果read中存在key，通过CAS的操作将对应的value置为nil（软删除态）
如果read中不存在，去dirty中查找，会先进行二次检查。如果read中不存在并且amended为true，则去dirty中查找删除（物理删除）并返回旧值（方法要返回），然后将misses++。如果read中存在或者amended为false，就会去read中判断删除。

遍历流程

首先获取read，然后判断amended，如果amended为true，就会将dirty中的数据覆盖到read中，并将dirty置为nil并将misses归零。
然后遍历read并执行传入的函数，通过返回值判断何时终止。

Go语言内存分配模型

Thu, 04 Dec 2025 00:00:00 +0000

MCache

简介

MCache与go语言的GMP模型中的 P进行绑定 ，因为真正可运行的线程M的数量与P一致，所以与P绑定更能 节省内存空间，可以保证每个 G 使用MCache时 不需要加锁 就可以获取内存。（因为一个P只有一个M在其上运行，不可能出现竞争，所以没有锁限制，进而加快了内存的分配）

内部构造

如图所示：

MCache中每个 span class 会对应一个 Mspan ，不同span class的mspan的总体长度不同（参考runtime/sizeclass.go）。当其中某个span class对应的mspan已经没有可以提供的object时，MCache会向MCentral申请一个对应的mspan。

特殊size class

对于span class为0和1，也就是 size class为0 的规格刻度内存，MCache实际上没有分配任何内存。Go语言内存管理对内存为0的数据申请做了特殊处理，如果申请的数据大小为0，则将直接返回一个 固定内存地址 ，不会进入Go语言内存管理的正常逻辑。这也是为什么在做channel同步时，会发送一个struct{}数据，因为不会申请任何内存，能够适当节省一部分内存空间。

MCentral

简介

当MCache中的某个size class对应的span被一次次的object上层取走后，如果出现当前size class的span空缺的情况，MCache会向MCentral申请对应的span。申请时需要 加锁 。

内部构造

MCentral针对每个span class 级别有两个 span链表 。

MCentral是一个抽象的概念，实际上每个span class对应的内存数据结构是一个MCentral，即在MCentral这层数据管理中，实际上有span class个MCentral小内存管理单元。

内部字段：

type mcentral struct {
	_         sys.NotInHeap
	spanclass spanClass
    //当前mcantral对应的spanclass等级
    
	partial [2]spanSet // list of spans with a free object
    //表示还有可用空间的集合，集合中的所有span都至少有一个空闲的object空间。 
    //如果MCentral上游的MCache退还span，则会将退还的span加入集合
    
	full    [2]spanSet // list of spans with no free objects
    //表示没有可用空间的span链表，该链表上的span都不确定是否还有空闲的object空间。
    //如果MCentral将一个span提供给上游MCache，则被提供的span就会加入集合

}

partial 和 full 都是一个spanSet数组类型，都各有两个spanSet，这是为了给 GC 使用的，其中一个是已扫描的，另一个是未扫描的。

MHeap

简介

MHeap是内存块的管理对象，通过page对内存单元进行管理。用来详细管理每一系列page的结构称为一个 HeapArena 。一个HeapArena占用内存 64MB ，其中里面的内存是一个个的mspan，最小单元依然是pages。所有的HeapArena组成的集合是一个 Arenas ，即MHeap针对堆内存的管理。MHeap上游是MCentral，当MCentral中的span不够时向MHeap申请。MHeap的下游是操作系统，当MHeap内存不足时会向操作系统的 虚拟内存 空间申请，访问MHeap获取内存时依然需要 加锁。

MHeap中HeapArena占用了绝大部分的空间，其中每个HeapArena包含一个 bitmap ，其作用是标记当前这个HeapArena的内存使用情况。其主要服务于 GC 垃圾回收模块，bitmap共有 两种标记，一种是标记对应地址中 是否存在对象，另一种是标记此对象 是否被GC模块标记过，所以当前HeapArena中的所有page均会被bitmap标记。

内部构造

如图所示：

对象分配流程

go语言内存管理中的对象划分：

对象级别	大小范围
微对象（Tiny对象）	[1，16B）
小对象	[16B，32KB]
大对象	(32KB，无限大）

Tiny对象分配流程

针对Tiny对象，go语言做了特殊处理，MCache中不仅保存着各个span class级别的内存块空间，还有一个比较特殊的 Tiny存储空间。

Tiny空间是从size class=2（对应span class=4\5）中获取的一个16B的object，作为Tiny对象的分配空间。

主要是因为类似bool或者1字节的byte，也都会独享8B的内存空间，进而导致一定的空间浪费。所以将申请的object小于16B的申请同意归为Tiny对象申请。

分配过程：

P 向 MCache 申请微小对象，如一个bool变量。如果申请的object在Tiny对象的大小范围，则进入Tiny对象的申请流程，否则进入小对象或者大对象的申请流程。
判断申请的tiny对象是否包含 指针 ，如果包含指针，则进入 小对象 的申请流程（不会放在tiny缓冲区，因为需要 GC 进入扫描流程）。
如果tiny空间的16B没有多余的存储容量，则从size class=2的span中获取一个16B的object放入tiny缓冲区中。
将1B的bool类型放置在16B的tiny空间中，以 字节对齐 的方式放置。（tiny对象的申请也达不到内存利用率100%）（此处不做详细内存对齐讲解）

小对象

分配小对象的流程是按照span class的规格匹配的。

分配过程：

协程逻辑层 P 向go语言内存管理申请一个对象所需的内存空间。
MCache 收到请求后，根据对象所需的内存空间计算出需要的size。
判断size是否小于16B，小于进入tiny对象的申请流程，否则进入小对象的申请流程。
根据size匹配对应的 size class 内存规格，在根据size class和该对象是否包含 指针，来定位是从noscan span class还是从scan span class获取空间，如果没有指针，则锁定 noscan。
在定位的span class中的span取出一个object返回给协程逻辑层P。流程结束
如果定位的span class中的span所有的内存块object都被占用，则 MCache 会向 MCentral 申请一个span。
MCentral收到内存申请后，优先从对应的span class中的 Partial Set 里取出span，如果Partial Set里没有，则从 Full Set 中取，返给MCache。
MCache得到span后，补充到对应的span class中，之后再次执行第5步。
如果Full Set中没有符合的span，则MCentral会向 MHeap 申请内存。
MHeap收到请求后从其中一个 HeapArena 中取出一部分pages返给MCentral，当MHeap没有足够空间时向 操作系统 申请内存，将申请的内存也保存到HeapArena中的mspan中。MCentral将从MHeap获取的由pages组成的span添加到对应的span class 集合中作为补充 ，之后继续执行第7步。
最后协程业务逻辑层得到对象申请到的内存，流程结束。

大对象

小对象从MCache中分配，而大对象直接从MHeap中分配。对于不满足MCache分配范围的对象均按照大对象处理。

分配过程：

协程逻辑层申请大对象所需的内存空间，如果超过32KB，则直接 绕过MCache 和 MCentral 向 MHeap 申请。
MHeap根据对象所需的空间计算得到需要多少个pages。
MHeap向 Arenas 中的HeapArena申请对应的pages。
如果Arenas中没有HeapArena可提供合适的pages内存，则向操作系统的虚拟内存申请，并且填充到Arenas中。
MHeap返回大对象的内存空间，协程逻辑层得到内存，流程结束

Go语言Channel详解

Thu, 27 Nov 2025 00:00:00 +0000

源码解读版本1.22

简介

go语言提供的并发模型是通信顺序进程（csp）。goroutine和channel分别对应csp中的实体和传递信息的媒介，goroutine之间通过channel传递数据。

目前channel的收发操作都遵循 先进先出 的设计。channel的内部表示的hchan结构体，结构体中包含了用于保护成员变量的 互斥锁。所以说，在某种程度上，channel是一个 有锁队列。

关键源码：

type hchan struct {
    qcount   uint
    dataqsiz uint
    buf      unsafe.Pointer
    elemsize uint16
    closed   uint32
    elemtype *_type
    sendx    uint
    recvx    uint
    recvq    waitq
    sendq    waitq

    lock mutex
}

channel的创建

channel的创建都会使用 make 关键字，他会对缓冲区大小参数进行检查，如果没有，他会默认为0。然后根据传入的缓冲区的大小调用makechan或makechan64函数，64的话是用来处理缓冲区大小大于232的情况，这种情况的话很少见。

在makechan中会分三种情况:

如果channel中不存在缓冲区，那就为hchan分配一块内存空间。
如果channel中存储的不是指针类型，会为当前channel和底层数组分配一块连续的内存空间。
默认情况下会为hchan和缓冲区单独分配空间。

无缓冲的channel

一个基于无缓存Channels的发送操作将导致发送者goroutine阻塞，直到另一个goroutine在相同的Channel上执行接收操作，当发送的值通过Channel成功传输之后，两个goroutine可以继续执行后面的语句。反之，如果接收操作先发生，那么接收者goroutine也将阻塞，直到有另一个goroutine在相同的Channel上执行发送操作。

有缓冲的channel

向缓存Channel的发送操作就是向内部缓存队列的尾部插入元素，接收操作则是从队列的头部删除元素。如果内部缓存队列是满的，那么发送操作将阻塞直到因另一个goroutine执行接收操作而释放了新的队列空间。相反，如果channel是空的，接收操作将阻塞直到有另一个goroutine执行发送操作而向队列插入元素。

关闭的channel

对于已经关闭的channel，如果通道内已经没有数据了，可以不限次数的读取，但是读到的是该数据类型的零值如果通道内还有数据，那么仍然可以读到之前存储的数据，ok会返回true，表示通道内有数据，当通道内的数据读完时，也会返回零值。

但是如果向已经关闭的channel写入数据会panic。

Go三方缓存库对比

Wed, 10 Sep 2025 00:00:00 +0000

前言

原生map设计的缺陷

不支持并发，需要加锁操作，原生库提供的有sync.map，底层存储所使用的容器还是map。
不会自动缩容。内置的map有自动扩容的功能，但是当删除大量数据之后不会自动缩容，删除之后桶本身占用的内存并不会被回收。(可以通过定时新建map拷贝来实现，但是比较麻烦)
如果存放的数据的类型是指针时，GC会扫描map的所有元素，效率不高。

三方库主流解决方案

三方库通过 预分配内存（创建时指定map大小，当插入时如果没有空位就通过淘汰算法清除老数据）+ 分片hash（将一个大map拆分成多个小map，分片减少了key进入同一个hash shard的概率，同时，当一个分片加锁时不会影响别的分片）+ 缓存淘汰算法（lfu、lru、fifo等）通过控制数量来减少map不缩容带来的影响。
也有三方库底层通过map+slice的形式来减少不缩容的影响，其中slice用来真正的存储value，map[key][index]用来查找key在slice中对应的下标。

三方库对比

bigcache

存储结构

分片hash+[]byte ，每一个分片称为一个shard（map[int64]int32，避免了存储指针），在get或者set时会先对key进行hash，根据hash值判断操作哪一个shard，之后的操作都是在shard上进行的。（shard之间互不影响，每个都有读写锁）真正的item（set的value）是存储在[]byte（bytesqueue，gc对于切片当作一个变量扫描，无需遍历整个数组）中的，分片（shard）中的value其实就是该item对应的下标。

添加操作

添加操作分为三种情况：

要添加的key已经存在（也可能是hash碰撞）：由于使用的是FIFO淘汰策略，所以即使有旧值的情况下，新值也不会复用其内存，而是push新的value到队列中。之前的旧值并未从内存中移除，仅将其偏移量从hashmap中移除，使得外部读不到。

旧值何时淘汰：
1. 设置了CleanWindow，且旧值刚好过时，会被清理器自动淘汰。
2. 设置了MaxEntrySize或者HardMaxCacheSize，当内存满时，也会出发旧数据的淘汰。

if previousIndex := s.hashmap[hashedKey]; previousIndex != 0 {
	if previousEntry, err := s.entries.Get(in(previousIndex)); err == nil {
		resetHashFromEntry(previousEntry)
		//remove hashkey
		delete(s.hashmap, hashedKey)
	}
}

bytesqueue已满：

a. 如果bytesqueue未达到设定的HardMaxCacheSize上限，或者HardMaxCacheSize没有设置，则直接扩容直到切片上限。

b. 如果已达上限，则会删除最旧的数据（无论是否过期），知道可以将当前数据添加进去。
正常情况下，加当前shard的写锁，直接添加并更新索引。

获取操作

添加操作的逆过程。需要注意的是，如果获取时数据到达了过期时间，但还没有被清理掉，这时也是可以成功获取到的。是符合大多数需求场景的。

删除操作

和添加时清除旧值类似。

淘汰策略

采用FIFO淘汰策略。新增数据，以及对老数据进行修改，都是直接append到[]byte（bytesqueue）中的。基本不对内存进行修改删除。同时，每个数据项不能单独设置缓存时长，必须全部保持一致。这样对数据淘汰比较友好。

freecache

存储结构

freecache和bigcache类似，也是分片的思想。freecache内部包含256个分段（segment），每个分段都有一把锁。每个分段内部包含两个指针rb（ringbuffer，底层是切片，存储真实数据）和slotsData（也是切片，存储数据在rb中的下标，查找时二分法遍历）。指针固定512（rb和slotData）个，所以号称0GC。但是freecache的key和value都是[]byte类型的。需要进行序列化操作。

添加操作

先对key进行hash，低8位对应segment数组，低8-15位选取slot下标，同时取高 16 位做 hash16 用于 slot 内快速比较。然后通过二分法寻找小于等于当前hash16，如果找到等于的还要继续对比key的信息。如果找到相同的key，则是更新操作，没找到就是插入。更新时会比较新value和老value的大小，如果比老的小就可以直接覆盖写入，否则就在rb的末尾寻找空间写入。插入时如果rb空间不足就会触发淘汰机制。

查找操作

与添加操作的查找类似，先通过key定位segment，然后继续定位slot，然后根据hash16进行二分查找。如果找到了继续对存储的key进行对比。完全命中才算。命中时读取其设置的过期时间，如果已经到了，返回未命中，并将此项标记为删除。没过期就更新相关的命中统计。

删除操作

value的定位和上面的一样，找到之后会将索引从slot中移除，并把该 entry 的 header 标记 deleted = true（逻辑删除标识，写在 header 里）。这意味着索引已经不再指向该条目，外部 Get/Set 不会再找到它。

淘汰机制

当 RingBuf 空间不足时，FreeCache 会从缓冲区的头部开始主动淘汰数据以释放空间。其淘汰策略是一个精巧的、近似 LRU 的策略，综合考虑了访问时间和过期时间。 freecache 不是精确维护一个 LRU 链表，而是用分段 + 环形缓冲 + “平均访问时间”比较的方法：当某个段要腾空间时，优先删除过期或“比段平均访问时间更旧（更冷）”的条目；如果条目相对较新（热），则把它搬到环形缓冲的尾部以保留。这个策略因此被称为 Nearly LRU（近似 LRU）。

ristretto

存储结构

与前面的框架类似，也是分片hash的设计思想（256个分片+读写锁）（最底层使用的map存储的value），但是最底层存储的key是经过计算后的hash值（该框架对key计算了两个hash值<两个uint64>，keyhash和 conflict ，后者用于判断冲突，使用的是xxhash算法）。该框架在初始化实例时会自动启动一个协程processItems来进行增删改的操作，并周期性的进行GC回收。

添加操作

首先会检查设置的过期时间，如果小于0直接返回false代表失败，为0表示永不过期。然后根据key计算出两个hash值。然后会先尝试更新操作，如果返回更新成功，会直接修改存储的value，并将当前item的flag修改为更新操作。然后尝试将这个item放入到setbuff的缓冲队列中（channel），如果队列未满或者满了但是当前操作是更新会返回true，视为写入成功，否则返回false并记录指标。然后processItems协程会从setbuff中获取数据（select）。
获取到数据之后，首先会判断当前item是否是特殊item（内置一个空结构体类型的channel字段wait），由于是协程监听进行的增删改操作，不保证强一致性，Ristretto提供了一个Wait函数来等待之前设置的item全部设置成功，该函数会进行阻塞（读取wait），直到setbuff执行到这个特殊的item，然后关闭这个特殊item的wait，结束Wait函数，表示数据已经完全录入完毕。
如果是普通的item，会先计算这个item的消耗cost，如果初始化时提供了Coster函数，并且当前flag不是删除，且item的cost为0，就会调用提供的函数进行计算真实的cost，然后还会加上内部存储占用 itemSize，除非在 Config 中设置 IgnoreInternalCost = true。
然后判断当前item的flag是否是添加操作（这里默认是），然后调用函数进行决策，通过TinyLFU算法来判断当前item是否值得被接受，以及如果接受之后超出内存上限需要通过 Sampled LFU 算法决定要淘汰哪些数据。如果值得添加，就调用函数将item添加到底层map中并记录指标，然后记录当前key的时间戳，方便后续计算寿命。如果不值得添加，就调用 onReject 回调函数，直接丢弃。然后对需要淘汰的数据进行删除。

更新操作

同理从setbuff中获取，未进入setbuff的添加的item参考添加操作。外部暴露的函数与添加操作一致，都是Set。进入setbuff的flag为更新操作的item仅更新相关指标即可。

删除操作

同理从setbuff中获取（有序队列，避免了先执行删除后又被恢复的场景），执行相关的指标更新，然后从底层删除，并调用相关的回调函数。

获取操作

先获取key的两个hash值，在从map寻找数据之前，会先执行一个Push操作，将访问计数的采集推入缓冲再进行读取，缓冲是自定义的一个ring-buffer，内部有sync.pool字段存储获取的key的切片，目的是合成批量操作降低开销。然后才会在真正的分片hash中查找对应的数据，如果传入了 conflictHash 且不匹配就认为不存在，检查 item 是否过期（TTL），如果过期也当作不存在。

淘汰策略

采用的是 Sampled LFU（随机采样找出最不常用的候选）淘汰算法，当添加时发现空间不足时会先用 TinyLFU 估算新key的频率，然后从已有的item中随机抽取5个（源码写死，研究表明，5 个样本的概率足以近似全局最低频项）估算key的频率，如果新key最低，就不值得进入缓存，不是最低就将要淘汰的key添加到相关队列中，重复上述步骤，直到能把新key放进去。

总结

对比	数据类型限制	淘汰策略	一致性	过期设置	GC	内存利用率	适用场景
bigcache	value 必须是 `[]byte`	FIFO	强一致性	仅支持全局过期时间，不支持单个 key 设置过期；获取时若过期按成功处理	0 GC	支持动态扩展，利用率较高，但没有淘汰策略，过期数据可能占用内存较久	数据生命周期短，不太在意命中率；适合短时缓存、临时存储
freecache	key 和 value 都必须是 `[]byte`	Nearly LRU（近似 LRU）	强一致性	支持单个 key 设置过期时间；获取时若过期按失败处理	0 GC	内存固定分配，利用率高；但 key 小 value 大时可能产生空间碎片	命中率要求不高；适合日志、监控指标等大量 KV 缓存
ristretto	无限制	Sampled LFU（随机采样选出最不常用候选）	最终一致性	支持单个 key 设置过期时间；获取时若过期按失败处理	Go GC	有容量上限且控制精细，结合淘汰策略，整体内存利用率最高	需要高命中率；适合业务缓存（用户会话、推荐系统、热点数据）

Go语言 on 你怂你mua

Go Map 1.24新实现

底层结构

特性

初始化流程

添加流程

小map写入细节

大map写入细节

搜索流程

关键点

删除过程

扩容过程：

小map扩容

大map扩容

扩容流程详解（grow）

分裂流程详解（split）（ Extendible Hashing ）

分裂过程中第8步详解

Go内部锁

Mutex

Mutex的状态

加锁和解锁

RWMutex

写锁

读锁

Go语言GMP模型

简介

g的状态

g0

四种调度类型

findRunnable函数（寻找可执行的g）

Go语言sync.Map

数据结构

读流程

覆盖流程

写流程（插入或更新）

dirtyLocked流程

删除流程

遍历流程

Go语言内存分配模型

相关概念

page

mspan

size class相关

Demo

MCache

简介

内部构造

特殊size class

MCentral

简介

内部构造

MHeap

简介

内部构造

对象分配流程

go语言内存管理中的对象划分：

Tiny对象分配流程

小对象

大对象

Go语言Channel详解

简介

channel的创建

无缓冲的channel

有缓冲的channel

关闭的channel

Go三方缓存库对比

前言

原生map设计的缺陷

三方库主流解决方案

三方库对比

bigcache

存储结构

添加操作

获取操作

删除操作

淘汰策略

freecache

存储结构

添加操作

查找操作