專案開發中遇到一個錯誤 “**fatal error: concurrent map read and map write**”。
 
有過一兩年 Golang 開發經驗的同學應該都不陌生，這是 Golang 內建的 map **併發非安全** 導致的。

解決辦法也不復雜 --- 用 **sync.map** 代替了內建的 map 。
```go
//初始化，多維度資料分開
s.pmap = new(sync.Map)
s.tmap = new(sync.Map)
s.bmap = new(sync.Map)
……
//儲存資料，資料型別比較靈活
for _, param := range *** {
    s.pmap.Store(param.Name, param)
    if param.Type == *** {
        s.tmap.Store(param.ID, ***)
    } else {
        s.bmap.Store(param.ID, ***)
    }
}
……
//獲取資料
data, ok := s.pmap.Load(name) 
 ```
sync.map 包是 Golang 1.9 之後官方支援的併發安全的 map 包，之所以放在 sync 包裡，是因為 sync 包裡包含了 Golang 語言的絕大部分同步原語，它是 Golang 併發程式設計中佔據重要地位的一個包。

其實 Golang1.9 之前這個問題的解決辦法是給內建的 map 加鎖 sync.RWMutex 等，也在 sync 包裡。

Golang 語言作為一個原生支援使用者態程式（Goroutine）的語言，當提到併發程式設計都離不開鎖。鎖是一種併發程式設計中的同步原語（Synchronization Primitives），它能保證多個 Goroutine 在訪問同一片記憶體時不會出現競爭或同時寫導致的各種不一致混亂及異常等問題。

我們從 sync 包的原始碼目錄結構可以看出，sync 包主要提供了 **Mutex、RWmutex、WaitGroup、Map、Once、Cond、Pool、PoolQueue**等同步原語。

![](media/16540453248322/16540455063172.jpg)

下面我們會逐個分析其作用及使用注意事項（選用了一些 Golang 經典面試題中常見的一些錯誤），我們集中看使用場景比較多的幾個。

sync 包中還有個 **atomic** 目錄，是 Golang 提供一些的底層的原子操作，不是我們今天討論的內容，感興趣的同學可以自行檢視原始碼。

### 一、Sync.Mutex

Sync.Mutex 互斥鎖，它用來保證在任一時刻，只能有一個 Goroutine 訪問共享資源，即互斥訪問。

互斥鎖提供兩個方法，**加鎖 Lock（）和 解鎖 Unlock（）**。

sync.Mutex 初始值為 Unlock 狀態，並且 sync.Mutex 常做為其它結構體的匿名變數使用。
```go
// A Mutex is a mutual exclusion lock.
// The zero value for a Mutex is an unlocked mutex.
//
// A Mutex must not be copied after first use.
type Mutex struct {
 state int32
 sema  uint32
}

// A Locker represents an object that can be locked and unlocked.
type Locker interface {
 Lock()
 Unlock()
}

……

func (m *Mutex) Lock()     //鎖住 m，如果 m 已經被加鎖，Lock 將會引發 panic；
func (m *Mutex) Unlock()   //解鎖 m，如果 m 未加鎖，Unlock 也會引發 panic，unlock of unlocked mutex；
```

**1.資源有鎖時必須先解鎖後才能再加鎖，資源沒鎖時必須先加鎖才能解鎖。**

看下面這段程式碼
```go
var mu sync.Mutex 
var chain string
func main() {
    chain = "main"
    A() 
    fmt.Println(chain)
}
func A() {
    mu.Lock()    //mu.Unlock
    defer mu.Unlock()
    chain = chain + " --> A" 
    B()
}
func B() {
    chain = chain + " --> B"
    C() 
}
func C() {
    mu.Lock()
    defer mu.Unlock()
    chain = chain + " --> C"
}
……
fatal error: all goroutines are asleep - deadlock!

goroutine 1 [semacquire]:
sync.runtime_SemacquireMutex(0x514b7c)
 /usr/lib/golang/src/runtime/sema.go:62 +0x34
sync.(*Mutex).Lock(0x514b78)
 /usr/lib/golang/src/sync/mutex.go:87 +0x9d
main.C()

如果將函式 A 中 mu.Lock 改為 mu.Unlock()

fatal error: sync: unlock of unlocked mutex

goroutine 1 [running]:
runtime.throw(0x4a8a4c, 0x1e)
 /usr/lib/golang/src/runtime/panic.go:596 +0x95 fp=0xc42005dea8 sp=0xc42005de88
sync.throw(0x4a8a4c, 0x1e)
 /usr/lib/golang/src/runtime/panic.go:585 +0x35 fp=0xc42005dec8 sp=0xc42005dea8
sync.(*Mutex).Unlock(0x514b78)
 /usr/lib/golang/src/sync/mutex.go:113 +0xa4 fp=0xc42005def0 sp=0xc42005dec8
main.A()
```
函式 A 執行時先對 mu 加了鎖，而後進入函式 B ，函式 B 又進入函式 C，整個過程中並未對 mu 進行解鎖，這時又對 mu 進行加鎖是不行的。

使用 Lock() 加鎖後，不能再繼續對其加鎖，直到利用 Unlock() 解鎖後才能再加鎖。

同理，未加鎖時直接在函式 A 中對 mu 進行解鎖也是不行的，必須是先加所再解鎖成對出現的。

**2.sync.Mutex 最好透過指標進行傳遞。（sync包的所有同步原語都一樣）**

看下面一段程式碼
```go
type data struct { 
 mu sync.Mutex
}
func (d data) test(s string) { 
 fmt.Printf("mu address %p \n",&(d.mu))
 d.mu.Lock()
 defer d.mu.Unlock()
 for i:=0;i<5 ;i++ { 
  fmt.Println(s,i) 
  time.Sleep(time.Second)
 } 
}
func main() {
    var wg sync.WaitGroup 
 wg.Add(2)
 var d data
 go func() {
     defer wg.Done() 
  d.test("read")
 }()
 go func() {
  defer wg.Done() 
  d.test("write")
 }()
    wg.Wait() 
}
……
mu address 0xc42000e1f8    //鎖的地址不一樣了，所以鎖機制失效了。本意是要透過同一把鎖來對共享資源進行控制的。
write 0
mu address 0xc42009e000 
read 0
read 1
write 1
write 2
read 2
read 3
write 3
write 4
read 4
```
sync.Mutex 透過函式引數傳遞或者 struct 結構體中值傳遞時是值傳遞，會複製一個副本出來，可以看上面例子中的兩個鎖的地址是完全不同的。

所以本意透過同一把鎖來對共享資源進行控制的時候透過值傳遞複製一個新的鎖出來就達不到想要的效果，鎖失效。

所以傳遞 Mutex 時，必須用指標進行傳遞，或者相關的方法必須使用指標接收者。
```go
type data struct { 
 *mu sync.Mutex    //使用前記得初始化  data{new(sync.Mutex)}
}
或者
func (d *data) test(s string) {  //指標接收者
}
```
**3.在第一次被使用後，不能再對sync.Mutex進行復制（sync包的所有原語都一樣）。**

```go
type MyMutex struct { 
 count int 
 sync.Mutex
}
func main() {
 var mu MyMutex
 mu.Lock()
 var mu1 = mu    //加鎖後複製了一個新的Mutex出來，此時 mu1 跟 mu的鎖狀態一致，都是加鎖的狀態
 mu.count++
 mu.Unlock()
 mu1.Lock()
 mu1.count++
 mu1.Unlock() 
 fmt.Println(mu.count, mu1.count)
}
……
fatal error: all goroutines are asleep - deadlock!
```
複製會連帶 Mutex 的狀態一起復制，所以 mu1 其實跟複製時 mu 的狀態一樣，已經是加鎖狀態，下面再加鎖就會死鎖。

### 二、Sync.RWMutex

sync.RWMutex 是一個讀寫互斥鎖，它是為了保證多個 Goroutine 可以同時讀取某一個共享資源，但只有一個 Goroutine 能夠更新資源，也就是說可以同時讀，不能同時寫，也不能同時讀寫，即**讀和寫是互斥的，寫和寫也是互斥的，讀和讀是不互斥的**。

它主要用於讀多寫少的場景，支援 Lock、Unlock、RLock、RUnlock 四個方法,除了“寫鎖定”和“寫解鎖”狀態外，多了一個“讀鎖定”和“讀解鎖“。
```go
func (rw *RWMutex) Lock()     //寫鎖定 rw，禁止其他 Goroutine 讀取和寫入。如果 rw 已經被寫鎖定，仍然需要先解鎖才可以再次鎖定
func (rw *RWMutex) Unlock()   //寫解鎖 rw，如果 rw 未被寫鎖定，Unlock 也會引發 panic；
func (rw *RWMutex) RLock()     //讀鎖定 rw，如果 rw 已經被讀鎖定，禁止其他 Goroutine 寫入，但可以讀取；讀鎖可以連續鎖定，不一定非要先解讀鎖再鎖定，因為讀和讀是不互斥的。
func (rw *RWMutex) RUnlock()   //讀解鎖 rw，如果 rw 未被讀鎖定，RUnlock 會引發 panic；
```
這裡體現了不同，**sync.RWMutex 允許至少一個讀鎖或一個寫鎖存在，即可以有多個讀鎖。** 而 sync.Mutex 只允許一個讀鎖或一個寫鎖存在。

看下面這段程式碼
```go
var mu sync.RWMutex
var count int

func main() {
    go A()
    time.Sleep(2 * time.Second)
    mu.Lock()
    defer mu.Unlock()
    count++
    fmt.Println(count)
}
func A() {
    fmt.Println("enter A")
    mu.RLock()
    fmt.Println("A after RLock")
    defer mu.RUnlock()
    B()
}
func B() {
    fmt.Println("enter B")
    time.Sleep(5 * time.Second)
    C()
}
func C() {
    fmt.Println("enter C")
    mu.RLock()  //main中 mu.Lock 寫鎖定了，這裡就死鎖了。
    defer mu.RUnlock()
}
……
enter A
A after RLock
enter B
enter C
fatal error: all goroutines are asleep - deadlock!
```
RWMutex 為了有效防止寫鎖飢餓，**當寫鎖阻塞時，新的讀鎖是無法申請的**，main 函式中進行了寫鎖定，且用了 defer 要到 main 函式執行完時才會解鎖，此時 A 協程執行到 C 時重新申請讀鎖定是不允許的，導致整個程式死鎖。

注意程式碼中有兩行 time 控制，是為了保證 main 和 子協程執行的時機的，方便控制鎖的先後時機。感興趣的同學可以自行註釋掉或者調整 Sleep 的時間試驗下。

### 三、Sync.WaitGroup

sync.WaitGroup 組等待，它的使用場景是等待一組 Goroutine 執行完成。

其內部擁有一個計數器，每個 Goroutine 啟動時加 1，執行結束時減 1，主程式透過檢測計數器來判斷整組 Goroutine 是否執行完畢。

我們使用sync.WaitGroup 時主要用到Add、Done、Wait 三個方法。
```go
// A WaitGroup waits for a collection of goroutines to finish.
// The main goroutine calls Add to set the number of
// goroutines to wait for. Then each of the goroutines
// runs and calls Done when finished. At the same time,
// Wait can be used to block until all goroutines have finished.
//
// A WaitGroup must not be copied after first use.
type WaitGroup struct {
 noCopy noCopy  //第一次使用後不可複製

// 64-bit value: high 32 bits are counter, low 32 bits are waiter count.
 // 64-bit atomic operations require 64-bit alignment, but 32-bit
 // compilers do not ensure it. So we allocate 12 bytes and then use
 // the aligned 8 bytes in them as state, and the other 4 as storage
 // for the sema.
 state1 [3]uint32  
}
func (wg *WaitGroup) Add(delta int) //整組任務開始時按照任務數量設定計數器值，或者在每個 Goroutine 中單獨加1也可以；
func (wg *WaitGroup) Done()  //Goroutine 執行完成，即完成其中一個任務，計數器減1；
func (wg *WaitGroup) Wait()： //主程式等待，直到計數器歸零。如果計數器小於 0，則該操作會引發 panic。
```
看下面一段程式碼
```go
func main() {
    var wg sync.WaitGroup 
 wg.Add(1)
 go func() {
     fmt.Println("1") 
  wg.Done() 
  wg.Add(1)
 }()
    wg.Wait() 
}
……
1
panic: sync: WaitGroup is reused before previous Wait has returned
```
main 中設定了整組任務只有一個，然後在 Goroutine 中進行了 Done 操作，這時主程式中 wait 判斷計數器清零了就返回了，這時對已經返回的 WaitGroup 再次設定 Add 導致 panic。
```go
func main() {
    var wg sync.WaitGroup
    ch := make(chan int, 10)
    for i := 0; i < 10; i++ {
        wg.Add(1)
        go getData(i, wg, ch)
    }
    wg.Wait()
    fmt.Println("all done")
    for i := 0; i < 10; i++ {
        counter :=

從專案的一個 panic 說起：Go 中 Sync 包的分析應用

相關文章