看過這篇剖析,你還不懂 Go sync-Map 嗎?
hi, 大家好,我是 haohongfan。
本篇文章會從使用方式和源碼角度剖析 sync.Map。不過不管是日常開發還是開源項目中,好像 sync.Map 並沒有得到很好的利用,大家還是習慣使用 Mutex + Map 來使用。
下面這段代碼,看起來很有道理,其實是用錯了(背景:併發場景中獲取註冊信息)。
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 的同學看着上面這段代碼很眼熟,但確實是用錯了,關於爲什麼用錯了以及會造成什麼影響,請大家關注後續的文章。
我大概分析了下大家寧願使用 Mutex + Map,也不願使用 sync.Map 的原因:
-
sync.Map 本身就很難用,使用起來並不像一個 Map。失去了 map 應有的特權語法,如:make, map[1] 等
-
sync.Map 方法較多。讓一個簡單的 Map 使用起來有了較高的學習成本。
不管什麼樣的原因吧,當你讀過這篇文章後,在某些特定的併發場景下,建議使用 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 的相關操作轉成對應函數而已。
- 普通 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 兩個特有的函數,不過從字面就能理解是什麼意思了。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
}
sync map 全景圖
Load
Store
Delete
read map 的值是什麼時間更新的 ?
-
Load/LoadOrStore/LoadAndDelete 時,當 misses 數量大於等於 dirty map 的元素個數時,會整體複製 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 數量大於等於 dirty map 的元素個數時,會整體複製 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 數量大於等於 dirty map 的元素個數時,會整體複製 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 中也可能存在。
-
當訪問多次,發現 dirty map 中存在,read map 中不存在,導致 misses 數量大於等於 dirty map 的元素個數時,會整體複製 dirty map 到 read map。
-
當出現 dirty map 向 read map 複製後,dirty map 會被置成 nil。
-
當出現 dirty map 向 read map 複製後,readOnly.amended 等於了 false。當新插入了一個值時,會將 read map 中的值,重新給 dirty map 賦值一遍
read/dirty map 中的值一定是有效的嗎?
並不一定。放入到 read/dirty map 中的值總共有 3 種類型:
-
nil:如果獲取到的 value 是 nil,那說明這個 key 是已經刪除過的。既不在 read map,也不在 dirty map
-
expunged:這個 key 在 dirty map 中是不存在的
-
valid:其實就正常的情況,要麼這個值存在在 read map 中,要麼存在在 dirty map 中
sync.Map 是如何提高性能的?
通過源碼解析,我們知道 sync.Map 裏面有兩個普通 map,read map 主要是負責讀,dirty map 是負責讀和寫(加鎖)。在讀多寫少的場景下,read map 的值基本不發生變化,可以讓 read map 做到無鎖操作,就減少了使用 Mutex + Map 必須的加鎖 / 解鎖環節,因此也就提高了性能。
不過也能夠看出來,read map 也是會發生變化的,如果某些 key 寫操作特別頻繁的話,sync.Map 基本也就退化成了 Mutex + Map(有可能性能還不如 Mutex + Map)。
所以,不是說使用了 sync.Map 就一定能提高程序性能,我們日常使用中儘量注意拆分粒度來使用 sync.Map。
關於如何分析 sync.Map 是否優化了程序性能,同樣可以使用 pprof。具體過程可以參考 《這可能是最容易理解的 Go Mutex 源碼剖析》
sync.Map 應用場景
-
讀多寫少
-
寫操作也多,但是修改的 key 和讀取的 key 特別不重合。
關於第二點我覺得挺扯的,畢竟我們很難把控這一點,不過由於是官方的註釋還是放在這裏。
實際開發中我們要注意使用場景和擅用 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
本文由 Readfog 進行 AMP 轉碼,版權歸原作者所有。
來源:https://mp.weixin.qq.com/s/kblDTqKlUaTITIppigq9yA