hi, 大家好挥萌，我是 haohongfan。
本篇文章會從使用方式和源碼角度剖析 sync.Map枉侧。不過不管是日常開發(fā)還是開源項目中引瀑，好像 sync.Map 并沒有得到很好的利用，大家還是習慣使用 Mutex + Map 來使用榨馁。
下面這段代碼憨栽，看起來很有道理，其實是用錯了（背景：并發(fā)場景中獲取注冊信息）翼虫。
instance, ok := instanceMap[name]
if ok {
return instance, nil
}
initLock.Lock()
defer initLock.Unlock()
// double check
instance, ok = instanceMap[name]
if ok {
return instance, nil
}
這里使用使用 sync.Map 會更合理些屑柔，因為 sync.Map 底層完全包含了這個邏輯≌浣＃可能寫 Java 的同學看著上面這段代碼很眼熟掸宛，但確實是用錯了，關于為什么用錯了以及會造成什么影響招拙，請大家關注后續(xù)的文章唧瘾。
我大概分析了下大家寧愿使用 Mutex + Map措译，也不愿使用 sync.Map 的原因：
- sync.Map 本身就很難用，使用起來并不像一個 Map饰序。失去了 map 應有的特權語法领虹，如：make, map[1] 等
- sync.Map 方法較多。讓一個簡單的 Map 使用起來有了較高的學習成本求豫。
不管什么樣的原因吧塌衰，當你讀過這篇文章后，在某些特定的并發(fā)場景下蝠嘉，建議使用 sync.Map 代替 Map + Mutex 的猾蒂。
用法全解
package main
import (
"fmt"
"sync"
)
func main() {
var syncMap sync.Map
syncMap.Store("11", 11)
syncMap.Store("22", 22)
fmt.Println(syncMap.Load("11")) // 11
fmt.Println(syncMap.Load("33")) // 空
fmt.Println(syncMap.LoadOrStore("33", 33)) // 33
fmt.Println(syncMap.Load("33")) // 33
fmt.Println(syncMap.LoadAndDelete("33")) // 33
fmt.Println(syncMap.Load("33")) // 空
syncMap.Range(func(key, value interface{}) bool {
fmt.Printf("key:%v value:%v\n", key, value)
return true
})
// key:22 value:22
// key:11 value:11
}
其實 sync.Map 并不復雜，只是將普通 map 的相關操作轉成對應函數(shù)而已是晨。
| 普通 map | sync.Map | |
|---|---|---|
| map 獲取某個 key | map[1] | sync.Load(1) |
| map 添加元素 | map[1] = 10 | sync.Store(1, 10) |
| map 刪除一個 key | delete(map, 1) | sync.Delete(1) |
| 遍歷 map | for...range | sync.Range() |
sync.Map 兩個特有的函數(shù)肚菠，不過從字面就能理解是什么意思了。
LoadOrStore：sync.Map 存在就返回罩缴，不存在就插入
LoadAndDelete：sync.Map 獲取某個 key蚊逢，如果存在的話，同時刪除這個 key
源碼解析
type Map struct {
mu Mutex
read atomic.Value // readOnly read map
dirty map[interface{}]*entry // dirty map
misses int
}
read map 的值是什么時間更新的 箫章？
- Load/LoadOrStore/LoadAndDelete 時烙荷，當 misses 數(shù)量大于等于 dirty map 的元素個數(shù)時，會整體復制 dirty map 到 read map
- Store/LoadOrStore 時檬寂，當 read map 中存在這個key终抽，則更新
- Delete/LoadAndDelete 時，如果 read map 中存在這個key桶至，則設置這個值為 nil
dirty map 的值是什么時間更新的 昼伴？
- 完全是一個新 key， 第一次插入 sync.Map镣屹，必先插入 dirty map
- Store/LoadOrStore 時圃郊，當 read map 中不存在這個key，在 dirty map 存在這個key女蜈，則更新
- Delete/LoadAndDelete 時持舆，如果 read map 中不存在這個key，在 dirty map 存在這個key伪窖，則從 dirty map 中刪除這個key
- 當 misses 數(shù)量大于等于 dirty map 的元素個數(shù)時逸寓，會整體復制 dirty map 到 read map，同時設置 dirty map 為 nil
疑問：當 dirty map 復制到 read map 后覆山，將 dirty map 設置為 nil竹伸，也就是 dirty map 中就不存在這個 key 了。如果又新插入某個 key汹买，多次訪問后達到了 dirty map 往 read map 復制的條件佩伤，如果直接用 read map 覆蓋 dirty map聊倔，那豈不是就丟了之前在 read map 但不在 dirty map 的 key ?
答：其實并不會晦毙。當 dirty map 向 read map 復制后生巡，readOnly.amended 等于了 false。當新插入了一個值時见妒，會將 read map 中的值孤荣，重新給 dirty map 賦值一遍，也就是 read map 也會向 dirty map 中復制须揣。
func (m *Map) dirtyLocked() {
if m.dirty != nil {
return
}
read, _ := m.read.Load().(readOnly)
m.dirty = make(map[interface{}]*entry, len(read.m))
for k, e := range read.m {
if !e.tryExpungeLocked() {
m.dirty[k] = e
}
}
}
read map 和 dirty map 是什么時間刪除的盐股？
- 當 read map 中存在某個 key 的時候，這個時候只會刪除 read map耻卡， 并不會刪除 dirty map（因為 dirty map 不存在這個值）
- 當 read map 中不存在時疯汁，才會去刪除 dirty map 里面的值
疑問：如果按照這個刪除方式，那豈不是 dirty map 中會有殘余的 key卵酪，導致沒刪除掉幌蚊？
答：其實并不會。當 misses 數(shù)量大于等于 dirty map 的元素個數(shù)時溃卡，會整體復制 dirty map 到 read map溢豆。這個過程中還附帶了另外一個操作：將 dirty map 置為 nil。
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
}
read map 與 dirty map 的關系 瘸羡？
- 在 read map 中存在的值漩仙，在 dirty map 中可能不存在。
- 在 dirty map 中存在的值犹赖，在 read map 中也可能存在队他。
- 當訪問多次，發(fā)現(xiàn) dirty map 中存在峻村，read map 中不存在漱挎，導致 misses 數(shù)量大于等于 dirty map 的元素個數(shù)時，會整體復制 dirty map 到 read map雀哨。
- 當出現(xiàn) dirty map 向 read map 復制后磕谅，dirty map 會被置成 nil。
- 當出現(xiàn) dirty map 向 read map 復制后雾棺，readOnly.amended 等于了 false膊夹。當新插入了一個值時，會將 read map 中的值捌浩，重新給 dirty map 賦值一遍
read/dirty map 中的值一定是有效的嗎放刨？
并不一定。放入到 read/dirty map 中的值總共有 3 種類型：
- nil：如果獲取到的 value 是 nil尸饺，那說明這個 key 是已經(jīng)刪除過的进统。既不在 read map助币，也不在 dirty map
- expunged：這個 key 在 dirty map 中是不存在的
- valid：其實就正常的情況，要么這個值存在在 read map 中螟碎，要么存在在 dirty map 中
sync.Map 是如何提高性能的眉菱？
通過源碼解析，我們知道 sync.Map 里面有兩個普通 map掉分，read map主要是負責讀俭缓，dirty map 是負責讀和寫（加鎖）。在讀多寫少的場景下酥郭，read map 的值基本不發(fā)生變化华坦，可以讓 read map 做到無鎖操作，就減少了使用 Mutex + Map 必須的加鎖/解鎖環(huán)節(jié)不从，因此也就提高了性能惜姐。
不過也能夠看出來，read map 也是會發(fā)生變化的椿息，如果某些 key 寫操作特別頻繁的話歹袁，sync.Map 基本也就退化成了 Mutex + Map（有可能性能還不如 Mutex + Map）。
所以撵颊，不是說使用了 sync.Map 就一定能提高程序性能宇攻，我們日常使用中盡量注意拆分粒度來使用 sync.Map。
關于如何分析 sync.Map 是否優(yōu)化了程序性能倡勇，同樣可以使用 pprof逞刷。具體過程可以參考 《這可能是最容易理解的 Go Mutex 源碼剖析》
sync.Map 應用場景
- 讀多寫少
- 寫操作也多，但是修改的 key 和讀取的 key 特別不重合妻熊。
關于第二點我覺得挺扯的夸浅，畢竟我們很難把控這一點，不過由于是官方的注釋還是放在這里扔役。
實際開發(fā)中我們要注意使用場景和擅用 pprof 來分析程序性能帆喇。
sync.Map 使用注意點
和 Mutex 一樣， sync.Map 也同樣不能被復制亿胸，因為 atomic.Value 是不能被復制的坯钦。
參考鏈接
- https://golang.design/under-the-hood/zh-cn/part1basic/ch05sync/map/
- https://draveness.me/golang-sync-primitives/
- https://github.com/golang/go/blob/master/src/sync/map.go
sync.Map 完整流程圖獲取鏈接：鏈接: https://pan.baidu.com/s/1RIX6NKj8UhWkdFyFHptWwg 密碼: rsg9。
