Go 並發讀寫 sync.map 詳細
map 的兩種目前在業界使用的最多的並發支持的模式分別是:
- 原生
map +
互斥鎖或讀寫鎖mutex
。 - 標準庫
sync.Map
(Go1.9及以後)。
有瞭選擇,總是有選擇困難癥的,這兩種到底怎麼選,誰的性能更加的好?我有一個朋友說 標準庫 sync.Map
性能菜的很,不要用。我到底聽誰的…
今天煎魚就帶你揭秘 Go sync.map
,我們先會瞭解清楚什麼場景下,Go map
的多種類型怎麼用,誰的性能最好!
接著根據各 map
性能分析的結果,針對性的對 sync.map
進行源碼解剖,瞭解 WHY。
一起愉快地開始吸魚之路。
1、sync.Map 優勢
在 Go 官方文檔中明確指出 Map 類型的一些建議:
- 多個
goroutine
的並發使用是安全的,不需要額外的鎖定或協調控制。 - 大多數代碼應該使用原生的
map
,而不是單獨的鎖定或協調控制,以獲得更好的類型安全性和維護性。
同時 Map
類型,還針對以下場景進行瞭性能優化:
- 當一個給定的鍵的條目隻被寫入一次但被多次讀取時。例如在僅會增長的緩存中,就會有這種業務場景。
- 當多個
goroutines
讀取、寫入和覆蓋不相幹的鍵集合的條目時。
這兩種情況與 Go map
搭配單獨的 Mutex
或 RWMutex
相比較,使用 Map
類型可以大大減少鎖的爭奪。
2、性能測試
聽官方文檔介紹瞭一堆好處後,他並沒有講到缺點,所說的性能優化後的優勢又是否真實可信。我們一起來驗證一下。
首先我們定義基本的數據結構:
// 代表互斥鎖 type FooMap struct { sync.Mutex data map[int]int } // 代表讀寫鎖 type BarRwMap struct { sync.RWMutex data map[int]int } var fooMap *FooMap var barRwMap *BarRwMap var syncMap *sync.Map // 初始化基本數據結構 func init() { fooMap = &FooMap{data: make(map[int]int, 100)} barRwMap = &BarRwMap{data: make(map[int]int, 100)} syncMap = &sync.Map{} }
在配套方法上,常見的增刪改查動作我們都編寫瞭相應的方法。用於後續的壓測(隻展示部分代碼):
func builtinRwMapStore(k, v int) { barRwMap.Lock() defer barRwMap.Unlock() barRwMap.data[k] = v } func builtinRwMapLookup(k int) int { barRwMap.RLock() defer barRwMap.RUnlock() if v, ok := barRwMap.data[k]; !ok { return -1 } else { return v } } func builtinRwMapDelete(k int) { barRwMap.Lock() defer barRwMap.Unlock() if _, ok := barRwMap.data[k]; !ok { return } else { delete(barRwMap.data, k) } }
其餘的類型方法基本類似,考慮重復篇幅問題因此就不在此展示瞭。
壓測方法基本代碼如下:
func BenchmarkBuiltinRwMapDeleteParalell(b *testing.B) { b.RunParallel(func(pb *testing.PB) { r := rand.New(rand.NewSource(time.Now().Unix())) for pb.Next() { k := r.Intn(100000000) builtinRwMapDelete(k) } }) }
這塊主要就是增刪改查的代碼和壓測方法的準備,壓測代碼直接復用的是大白大佬的 go19-examples/benchmark-for-map
項目。
也可以使用 Go 官方提供的 map\_bench\_test.go,有興趣的小夥伴可以自己拉下來運行試一下。
2.1 壓測結果
1)寫入
名 | 含義 | 壓測結果 |
---|---|---|
BenchmarkBuiltinMapStoreParalell-4 | map+mutex 寫入元素 | 237.1 ns/op |
BenchmarkSyncMapStoreParalell-4 | sync.map 寫入元素 | 509.3 ns/op |
BenchmarkBuiltinRwMapStoreParalell-4 | map+rwmutex 寫入元素 | 207.8 ns/op |
總體的排序(從慢到快)為:SyncMapStore < MapStore < RwMapStore。
2)查找
方法名 | 含義 | 壓測結果 |
---|---|---|
BenchmarkBuiltinMapLookupParalell-4 | map+mutex 查找元素 | 166.7 ns/op |
BenchmarkBuiltinRwMapLookupParalell-4 | map+rwmutex 查找元素 | 60.49 ns/op |
BenchmarkSyncMapLookupParalell-4 | sync.map 查找元素 | 53.39 ns/op |
在查找元素上,最慢的是原生 map+互斥鎖,其次是原生 map+讀寫鎖。最快的是 sync.map
類型。
總體的排序為:MapLookup < RwMapLookup < SyncMapLookup。
3)刪除
方法名 | 含義 | 壓測結果 |
---|---|---|
BenchmarkBuiltinMapDeleteParalell-4 | map+mutex 刪除元素 | 168.3 ns/op |
BenchmarkBuiltinRwMapDeleteParalell-4 | map+rwmutex 刪除元素 | 188.5 ns/op |
BenchmarkSyncMapDeleteParalell-4 | sync.map 刪除元素 | 41.54 ns/op |
在刪除元素上,最慢的是原生 map+
讀寫鎖,其次是原生 map+
互斥鎖,最快的是 sync.map
類型。
總體的排序為:RwMapDelete < MapDelete < SyncMapDelete
。
2.3 場景分析
根據上述的壓測結果,我們可以得出 sync.Map
類型:
- 在讀和刪場景上的性能是最佳的,領先一倍有多。
- 在寫入場景上的性能非常差,落後原生 map+鎖整整有一倍之多。
因此在實際的業務場景中。假設是讀多寫少的場景,會更建議使用 sync.Map 類型。
但若是那種寫多的場景,例如多 goroutine
批量的循環寫入,那就建議另辟途徑瞭,性能不忍直視(無性能要求另當別論)。
3、sync.Map 剖析
清楚如何測試,測試的結果後。我們需要進一步深挖,知其所以然。
為什麼 sync.Map 類型的測試結果這麼的 “偏科”,為什麼讀操作性能這麼高,寫操作性能低的可怕,他是怎麼設計的?
3.1 數據結構
sync.Map
類型的底層數據結構如下:
type Map struct { mu Mutex read atomic.Value // readOnly dirty map[interface{}]*entry misses int } // Map.read 屬性實際存儲的是 readOnly。 type readOnly struct { m map[interface{}]*entry amended bool }
mu
:互斥鎖,用於保護read
和dirty
。read
:隻讀數據,支持並發讀取(atomic.Value
類型)。如果涉及到更新操作,則隻需要加鎖來保證數據安全。read
實際存儲的是readOnly
結構體,內部也是一個原生map
,amended
屬性用於標記read
和dirty
的數據是否一致。dirty
:讀寫數據,是一個原生map
,也就是非線程安全。操作dirty
需要加鎖來保證數據安全。misses
:統計有多少次讀取read
沒有命中。每次read
中讀取失敗後,misses
的計數值都會加 1。
在 read
和 dirty
中,都有涉及到的結構體:
type entry struct { p unsafe.Pointer // *interface{} }
其包含一個指針 p, 用於指向用戶存儲的元素(key)所指向的 value
值。
在此建議你必須搞懂 read
、dirty
、entry
,再往下看,食用效果會更佳,後續會圍繞著這幾個概念流轉。
3.2 查找過程
劃重點,Map
類型本質上是有兩個 “map
”。一個叫 read
、一個叫 dirty
,長的也差不多:
sync.Map 的 2 個 map
當我們從 sync.Map 類型中讀取數據時,其會先查看 read 中是否包含所需的元素:
- 若有,則通過
atomic
原子操作讀取數據並返回。 - 若無,則會判斷
read.readOnly
中的amended
屬性,他會告訴程序 dirty 是否包含read.readOnly.m
中沒有的數據;因此若存在,也就是amended
為 true,將會進一步到 dirty 中查找數據。
sync.Map
的讀操作性能如此之高的原因,就在於存在 read 這一巧妙的設計,其作為一個緩存層,提供瞭快路徑(fast path)的查找。
同時其結合 amended
屬性,配套解決瞭每次讀取都涉及鎖的問題,實現瞭讀這一個使用場景的高性能。
3.3 寫入過程
我們直接關註 sync.Map
類型的 Store
方法,該方法的作用是新增或更新一個元素。
源碼如下:
func (m *Map) Store(key, value interface{}) { read, _ := m.read.Load().(readOnly) if e, ok := read.m[key]; ok && e.tryStore(&value) { return } ... }
調用 Load
方法檢查 m.read
中是否存在這個元素。若存在,且沒有被標記為刪除狀態,則嘗試存儲。
若該元素不存在或已經被標記為刪除狀態,則繼續走到下面流程:
func (m *Map) Store(key, value interface{}) { ... m.mu.Lock() read, _ = m.read.Load().(readOnly) if e, ok := read.m[key]; ok { if e.unexpungeLocked() { m.dirty[key] = e } e.storeLocked(&value) } else if e, ok := m.dirty[key]; ok { e.storeLocked(&value) } else { if !read.amended { m.dirtyLocked() m.read.Store(readOnly{m: read.m, amended: true}) } m.dirty[key] = newEntry(value) } m.mu.Unlock() }
由於已經走到瞭 dirty
的流程,因此開頭就直接調用瞭 Lock
方法上互斥鎖,保證數據安全,也是凸顯性能變差的第一幕。
其分為以下三個處理分支:
- 若發現 read 中存在該元素,但已經被標記為已刪除(
expunged
),則說明dirty
不等於nil
(dirty 中肯定不存在該元素)。其將會執行如下操作。 - 將元素狀態從已刪除(
expunged
)更改為 nil。 - 將元素插入 dirty 中。
- 若發現 read 中不存在該元素,但 dirty 中存在該元素,則直接寫入更新
entry
的指向。 - 若發現
read
和dirty
都不存在該元素,則從read
中復制未被標記刪除的數據,並向dirty
中插入該元素,賦予元素值 entry 的指向。
我們理一理,寫入過程的整體流程就是:
- 查
read
,read
上沒有,或者已標記刪除狀態。 - 上互斥鎖(Mutex)。
- 操作 dirty,根據各種數據情況和狀態進行處理。
回到最初的話題,為什麼他寫入性能差那麼多。究其原因:
- 寫入一定要會經過
read
,無論如何都比別人多一層,後續還要查數據情況和狀態,性能開銷相較更大。 - (第三個處理分支)當初始化或者
dirty
被提升後,會從read
中復制全量的數據,若 read 中數據量大,則會影響性能。
可得知 sync.Map
類型不適合寫多的場景,讀多寫少是比較好的。
若有大數據量的場景,則需要考慮 read 復制數據時的偶然性能抖動是否能夠接受。
3.4 刪除過程
這時候可能有小夥伴在想瞭。寫入過程,理論上和刪除不會差太遠。怎麼 sync.Map
類型的刪除的性能似乎還行,這裡面有什麼貓膩?
源碼如下:
func (m *Map) LoadAndDelete(key interface{}) (value interface{}, loaded bool) { read, _ := m.read.Load().(readOnly) e, ok := read.m[key] ... if ok { return e.delete() } }
刪除是標準的開場,依然先到 read
檢查該元素是否存在。
若存在,則調用 delete
標記為 expunged
(刪除狀態),非常高效。可以明確在 read
中的元素,被刪除,性能是非常好的。
若不存在,也就是走到 dirty 流程中:
func (m *Map) LoadAndDelete(key interface{}) (value interface{}, loaded bool) { ... if !ok && read.amended { m.mu.Lock() read, _ = m.read.Load().(readOnly) e, ok = read.m[key] if !ok && read.amended { e, ok = m.dirty[key] delete(m.dirty, key) m.missLocked() } m.mu.Unlock() } ... return nil, false }
若 read
中不存在該元素,dirty
不為空,read
與 dirty
不一致(利用 amended
判別),則表明要操作 dirty
,上互斥鎖。
再重復進行雙重檢查,若 read
仍然不存在該元素。則調用 delete
方法從 dirty
中標記該元素的刪除。
需要註意,出現頻率較高的 delete 方法:
func (e *entry) delete() (value interface{}, ok bool) { for { p := atomic.LoadPointer(&e.p) if p == nil || p == expunged { return nil, false } if atomic.CompareAndSwapPointer(&e.p, p, nil) { return *(*interface{})(p), true } } }
該方法都是將 entry.p
置為 nil
,並且標記為 expunged
(刪除狀態),而不是真真正正的刪除。
註:不要誤用 sync.Map
,前段時間從字節大佬分享的案例來看,他們將一個連接作為 key
放瞭進去,於是和這個連接相關的,例如:buffer
的內存就永遠無法釋放瞭…
總結:
針對 sync.Map
的性能差異,進行瞭深入的源碼剖析,瞭解到瞭其背後快、慢的原因,實現瞭知其然知其所以然。
經常看到並發讀寫 map
導致致命錯誤,實在是令人憂心。大傢覺得如果本文不錯,歡迎分享給更多的 Go 愛好者 :)
到此這篇關於Go 並發讀寫 sync.map 詳細的文章就介紹到這瞭,更多相關Go 並發讀寫 sync.map 內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet!
推薦閱讀:
- go sync.Map基本原理深入解析
- Golang的鎖機制與使用技巧小結
- Go語言讀寫鎖RWMutex的源碼分析
- 一文掌握Go語言並發編程必備的Mutex互斥鎖
- Go語言如何利用Mutex保障數據讀寫正確