如何使用 atomic 包減少鎖沖突
寫在前面
本文基于 Golang 1.14
Go 提供了 channel 或 mutex 等內存同步機制，有助于解決不同的問題。在共享內存的情況下，mutex 可以保護內存不發生數據競爭(data race)。不過，雖然存在兩個 mutex，但 Go 也通過 atomic 包提供了原子內存基元來提高性能。在深入研究解決方案之前，我們先回過頭來看看數據競爭。
數據競爭
當兩個或兩個以上的 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
