一口氣搞懂 Go sync-map 所有知識點

在之前的 《爲什麼 Go map 和 slice 是非線程安全的？》 文章中，我們討論了 Go 語言的 map 和 slice 非線程安全的問題，基於此引申出了 map 的兩種目前在業界使用的最多的併發支持的模式。

分別是：

有了選擇，總是有選擇困難症的，這兩種到底怎麼選，誰的性能更加的好？我有一個朋友說 標準庫 sync.Map 性能菜的很，不要用。我到底聽誰的...

今天煎魚就帶你揭祕 Go sync.map，我們先會了解清楚什麼場景下，Go map 的多種類型怎麼用，誰的性能最好！

接着根據各 map 性能分析的結果，針對性的對 sync.map 進行源碼解剖，瞭解 WHY。

一起愉快地開始吸魚之路。

sync.Map 優勢

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

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

這兩種情況與 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）寫入：

gBVPJE

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

總體的排序（從慢到快）爲：SyncMapStore < MapStore < RwMapStore。

2）查找：

Qua0NN

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

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

3）刪除：

cssGHQ

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

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

場景分析

根據上述的壓測結果，我們可以得出 sync.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
}

在 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 中是否包含所需的元素：

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 方法上互斥鎖，保證數據安全，也是凸顯性能變差的第一幕。

其分爲以下三個處理分支：

我們理一理，寫入過程的整體流程就是：

回到最初的話題，爲什麼他寫入性能差那麼多。究其原因：

可得知 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 的內存就永遠無法釋放了...

總結

通過閱讀本文，我們明確了 sync.Map 和原生 map + 互斥鎖 / 讀寫鎖之間的性能情況。

標準庫 sync.Map 雖說支持併發讀寫 map，但更適用於讀多寫少的場景，因爲他寫入的性能比較差，使用時要考慮清楚這一點。

另外我們針對 sync.Map 的性能差異，進行了深入的源碼剖析，瞭解到了其背後快、慢的原因，實現了知其然知其所以然。

經常看到併發讀寫 map 導致致命錯誤，實在是令人憂心。大家覺得如果本文不錯，歡迎分享給更多的 Go 愛好者 ：）

參考

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/8aufz1IzElaYR43ccuwMyA

猜你喜歡