Golang源码探究 —— sync.Map
Golang内置的map是不支持并发读写的，它在内部有检测机制，一旦发现并发读写，就会panic。如果需要并发读写map，有三种方案。1、使用map + Mutex 2、使用 map + RWMutex 3、使用sync.Map。前两者的效率在大部分情况下都不如官方提供的sync.Map。接下来来分析一下sync.Map是如何实现并发读写的。
1、sync.Map的结构
sync.Map的源码在sync/map.go中, skd版本：1.18
sync.Map的结构用图表示如下：
源码如下：
type Map struct {
// 互斥锁
mu Mutex
/*
read中包含了一个可以并发访问的map，无需对mu加锁就可以访问，读写数据都会经过read map
它最终会包含这样一个结构：
type readOnly struct {
m map[interface{}]*entry
amended bool
}
*/
read atomic.Value // readOnly
// dirty map 新增数据，走dirty map
dirty map[interface{}]*entry
// 未命中次数
misses int
}
// readOnly is an immutable struct stored atomically in the Map.read field.
type readOnly struct {
m map[any]*entry
amended bool // 如果dirty中存在没有在m中的key时为true
}
type entry struct {
p unsafe.Pointer // *interface{}
}
sync.Map结构体中包含了四个字段，其中包含了两个map[interface{}]*entry ，entry中包含了一个unsafe的Pointer，这个指针指向了真正的value值。
2、sync.Map读写
2.1 正常读写
Map的正常读写是走的read这个map，从read map中查找k-v。
2.2 追加问题
假设我们要追加一个键值对"d":“go”，首先，因为不知道map中有没有这个key，因此需要先在read map中寻找，没有找到就会先对mu加锁，然后在下面的dirty map中追加。
追加的时候，要创建一个entry，指针指向真正的值。然后要将amended置为true，表示read中的map已经不完整了，dirty map中有新追加的键值对。但是为什么要这样做？正常已存在的键值的读和修改走的都是上面的read map，而追加则是走的dirty map。因为上面的read map的读和写都不会涉及到map扩容的问题，而追加可能会导致map扩容。
2.3 追加后读写
在追加后，我们要读出"d"的值，首先还是要走read这条线，read中找不到，但是amended为true，表示read中的map和dirty map不一致。因此要从dirty map中查找。读完后要把misses加1，表示一次要读的键在上面的map中未命中。随着多次的未命中，msses逐渐增加，当增加到misses == len(dirty)时，就会进行dirty提升。
2.4 dirty提升
当misses与dirty map的长度相等时，就无法忍受了。因为多次在read中读取却未命中，还需要再走dirty map，这时候就会进行dirty map的提升。将上面的map干掉，将dirty提升上去，dirty变成新的read map，此时下面的dirty map为nil。后面如果追加的话，会重建dirty map。然后就会进入了初始的循环。
3 sync.Map删除
- sync.Map的删除相比于查询、修改、新增更麻烦。
- 删除可以分为正常删除和追加后删除。
- 提升后，被删的key还需要特殊处理。
3.1 正常删除
在read map中根据key找到对应的entry，但是不是删除在map中对应的entry，而是将entry中的指针置为nil，这样就没有任何指针指向真正的值了，垃圾回收器就可以进行回收。
3.2 追加后删除
假设"d"是我们刚追加上去的，read map和dirty map中的数据是不一致的。如果要删除"d"，首先从read map中查找，没有找到，而且amended为true。对mu进行上锁，然后取dirty map中查找，找到后将entry中的指针置为nil。但是追加后删除涉及一个提升的问题，假设删除后，后面要将dirty map提升上来，那么四个键中的其中一个是指向nil的，如果要重建下面的dirty map，是否要重建这个nil的key呢？这个时候就不重建它，而是将指针指向expunged（删除了的意思）。将指针指向expunged就是为了提醒来访问的协程，这个键值对已经被删除了，如果要删除这个键值对的话，之间删除就行了，因为在下面已经没有了。
// expunged is an arbitrary pointer that marks entries which have been deleted
// from the dirty map.
var expunged = unsafe.Pointer(new(any))
4、源码分析
源码如下：
读取数据的逻辑：
/*
从Map中读取数据
*/
func (m *Map) Load(key any) (value any, ok bool) {
// 从atomic.Value中加载数据并断言为readOnly类型
read, _ := m.read.Load().(readOnly)
// 直接从read的map中读取
e, ok := read.m[key]
// 如果没有找到，并且read.amended为true，说明read map和dirty map中的数据不一致，因此需要再从dirty map中读取
if !ok && read.amended {
// 对mu上锁
m.mu.Lock()
// 防止当阻塞在lock上的时候，dirty map被提升了，因此需要重新获取一次read map
read, _ = m.read.Load().(readOnly)
e, ok = read.m[key]
if !ok && read.amended {
// 访问dirty map
e, ok = m.dirty[key]
// 无论是否找到了需要的键值，都记录一个miss
m.missLocked()
}
m.mu.Unlock()
}
if !ok {
return nil, false
}
// 从entry中获取数据
return e.load()
}
// 从获取到的entry中的指针读取数据，如果指针为nil或者expunged说明要查找的key-val不存在
func (e *entry) load() (value any, ok bool) {
p := atomic.LoadPointer(&e.p)
// 如果p == expunged，说明已经被删除
if p == nil || p == expunged {
return nil, false
}
return *(*any)(p), true
}
// 记录未命中的次数，如果次数达到dirty map的长度时，提升dirty map
func (m *Map) missLocked() {
m.misses++
if m.misses < len(m.dirty) {
return
}
// 如果mmisses == len(m.dirty) 就要提升dirty
m.read.Store(readOnly{m: m.dirty})
m.dirty = nil
m.misses = 0
}
修改或新增数据逻辑：
/*
修改或新增键值对
*/
func (m *Map) Store(key, value any) {
// 获取read
read, _ := m.read.Load().(readOnly)
// 先从read map中查询是否存在，如果存在，就是修改操作，调用tryStore修改read map中的数据
if e, ok := read.m[key]; ok && e.tryStore(&value) {
return
}
// 要修改的数据可能在dirty map中，属于2.3的情况 或者是不在dirty map中，那么就是新增k-v操作
// 先上锁
m.mu.Lock()
// 再次查询read map防止阻塞在lock期间，dirty map被提升
read, _ = m.read.Load().(readOnly)
// ok == true说明dirty map已经被提升，而且要修改的数据在原来的dirty map中
if e, ok := read.m[key]; ok {
if e.unexpungeLocked() {
// entry被删除了
m.dirty[key] = e
}
e.storeLocked(&value)
// 查找dirty map，如果找到，就修改dirty map中的数据
} else if e, ok := m.dirty[key]; ok {
e.storeLocked(&value)
// 追加数据
} else {
//
if !read.amended {
// 第一次新增，此时amended为false，可能是dirty提升后第一次新增，此时需要重建dirty map
m.dirtyLocked()
// 修改amended为true
m.read.Store(readOnly{m: read.m, amended: true})
}
// 新增数据
m.dirty[key] = newEntry(value)
}
m.mu.Unlock()
}
/*
修改read map中的值
*/
func (e *entry) tryStore(i *any) bool {
for {
p := atomic.LoadPointer(&e.p)
// 说明已经被删除
if p == expunged {
return false
}
// 原子操作，修改值
if atomic.CompareAndSwapPointer(&e.p, p, unsafe.Pointer(i)) {
return true
}
}
}
/*
第一次新增，dirty map可能被提升了，如果被提升，那么dirty map为nil，需要重建
*/
func (m *Map) dirtyLocked() {
if m.dirty != nil {
return
}
// 重建dirty map
read, _ := m.read.Load().(readOnly)
m.dirty = make(map[any]*entry, len(read.m))
for k, e := range read.m {
// 不会添加expunged的k
if !e.tryExpungeLocked() {
m.dirty[k] = e
}
}
}
删除逻辑：
/*
删除键对应的值
*/
func (m *Map) Delete(key any) {
m.LoadAndDelete(key)
}
/*
删除键对应的值并返回原值
*/
func (m *Map) LoadAndDelete(key any) (value any, loaded bool) {
read, _ := m.read.Load().(readOnly)
// 判断要删除的key是否在read map中
e, ok := read.m[key]
// 不在read map中，并且read map和dirty map中的数据不一致
if !ok && read.amended {
m.mu.Lock()
// 同样的，防止在阻塞期间，dirty map被提升了
read, _ = m.read.Load().(readOnly)
e, ok = read.m[key]
if !ok && read.amended {
// 在dirty map中
e, ok = m.dirty[key]
// 直接删除
delete(m.dirty, key)
// 记录未命中次数
m.missLocked()
}
m.mu.Unlock()
}
// 并没有从read map中删除val，而是将entry中的指针置为nil
if ok {
return e.delete()
}
return nil, false
}
/*
将val从entry中删除
*/
func (e *entry) delete() (value any, ok bool) {
for {
p := atomic.LoadPointer(&e.p)
// p == nil说明已经被删除
// p == expunged 说明原来在dirty map中被删除了，并且原来的dirty map被提升为了read map
if p == nil || p == expunged {
return nil, false
}
// 将entry中的指针置为nil
if atomic.CompareAndSwapPointer(&e.p, p, nil) {
return *(*any)(p), true
}
}
}
5、总结
- 普通map在扩容时会有并发问题
- sync.Map使用了两个map，分离了扩容问题
- 不会引发map扩容的操作（查、改）使用read map
- 可能引发扩容的操作（新增）使用dirty map
- 读写操作都发送在read map，虽然普通map有并发读写问题，遇到并发读写时会panic，而且读写read map时没有加锁。是因为read map在读写时没有真正的对普通map进行写入，而是只有读取操作，读取entry，然后再读写entry中的指针，使用的是原子操作，因此不会产生并发读写map的问题
- sync.Map在读多、写多、追加少的情况下性能比较好