最佳化 Go 中的 map 並發存取

這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。

Catena （時序儲存引擎）中有一個函數的實現備受爭議，它從 map 中根據指定的 name 擷取一個 metricSource。每一次插入操作都會至少調用一次這個函數，現實情境中該函數調用更是頻繁，並且是跨多個協程的，因此我們必須要考慮同步。

該函數從 map[string]*metricSource 中根據指定的 name 擷取一個指向 metricSource 的指標，如果擷取不到則建立一個並返回。其中要注意的關鍵點是我們只會對這個 map 進行插入操作。

簡單實現如下：（為節省篇幅，省略了函數頭和返回，只貼重要部分）

var source *memorySourcevar present boolp.lock.Lock() // lock the mutexdefer p.lock.Unlock() // unlock the mutex at the endif source, present = p.sources[name]; !present {// The source wasn't found, so we'll create it.source = &memorySource{name: name,metrics: map[string]*memoryMetric{},}// Insert the newly created *memorySource.p.sources[name] = source}

經測試，該實現大約可以達到 1,400,000 插入/秒（通過協程並發調用，GOMAXPROCS 設定為 4）。看上去很快，但實際上它是慢於單個協程的，因為多個協程間存在鎖競爭。

我們簡化一下情況來說明這個問題，假設兩個協程分別要擷取“a”、“b”，並且“a”、“b”都已經存在於該 map 中。上述實現在運行時，一個協程擷取到鎖、拿指標、解鎖、繼續執行，此時另一個協程會被卡在擷取鎖。等待鎖釋放是非常耗時的，並且協程越多效能越差。

讓它變快的方法之一是移除鎖控制，並保證只有一個協程訪問這個 map。這個方法雖然簡單，但沒有伸縮性。下面我們看看另一種簡單的方法，並保證了安全執行緒和伸縮性。 

var source *memorySourcevar present boolif source, present = p.sources[name]; !present { // added this line// The source wasn't found, so we'll create it.p.lock.Lock() // lock the mutexdefer p.lock.Unlock() // unlock at the endif source, present = p.sources[name]; !present {source = &memorySource{name: name,metrics: map[string]*memoryMetric{},}// Insert the newly created *memorySource.p.sources[name] = source}// if present is true, then another goroutine has already inserted// the element we want, and source is set to what we want.} // added this line// Note that if the source was present, we avoid the lock completely!

該實現可以達到 5,500,000 插入/秒，比第一個版本快 3.93 倍。有 4 個協程在跑測試，結果數值和預期是基本吻合的。

這個實現是 ok 的，因為我們沒有刪除、修改操作。在 CPU 緩衝中的指標地址我們可以安全使用，不過要注意的是我們還是需要加鎖。如果不加，某協程在建立插入 source 時另一個協程可能已經正在插入，它們會處於競爭狀態。這個版本中我們只是在很少情況下加鎖，所以效能提高了很多。

John Potocny 建議移除 defer，因為會延誤解鎖時間（要在整個函數返回時才解鎖），下面給出一個“終極”版本：

var source *memorySourcevar present boolif source, present = p.sources[name]; !present {// The source wasn't found, so we'll create it.p.lock.Lock() // lock the mutexif source, present = p.sources[name]; !present {source = &memorySource{name: name,metrics: map[string]*memoryMetric{},}// Insert the newly created *memorySource.p.sources[name] = source}p.lock.Unlock() // unlock the mutex}// Note that if the source was present, we avoid the lock completely!

9,800,000 插入/秒！改了 4 行提升到 7 倍啊！！有木有！！！！

更新：（譯註：原作者循序漸進非常贊）

上面實現正確嗎？No！通過 Go Data Race Detector 我們可以很輕鬆發現竟態條件，我們不能保證 map 在同時讀寫時的完整性。

下面給出不存在竟態條件、安全執行緒，應該算是“正確”的版本了。使用了 RWMutex，讀操作不會被鎖，寫操作保持同步。

var source *memorySourcevar present boolp.lock.RLock()if source, present = p.sources[name]; !present {// The source wasn't found, so we'll create it.p.lock.RUnlock()p.lock.Lock()if source, present = p.sources[name]; !present {source = &memorySource{name: name,metrics: map[string]*memoryMetric{},}// Insert the newly created *memorySource.p.sources[name] = source}p.lock.Unlock()} else {p.lock.RUnlock()}

經測試，該版本效能為其之前版本的 93.8%，在保證正確性的前提先能到達這樣已經很不錯了。也許我們可以認為它們之間根本沒有可比性，因為之前的版本是錯的。

 

本文譯自：Optimizing Concurrent Map Access in Go

---- EOF ----