源码 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。

Redis数据结构之Sorted Sets

Sat, 11 Oct 2025 00:00:00 +0000

redis 版本7.x

有序性与唯一性

Sorted sets与Sets类似，是一种集合类型，这种集合中不会出现重复的member(数据)。Sorted seats中的元素由两部分组成，分别是member和score(分数)。

member会关联一个double类型的score，Sorted sets默认会根据这个score对member从小到大排序。如果member关联的score相同，则按照字符串的字典顺序排列。

常见使用场景：

排行榜：游戏中根据分数排名top10。
速率限流器：滑动窗口速率限制器。
延迟队列：使用score存储过期时间，从小到大排序，最靠前的就是最先到期的数据。

skiplist + dict 和 listpack

Sorted sets底层通过两种方式存储数据：

listpack（7.0版本之前是ziplist）：使用条件是集合元素小于或等于128，且member占用字节数小于64。将member和score紧凑排列作为listpack的一个元素存储。
skiplist + dict：当不满足上述条件时，将数据分别存储在skiplist（跳表）和dict中，是一种空间换时间的思想。散列表key存储的是member，value存储的是关联的score。

listpack适用于元素个数不多且占用空间不大的场景，使用listpack就是为了节省内存。Sorted Sets能支持高效的范围查询，正是因为采用了skiplist。

而使用dict的目的是以O(1)的时间复杂度查询单个元素。总之，Sorted Sets在插入或者更新时，会同时向skiplist和dict中插入或更新对应的数据，以保证两者数据的一致性。

skiplist + dict

skiplist本质是一种可以进行二分查找的有序链表。skiplist在原有的基础上增加了多级索引来实现快速查找。

skiplist节点查找

通常数据查找是从顶层开始，如果节点保存的值比待查数据的值小，skipllist就继续访问该层的下一个节点。

如果比待查数据的值大，就跳到当前节点的下一层的链表继续查找。如下图所示查找节点17：

从level1开始，17大于6，继续与下一个节点比较
17<26，回到原节点，跳到当前节点的level0层链表，与下一个节点比较，找到目标17

skiplist也是受到这种多层链表的启发设计出来的。根据上面的生成链表，上层节点个数是下层节点个数的一半，查找过程类似二分查找，时间复杂度是O(n)。

但是，这种设计方式有个问题，就是每次新增一个节点，就会打乱相邻的两层链表节点个数2：1的关系，就需要调整链表结构。

为了避免这个问题，skiplist不要求上下相邻两层链表之间节点个数有严格的比例关系，而是为每个节点随机出一个层数，这样插入节点时只需要修改前后指针。

Sorted Sets相关数据结构源码如下：

typedef struct zskiplist {

    // 头尾指针便于双向遍历
    struct zskiplistNode *header, *tail;
    // 当前skiplist包含的元素个数
    unsigned long length;
    // 表内节点的最大层级
    int level;
    size_t alloc_size;
} zskiplist;

typedef struct zset {
    dict *dict;
    zskiplist *zsl;
} zset;

skiplist中的每个节点，由zskiplistNode结构体表示：

typedef struct zskiplistNode {
    sds ele;
    double score;
    struct zskiplistNode *backward;
    struct zskiplistLevel {
        struct zskiplistNode *forward;
        unsigned long span;
    } level[];
} zskiplistNode;

ele和score属性：使用sds类型的ele存储实际数据，score存储分数。
*backward：后退指针，指向该节点的上一个节点，便于倒序查找。每个节点只有一个后退指针，只有level0层的节点是双向链表。
level[]：
- *forward：前进指针。
- span：跨度，记录该层的forward指针指向的下一个节点之间的跨越了level0层的节点数

listpack

listpack的优势的节省内存，但只能按顺序查找元素，时间复杂度是O(n)。正因如此，才能在少量数据的情况下，节省内存同时又不影响性能。

Redis数据结构之Lists

Thu, 11 Sep 2025 00:00:00 +0000

redis中的list和java中的linkedlist类似，是一种线性有序结构，按照元素被推入列表中的顺序存储元素，满足先进先出的需求。可以把它当作队列、栈来使用。

内部结构演进

linkedlist

在redis3.2之前List底层数据结构由linkedlist或者ziplist实现，优先使用ziplist存储。当List对象满足以下两个条件时，将使用ziplist存储，否则使用linkedlist。

链表中的每个元素占用的字节数小于64
链表中的元素数量小于512个

关键源码：

/* 链表节点 */
typedef struct listNode {
    // prev与next字段形成双端链表
    struct listNode *prev;
    struct listNode *next;
    void *value;
} listNode;

/* 链表结构体 */
typedef struct list {
    listNode *head;
    listNode *tail;

    void *(*dup)(void *ptr);
    void (*free)(void *ptr);
    int (*match)(void *ptr, void *key);

    unsigned long len;
} list;

redis链表的特性

双端：链表节点带有prev和next指针，获取某个节点的前置和后置节点的时间复杂度都是O(1)
无环：链表头节点的prev和尾节点的next指针指向的都是null。对链表的访问以null结尾。
带表头指针和表尾指针：list结构体有head和tail指针，获取链表头尾节点的时间复杂度为O(1)
len属性：list结构体有len属性，获取节点数量的时间复杂度为O(1)

ziplist

linkedlist中存在prev、next两个指针，在数据很小的情况下，指针占用的空间会超过数据占用的空间。

linkedlist是链表结构，在内存中不是连续的，遍历效率低下。

为了解决上述的两个问题，创建了ziplist，ziplist是一种内存紧凑的数据结构，占用一块连续的内存空间，能够提高内存利用率。

当一个Lists只有少量数据，并且每个列表项要么是小整数型，要么是比较短的字符串时，就会使用ziplist来作为List的底层数据结构存储数据。

ziplist是一块连续的内存，结构如下：

zlbytes：占用4字节，记录整个ziplist占用的总字节数
zltail：占用4字节，只想最后一个entry偏移量，用于快速定位最后一个entry
zllen：占用2字节，记录entry总数
entry：Lists的元素
zlend：ziplist结束的标志，占用1字节，值等于255

因为ziplist头尾元数据大小是固定的，并且zllen记录了ziplist头部最后一个元素的位置，所以可以用O(1)的时间复杂度找到ziplist中第一个或最后一个元素。而在查找中间元素时，只能从Lists头部或尾部开始遍历，时间复杂度O(n)。

存储数据的entry结构如图所示：

prevlen：记录前一个entry占用的字节数，逆序遍历就是通过这个字段确定的向前移动多少字节拿到上一个entry的 首地址 的。这部分会根据上一个entry的长度进行变长编码。变长方式如下：
- 前一个entry的字节数小于254（255用于zlend），prevlen的长度为1字节，值等于上一个entry的长度。
- 前一个entry的字节数大于等于254，prevlen占用5字节，第一字节配置为254作为一个标识，后面4字节组成一个32位int值，用于存放上一个entry的字节长度。
encoding：表示当前entry的类型和长度，前两位用于表示类型，前两位为11时表示存储的是int类型，其他情况表示存储的字符串。
entry-data：实际存放数据的地方，但是当entry存储的是int类型时，encoding和entry-data会合并到encoding中，并没有entry-data字段。

linkedlist与ziplist对比

为什么说ziplist节省内存？

与linkedlist相比，少了prev和next指针。
通过encoding字段针对编码进行细化存储，尽可能做到按需分配。

ziplist的不足:

不能保存过多的元素，否则查询性能下降，导致O(n)时间复杂度。
ziplist存储空间是连续的，当插入新的entry时，内存空间不足就需要重新分配一块连续的内存空间，引发连锁更新。

连锁更新问题:

每个entry都用prevlen记录上一个entry的长度，在当前entry B 前面插入一个新的entry A 时，会导致 B 的prevlen发生变化，也会导致 B 的大小发生改变。同理后面的entry C 也会发生改变。以此类推，就可能导致连锁更新问题。

连锁更新会导致多次重新分配ziplist的存储空间，直接影响ziplist的查询性能。所以在redis3.2引入了quicklist。

quicklist

quicklist结合了linkedlist与ziplist的优势，本质还是一个双向链表，只不过链表的每一个节点都是一个ziplist。

结构体源码如下：

typedef struct quicklistNode {
    struct quicklistNode *prev;
    struct quicklistNode *next;

    unsigned char *zl;
    unsigned int sz;

    unsigned int count : 16;
    unsigned int encoding : 2;
    unsigned int container : 2;
    unsigned int recompress : 1;
    unsigned int attempted_compress : 1;
    unsigned int extra : 10;
} quicklistNode;

typedef struct quicklist {
    quicklistNode *head;
    quicklistNode *tail;
    unsigned long count;        /* total entries */
    unsigned long len;          /* number of nodes */

    int fill : 16;              /* ziplist size limit */
    unsigned int compress : 16; /* compression depth */
} quicklist;

quicklist是ziplist的升级版，优化的关键点在于控制好每个ziplist的大小或者元素个数。

但是存在两个极端情况：

quicklist node的ziplist越小，可能造成越多的内存碎片。极端情况是每个ziplist只有一个entry，退化成了linkedlist。
quicklist node的ziplist过大，极端情况下会造成一个quicklist只有一个ziplist, 退化成了ziplist, 连锁更新的问题就会暴露出来。

所以在5.0版本的时候设计了另一个数据结构listpack, 并在7.0版本中替换掉了ziplist。

listpack

listpack的结构如图所示：

tot-bytes：即total bytes，占用4字节，记录listpack占用的总字节数
num-elements：占用2字节，记录listpack elements的个数
elements：listpack元素，保存数据的部分
listpack-end-byte：结束标志，占用1字节，固定值为255

element结构如图所示：

encoding-type：存储实际数据的编码类型和长度，是一个变长字段。
element-data：存放实际数据。
element-tot-len：前两个字段的总长度，不包括自身长度。

每个element只记录自身长度，修改或新增元素时，不会影响后续element的长度，解决了连锁更新的问题。

消息队列实战

消息队列介绍

消息队列是一种异步的服务间通信方式，适合用于分布式和微服务架构。消息在未被处理和删除之前一直在队列上。

消息队列基于先进先出(FIFO)的设计原则，允许发送者(生产者)向队列中发送消息，而接收者(消费者)则可以从队列中获取消息进行处理。通常消息队列被用于解耦应用程序的各个组件，实现异步通信、削峰填谷、解耦合、流量控制等。

消息队列特性：

消息有序性：消息是异步处理的，但消费者需要按生产者发送消息的顺序来消费，避免出现后发送的消息被先处理的情况。
重复消息处理：当网络问题出现消息重传时，消费者可能收到多条重复消息，可能造成同一业务逻辑被多次执行。在这种情况下，应用系统需要确保幂等性。
可靠性：保证一次性传递消息。如果发送消息时接收者不可用，消息队列会保留消息，直到成功传递它，消费者重启后可以继续读取消息进行处理，防止消息遗漏。

redis实现

实时消费问题

生产者可以使用LPUSH key element[element…] 的形式将消息插入队列头部，如果key不存在则会创建一个空的队列再插入消息。

消费者可以通过RPOP key 的形式依次读取队列的消息，以此实现先进先出的消息队列。

但是LPUSH、RPOP存在性能风险，生产者向队列插入消息时，Lists并不会主动通知消费者及时消费。程序需要不断轮询并判断是否为空再执行消费逻辑，这就会导致即使没有新的信息写入，消费者也在不停的调用RPOP命令占用CPU资源。

redis提供了BLPOP、BRPOP的阻塞读取的命令，消费者在读取队列没有数据时会自动阻塞，直到有新的消息写入队列，才继续读取新消息执行业务逻辑。

重复消费解决方案

消息队列自动为每一条消息生成一个全局ID
生产者为每条消息创建一个全局ID，消费者把处理过的消息ID记录下来，判断是否重复

其实这就是密等，对于同一条消息，消费者收到后处理一次的结果和处理多次的结果是一样的。

消息可靠性解决方案

场景：消费者读取消息处理过程中宕机了，就会导致消息没有处理完成，可是数据已经不在队列中了。

这种现象的本质是消费者处理消息时崩溃了，无法再读取消息，缺乏一个消息确认的可靠机制。

redis提供了BRPOPLPUSH source destination timeout 命令，含义是以阻塞的方式从source队列读取消息，同时把这个消息复制到另一个destination队列中(备份)，并且是原子操作。

不过这个命令在redis6.2版本被BLMOVE取代。

BLMOVE op1 op2 RIGHT LEFT 0

消费者在消费时在while循环中使用BLMOVE，以阻塞的方式从队列 op1 队尾消费消息，同时把消息复制到队列 op2 队头(备份队列)，该操作是原子性的，最后一个参数 timeout=0 表示持续等待。

如果上述命令消费成功，就使用 LREM 命令把队列 op2 中的对应消息删除，从而实现 ACK 确认机制。如果消费异常，使用 BRPOP op2 从备份队列中再次读取消息即可。

Redis数据结构之Set

Thu, 11 Sep 2025 00:00:00 +0000

无序和唯一

Sets是字符串类型的无序集合，集合中的元素是唯一的，不会出现重复的数据。Sets底层是用散列表实现的，散列表的key存储的是Sets元素中的value，散列表的value指向null。

使用场景

当你需要存储多个元素，且不允许出现重复数据，无需考虑元素有序性时，可以使用Sets。Sets还支持在集合之间做交集、并集、差集操作

共同关注：通过交集实现
每日新增关注数：对近两天的总注册用户量集合取差集
打标签：为自己收藏的文章打标签，例如微信收藏功能，这样可以快速找到被添加了某个标签的所有文章。

intset

当元素内容是64位以内的10进制整数，且元素个数不超过512时，Sets会使用更加省内存的intset来存储。相关结构源码如下：

typedef struct intset {
    uint32_t encoding;
    uint32_t length;
    int8_t contents[];
} intset;

length：记录整数集合存储的元素个数，其实就是contents数组的长度
contents：真正存储整数集合的数组，是一块连续的内存区域。数组中的元素会按照值的大小从小到大存储，并且不会有重复元素
encoding：编码格式，决定数组类型，一共有三种不同的值。
- INTSET_ENC_INT16：表示contents数组的存储元素是int16_t类型的，每2字节表示一个整数元素
- INTSET_ENC_INT32：表示contents数组的存储元素是int32_t类型的，每4字节表示一个整数元素
- INTSET_ENC_INT64：表示contents数组的存储元素是int64_t类型的，每8字节表示一个整数元素

intset升级

当往一个int16_t类型的intset中插入一个int64_t类型的值时会触发升级。也就是Sets的所有数据类型会转换成int64_t类型。步骤如下：

根据新元素的类型和Sets元素数量，计算包括新添加的元素在内的新空间大小，对底层数组空间扩容，重新分配空间。
将intset中原有的元素转换成新元素类型，按从大到小的顺序放到正确位置，需要保障intset元素的有序性。
将encoding的值修改为length+1

因此，每次向intset添加新元素可能引起升级，升级又会对原始数据进行类型转换，时间复杂度是O(n)。

intset不支持降级操作

散列表原理

Redis的散列表的底层数据结构通常是dict，由数组和链表构成，数组元素占用的槽位叫做哈希桶。当出现散列冲突时，会在桶下挂一个链表，用 拉链法 解决散列冲突的问题。

存储结构

散列表的底层存储数据结构实际上有两种:

dict数据结构
listpack(7.0之前使用ziplist)数据结构

通常使用dict数据结构存储数据，每个field-value pairs构成一个dictEntry节点。只有 同时满足 以下两个条件，才会使用listpack数据结构替代dict。按照field在前，value在后紧密相连的方式，依次把每个field-value pairs放到列表的表尾。

每个field-value pairs中的field和value的字符串的字节数都小于64
field-value pairs数量小于512

每次向散列表写数据时，都会调用相关函数来判断是否需要转换底层数据结构。

当插入和修改的数据不满足以上两个条件时，就把散列表底层存储的数据结构转换为dict。虽然使用了listpack无法实现O(1)时间复杂度操作数据，但能大大减少内存占用，由于数据量比较小，性能不会有太大差异。

需要注意的是，不能由dict退化成listpack。

dict结构体主要源码如下：

struct dict {
    dictType *type;
    dictEntry **ht_table[2];
    unsigned long ht_used[2];
    long rehashidx; 
    unsigned pauserehash; 
    signed char ht_size_exp[2]; 
};

dictType *type：存放函数的结构体，定义了一些函数指针。可以通过配置自定义函数，实现在dict的key和value中存放任何类型的数据。
dictEntry **ht_table[2]：存放大小为2的散列表指针数组，每个指针指向一个dictEntry类型的散列表。
ht_used[2]：记录每个散列表使用了多少槽位。
rehashidx：标记是否正在执行rehash操作，-1表示没有，如果正在执行rehash操作，那么其实表示当前执行rehash操作的ht_table[0]的dictEntry数组的索引。
pauserehash：表示rehash的状态，大于0表示rehash暂停，等于0时表示继续执行，小于0时表示出错。

数组中每个元素都是dictEntry类型的，就是它存放了field-value pairs。其结构如下：

struct dictEntry {
    struct dictEntry *next;  /* Must be first */
    void *key;               /* Must be second */
    union {
        void *val;
        uint64_t u64;
        int64_t s64;
        double d;
    } v;
};

*key指针指向field-value pairs中的field，实际上指向一个SDS实例
v 是一个union联合体，表示field-value pairs中的value，同一时刻只有一个字段有value，用联合体的目的是节省内存。
- *val：value是非数字类型时使用该指针存储
- uint64_t u64：value是无符号整数时使用该字段
- int64_t s64：value是有符号整数时使用该字段
- double d：value是浮点数时使用该字段
*next指针指向下一个节点。当发生哈希冲突时，使用此链表（链表法）。

扩容和缩容

扩容和缩容的步骤如下：

为了提高性能，减少哈希冲突，会创建一个大小等于ht_used[0] * 2的散列表ht_used[1]，也就是每次扩容时根据散列表ht_table [0]已使用空间扩大一倍创建一个新散列表ht_table [1]。反之，如果是缩容操作，就根据ht_table [0]已使用空间缩小一半创建一个新的散列表。
重新计算field-value pairs的哈希值，得到这个field-value pairs在新散列表ht_table [1]中的桶位置，将field-value pairs迁移到新的散列表上。
所有field-value pairs迁移完成后，修改指针，释放空间。把ht_table [0]指针指向扩容后的散列表，回收原来的小的散列表空间，把ht_table [1]指针指向null，为下次扩容\缩容准备。

扩容\缩容时机

当前没有执行bgsave或者BGREWRITEAOF命令，同时负载因子大于等于1。也就是当前没有RDB子进程和AOF重写子进程在工作，这两个操作容易对性能造成影响。
正在执行bgsave或者BGREWRITEAOF命令，负载因子大于或等于5。这时哈希冲突比较严重，再不扩容，查询效率就太低了。

负载因子 = 散列表存储的dictEntry节点数量 / 哈希桶个数。理想情况下每个哈希桶存储一个dictEntry节点，这时负载因子 = 1。

扩容过程

为了防止阻塞主线程造成性能问题，不是一次性把全部key迁移，而是分多次将迁移操作分散到每次请求中，避免集中式rehash造成长时间阻塞。

在渐进式rehash期间，dict会同时使用ht_table[0]和ht_table[1]两个散列表，具体步骤如下：

将rehashidx配置为0，表示rehash开始执行。
在rehash期间，服务端每次处理客户端对dict散列表的增删改查操作时，除了执行指定操作外，还会检查当前dict是否处于rehash状态，如果是，就把散列表ht_table[0]上索引位置为rehashidx的哈希桶的链表的所有field-value pairs rehash到散列表ht_table[1]上，并将rehashidx加1。
当所有field-value pairs迁移完成后将rehashidx配置为-1，表示操作已完成。

删除、修改和查找可能会在两个散列表上进行，第一个没找到就去第二个，但是增加操作只会在新的散列表上进行。

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	有容量上限且控制精细，结合淘汰策略，整体内存利用率最高	需要高命中率；适合业务缓存（用户会话、推荐系统、热点数据）

Redis数据结构之String(SDS)

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

redis版本7.x

原生C语言字符串的问题

C语言使用char * 字符数组来实现字符串，在创建时就需要手动检查和分配空间。由于没有 length属性 记录长度，想要获取字符串的长度就需要从头遍历，直到遇到\0。
无法做到“安全的二进制格式数据存储”，图片等二进制格式数据无法保存。无法存储\0这种特殊字符，\0在C语言中代表字符串结尾。
字符串的扩容和缩容。char数组的长度在创建字符串的时候就确定下来，如果要追加数据，则要重新申请一块空间，把追加后的字符串内容拷贝进去，再释放旧的空间，十分消耗资源。

Redis中SDS设计

SDS也遵循C语言的以空字符串 \0 结尾的惯例，但是空字符串不计入SDS内部的len字段中。

SDS主要字段如下：

len：数组已使用长度
alloc：数组总长度
flags：SDS类型
char buf[]：存储的实际内容

O(1)时间复杂度获取字符串长度

SDS中的len字段保存了字符串的长度，实现了O(1)时间复杂度获取字符串长度。

SDS结构有一个flags字段，表示的是SDS类型。实际上SDS一共设计了5种类型，分别是sdshdr5、sdshdr8、sdshdr16、sdshdr32、sdshdr64，区别在于数组的len长度和分配空间长度alloc不同。

节省内存

之所以这么设计，是因为SDS使用不同的类型保存不同大小的字符串可以节省内存。

redis内部限制最大的字符串长度为512MB

编码格式

SDS内部采用了三种编码格式来存储，分别是int、embstr和raw。

int编码：8字节的长整型，值是数字类型且数字的长度小于20。
embstr编码：长度小于或等于44字节的字符串。
raw编码：长度大于44字节的字符串。

作用：代替字节对齐的方式来节省内存。

二进制格式的数据安全

因为SDS并不是通过 \0 来判断字符串结束的，而是采用len标志结束，所以可以直接存储二进制格式数据。

空间预分配

在需要对SDS的空间进行扩容时，不仅仅分配所需的空间，还会分配额外的未使用空间，通过预分配策略，减少了执行字符串增长所需的内存重新分配次数。

惰性空间释放

当对SDS进行缩短操作时，程序并不会回收多余的内存空间，如果后面需要append追加操作，则直接使用buf数组alloc-len中未使用的空间。通过惰性空间释放策略，避免了减小字符串所需的内存重新分配操作。

源码 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

Redis数据结构之Sorted Sets

有序性与唯一性

skiplist + dict 和 listpack

skiplist + dict

skiplist节点查找

listpack

Redis数据结构之Lists

内部结构演进

linkedlist

redis链表的特性

ziplist

linkedlist与ziplist对比

quicklist

listpack

消息队列实战