Go中Sync.Map的知識點有哪些

這篇文章主要講解了“ Go中Sync.Map的知識點有哪些”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“ Go中Sync.Map的知識點有哪些”吧！

sync.Map 優勢

在 Go 官方文檔中明確指出 Map 類型的一些建議：

• 多個 goroutine 的并發使用是安全的，不需要額外的鎖定或協調控制。

• 大多數代碼應該使用原生的 map，而不是單獨的鎖定或協調控制，以獲得更好的類型安全性和維護性。

同時 Map 類型，還針對以下場景進行了性能優化：

• 當一個給定的鍵的條目只被寫入一次但被多次讀取時。例如在僅會增長的緩存中，就會有這種業務場景。

• 當多個 goroutines 讀取、寫入和覆蓋不相干的鍵集合的條目時。

這兩種情況與 Go map 搭配單獨的 Mutex 或 RWMutex 相比較，使用 Map 類型可以大大減少鎖的爭奪。

性能測試

聽官方文檔介紹了一堆好處后，他并沒有講到缺點，所說的性能優化后的優勢又是否真實可信。我們一起來驗證一下。

首先我們定義基本的數據結構：

// 代表互斥鎖 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，有興趣的小伙伴可以自己拉下來運行試一下。

壓測結果

1)寫入：

在寫入元素上，最慢的是 sync.map 類型，其次是原生 map+互斥鎖(Mutex)，最快的是原生 map+讀寫鎖(RwMutex)。

總體的排序(從慢到快)為：SyncMapStore < MapStore < RwMapStore。

2)查找：

在查找元素上，最慢的是原生 map+互斥鎖，其次是原生 map+讀寫鎖。最快的是 sync.map 類型。

總體的排序為：MapLookup < RwMapLookup < SyncMapLookup。

3)刪除：

在刪除元素上，最慢的是原生 map+讀寫鎖，其次是原生 map+互斥鎖，最快的是 sync.map 類型。

總體的排序為：RwMapDelete < MapDelete < SyncMapDelete。

場景分析

根據上述的壓測結果，我們可以得出 sync.Map 類型：

• 在讀和刪場景上的性能是最佳的，領先一倍有多。

• 在寫入場景上的性能非常差，落后原生 map+鎖整整有一倍之多。

因此在實際的業務場景中。假設是讀多寫少的場景，會更建議使用 sync.Map 類型。

但若是那種寫多的場景，例如多 goroutine 批量的循環寫入，那就建議另辟途徑了，性能不忍直視(無性能要求另當別論)。

sync.Map 剖析

清楚如何測試，測試的結果后。我們需要進一步深挖，知其所以然。

為什么 sync.Map 類型的測試結果這么的 “偏科”，為什么讀操作性能這么高，寫操作性能低的可怕，他是怎么設計的?

數據結構

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，再往下看，食用效果會更佳，后續會圍繞著這幾個概念流轉。

查找過程

劃重點，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 屬性，配套解決了每次讀取都涉及鎖的問題，實現了讀這一個使用場景的高性能。

寫入過程

我們直接關注 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 復制數據時的偶然性能抖動是否能夠接受。

刪除過程

這時候可能有小伙伴在想了。寫入過程，理論上和刪除不會差太遠。怎么 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  的內存就永遠無法釋放了...

感謝各位的閱讀，以上就是“ Go中Sync.Map的知識點有哪些”的內容了，經過本文的學習后，相信大家對 Go中Sync.Map的知識點有哪些這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！