如何使用 atomic 包減少鎖沖突

作者：double12gzh 2021-12-27 10:13:51

Go 提供了 channel 或 mutex 等內存同步機制，有助于解決不同的問題。在共享內存的情況下，mutex 可以保護內存不發生數據競爭(data race)。不過，雖然存在兩個 mutex，但 Go 也通過 atomic 包提供了原子內存基元來提高性能。在深入研究解決方案之前，我們先回過頭來看看數據競爭。

寫在前面

本文基于 Golang 1.14

數據競爭

當兩個或兩個以上的 goroutine 同時訪問同一塊內存區域，并且其中至少有一個在寫時，就會發生數據競爭。雖然 map 內部有一定的機制來防止數據競爭，但一個簡單的結構體并沒有任何的機制，因此容易發生數據競爭。

為了說明數據競爭，我以一個goroutine 持續更新的配置為例向大家展示一下。

package main 
 
import ( 
    "fmt" 
    "sync" 
) 
 
type Config struct { 
    a []int 
} 
 
func main() { 
    cfg := &Config{} 
 
    // 啟動一個 writer goroutine，不斷寫入數據 
    go func() { 
        i := 0 
 
        for { 
            i++ 
            cfg.a = []int{i, i + 1, i + 2, i + 3, i + 4, i + 5} 
        } 
    }() 
 
    // 啟動多個 reader goroutine，不斷獲取數據 
    var wg sync.WaitGroup 
    for n := 0; n < 4; n++ { 
        wg.Add(1) 
        go func() { 
            for n := 0; n < 100; n++ { 
                fmt.Printf("%#v\n", cfg) 
            } 
            wg.Done() 
        }() 
    } 
 
    wg.Wait() 
}

運行這段代碼可以清楚地看到，原本期望是運行上述代碼后，每一行的數字應該是連續的，但是由于數據競爭的存在，導致結果是非確定性的。

F:\hello>go run main.go 
[...] 
&main.Config{a:[]int{180954, 180962, 180967, 180972, 180977, 180983}} 
&main.Config{a:[]int{181296, 181304, 181311, 181318, 181322, 181323}} 
&main.Config{a:[]int{181607, 181617, 181624, 181631, 181636, 181643}}

我們可以在運行時加入參數 --race 看一下結果：

F:\hello>go run --race main.go 
[...] 
&main.Config{a:[]int(nil)} 
================== 
&main.Config{a:[]int(nil)} 
WARNING: DATA RACE&main.Config{a:[]int(nil)} 
 
Read at 0x00c00000c210 by Goroutine 9: 
  reflect.Value.Int() 
      D:/Go/src/reflect/value.go:988 +0x3584 
  fmt.(*pp).printValue() 
      D:/Go/src/fmt/print.go:749 +0x3590 
  fmt.(*pp).printValue() 
      D:/Go/src/fmt/print.go:860 +0x8f2 
  fmt.(*pp).printValue() 
      D:/Go/src/fmt/print.go:810 +0x289a 
  fmt.(*pp).printValue() 
      D:/Go/src/fmt/print.go:880 +0x261c 
  fmt.(*pp).printArg() 
      D:/Go/src/fmt/print.go:716 +0x26b 
  fmt.(*pp).doPrintf() 
      D:/Go/src/fmt/print.go:1030 +0x326 
  fmt.Fprintf() 
      D:/Go/src/fmt/print.go:204 +0x86 
  fmt.Printf() 
      D:/Go/src/fmt/print.go:213 +0xbc 
  main.main.func2() 
      F:/hello/main.go:31 +0x42 
 
Previous write at 0x00c00000c210 by goroutine 7: 
  main.main.func1() 
      F:/hello/main.go:21 +0x66 
 
goroutine 9 (running) created at: 
  main.main() 
      F:/hello/main.go:29 +0x124 
 
goroutine 7 (running) created at: 
  main.main() 
      F:/hello/main.go:16 +0x95 
==================

為了避免同時讀寫過程中產生的數據競爭最常采用的方法可能是使用 mutex 或 atomic 包。

Mutex?還是 Atomic?

標準庫在 sync 包提供了兩種互斥鎖：sync.Mutex 和 sync.RWMutex。后者在你的程序需要處理多個讀操作和極少的寫操作時進行了優化。

針對上面代碼中產生的數據競爭問題，我們看一下，如何解決呢?

使用 sync.Mutex 解決數據競爭

package main 
 
import ( 
    "fmt" 
    "sync" 
) 
 
// Config 定義一個結構體用于模擬存放配置數據 
type Config struct { 
    a []int 
} 
 
func main() { 
    cfg := &Config{} 
    var mux sync.RWMutex 
 
    // 啟動一個 writer goroutine，不斷寫入數據 
    go func() { 
        i := 0 
 
        for { 
            i++ 
            // 進行數據寫入時，先通過鎖進行鎖定 
            mux.Lock() 
            cfg.a = []int{i, i + 1, i + 2, i + 3, i + 4, i + 5} 
            mux.Unlock() 
        } 
    }() 
 
    // 啟動多個 reader goroutine，不斷獲取數據 
    var wg sync.WaitGroup 
    for n := 0; n < 4; n++ { 
        wg.Add(1) 
        go func() { 
            for n := 0; n < 100; n++ { 
                // 因為這里只是需要讀取數據，所以只需要加一個讀鎖即可 
                mux.RLock() 
                fmt.Printf("%#v\n", cfg) 
                mux.RUnlock() 
            } 
            wg.Done() 
        }() 
    } 
 
    wg.Wait() 
}

通過上面的代碼，我們做了兩處改動。第一處改動在寫數據前通過 mux.Lock() 加了一把鎖;第二處改動在讀數據前通過 mux.RLock() 加了一把讀鎖。

運行上述代碼看一下結果：

F:\hello>go run --race main.go 
&main.Config{a:[]int{512, 513, 514, 515, 516, 517}} 
&main.Config{a:[]int{512, 513, 514, 515, 516, 517}} 
&main.Config{a:[]int{513, 514, 515, 516, 517, 518}} 
&main.Config{a:[]int{513, 514, 515, 516, 517, 518}} 
&main.Config{a:[]int{513, 514, 515, 516, 517, 518}} 
&main.Config{a:[]int{513, 514, 515, 516, 517, 518}} 
&main.Config{a:[]int{514, 515, 516, 517, 518, 519}} 
[...]

這次達到了我們的預期并且也沒有產生數據競爭。

使用 atomic 解決數據競爭

package main 
 
import ( 
    "fmt" 
    "sync" 
    "sync/atomic" 
) 
 
type Config struct { 
    a []int 
} 
 
func main() { 
    var v atomic.Value 
 
    // 寫入數據 
    go func() { 
        var i int 
        for { 
            i++ 
            cfg := Config{ 
                a: []int{i, i + 1, i + 2, i + 3, i + 4, i + 5}, 
            } 
            v.Store(cfg) 
        } 
    }() 
 
    // 讀取數據 
    var wg sync.WaitGroup 
    for n := 0; n < 4; n++ { 
        wg.Add(1) 
        go func() { 
            for n := 0; n < 100; n++ { 
                cfg := v.Load() 
                fmt.Printf("%#v\n", cfg) 
            } 
            wg.Done() 
        }() 
    } 
 
    wg.Wait() 
}

這里我們使用了 atomic 包，通過運行我們發現，也同樣達到了我們期望的結果：

[...] 
main.Config{a:[]int{219142, 219143, 219144, 219145, 219146, 219147}} 
main.Config{a:[]int{219491, 219492, 219493, 219494, 219495, 219496}} 
main.Config{a:[]int{219826, 219827, 219828, 219829, 219830, 219831}} 
main.Config{a:[]int{219948, 219949, 219950, 219951, 219952, 219953}}

從生成的輸出結果而言，看起來使用 atomic 包的解決方案要快得多，因為它可以生成更高的數字序列。為了更加嚴謹的證明這個結果，我們下面將對這兩個程序進行基準測試。

性能分析

一個 benchmark 應該根據被測量的內容來解釋。因此，我們假設之前的程序，有一個不斷存儲新配置的數據寫入器，同時也有多個不斷讀取配置的數據讀取器。為了涵蓋更多潛在的場景，我們還將包括一個只有數據讀取器的 benchmark，假設 Config 不經常改變。

下面是部分 benchmark 的代碼：

func BenchmarkMutexMultipleReaders(b *testing.B) { 
    var lastValue uint64 
    var mux sync.RWMutex 
    var wg sync.WaitGroup 
 
    cfg := Config{ 
        a: []int{0, 0, 0, 0, 0, 0}, 
    } 
 
    for n := 0; n < 4; n++ { 
        wg.Add(1) 
 
        go func() { 
            for n := 0; n < b.N; n++ { 
                mux.RLock() 
                atomic.SwapUint64(&lastValue, uint64(cfg.a[0])) 
                mux.RUnlock() 
            } 
            wg.Done() 
        }() 
    } 
 
    wg.Wait() 
}

執行上面的測試代碼后我們可以得到如下的結果：

name                              time/op 
AtomicOneWriterMultipleReaders-4  72.2ns ± 2% 
AtomicMultipleReaders-4           65.8ns ± 2% 
 
MutexOneWriterMultipleReaders-4    717ns ± 3% 
MutexMultipleReaders-4             176ns ± 2%

基準測試證實了我們之前看到的性能情況。為了了解 mutex 的瓶頸到底在哪里，我們可以在啟用 tracer 的情況下重新運行程序。

goroutines 運行時不間斷，能夠完成任務。對于帶有 mutex 的程序的配置文件，得到的結果那是完全不同的。

現在運行時間相當零碎，這是由于停放 goroutine 的 mutex 造成的。這一點可以從 goroutine 的概覽中得到證實，其中顯示了同步時被阻塞的時間。

屏蔽時間大概占到三分之一的時間，這一點可以從下面的 block profile 的圖中詳細看到。

在這種情況下，atomic 包肯定會帶來優勢。但是，在某些方面可能會降低性能。例如，如果你要存儲一張大地圖，每次更新地圖時都要復制它，這樣效率就很低。

via: https://medium.com/a-journey-with-go/go-how-to-reduce-lock-contention-with-the-atomic-package-ba3b2664b549

作者：Vincent Blanchon 譯者：double12gzh 校對：lxbwolf

責任編輯：未麗燕來源： Go語言中文網

Go atomic 數據競爭