1. 首頁 > 生活百科 > >

golang中的鎖競爭問題

生活百科

索引：https://www.waterflow.link/articles/1666884810643
當我們打印錯誤的時候使用鎖可能會帶來意想不到的結果 。
我們看下面的例子：
package mainimport ( "fmt" "sync")type Courseware struct { mutex sync.RWMutex Idint64 Codestring Duration int}func (c *Courseware) UpdateDuration(duration int) error { c.mutex.Lock() // 1 defer c.mutex.Unlock() if duration < 60 {return fmt.Errorf("課件時長必須大于等于60秒： %v", c) // 2 } c.Duration = duration return nil}// 3func (c *Courseware) String() string { c.mutex.RLock() defer c.mutex.RUnlock() return fmt.Sprintf("id %d, duration %d", c.Id, c.Duration)}func main() { c := &Courseware{} fmt.Println(c.UpdateDuration(0))}上面的代碼看起來貌似沒有什么問題，但是卻會導致死鎖：

  1. 更新課件時長的時候上鎖，避免出現數據競爭
  2. 判斷如果時長小于60秒的話，就報錯 。但是注意這里fmt.Errorf打印結構c會調用String()方法
  3. 我們看String方法里面，又使用了讀鎖，避免讀取的時候數據被更新
因為對臨界資源重復上鎖，所以導致了死鎖的問題 。解決辦法也很簡單：
  • 把鎖放到錯誤判斷之后：
    func (c *Courseware) UpdateDuration(duration int) error { if duration < 60 {return fmt.Errorf("課件時長必須大于等于60秒： %v", c) // 2 }c.mutex.Lock() defer c.mutex.Unlock() c.Duration = duration return nil}
  • 不使用String方法，避免重復上鎖：
    package mainimport ( "fmt" "sync")type Courseware struct { mutex sync.RWMutex Idint64 Codestring Duration int}func (c *Courseware) UpdateDuration(duration int) error { c.mutex.Lock() defer c.mutex.Unlock() if duration < 60 {return fmt.Errorf("課件時長必須大于等于60秒： %d，id: %d", c.Duration, c.Id) // 打印放在一個鎖里面也能保證安全 } c.Duration = duration return nil}func main() { c := &Courseware{} fmt.Println(c.UpdateDuration(0))}gorun10.go課件時長必須大于等于60秒： 0 ，  id: 0
我們再看一個切片的例子：
package mainimport ( "fmt")func main() { s := make([]int, 1) go func() {s1 := append(s, 1)fmt.Println(s1) }() go func() {s2 := append(s, 1)fmt.Println(s2) }()}我們初始化了一個長度為1，容量為1的切片 ， 然后分別在2個協程里面調用append往切片追加元素 。這種情況會導致數據競爭么？
答案是不會 。在其中一個協程里面，當我們append元素的時候，因為s的容量為1，所以底層會復制一個新的數組；同樣另一個協程也是如此 。
gorun -race 10.go[0 1][0 1]注意：這里的關鍵就是，兩個協程是否會同時訪問一個內存空間，這時導致數據競爭的關鍵 。
我們稍微修改下上面的例子：
package mainimport ( "fmt")func main() { s := make([]int, 1, 10) // 1 go func() {s1 := append(s, 1)fmt.Println(s1) }() go func() {s2 := append(s, 1)fmt.Println(s2) }()}
  1. 我們給s加了一個足夠大的容量
gorun -race 10.go[0 1]==================WARNING: DATA RACEWrite at 0x00c0000c0008 by goroutine 8:main.main.func2()...可以看到這就產生了數據競爭的問題 。因為s的容量足夠大，所以兩個協程有可能操作同一個底層數組的同一塊內存 。
解決辦法也很簡單，重新copy一個s就行了 。
下面我們繼續看一個map的例子：
package mainimport ( "strconv" "sync" "time")// 1type User struct { musync.RWMutex online map[string]bool}// 2func (u *User) AddOnline(id string) { u.mu.Lock() u.online[id] = true u.mu.Unlock()}// 3func (u *User) AllOnline() int { u.mu.RLock() online := u.online // 4 u.mu.RUnlock() sum := 0 for _, o := range online { // 5if o {sum++} } return sum}func main() { u := &User{} u.online = make(map[string]bool) go func() {for i := 0; i < 10000; i++ {u.AddOnline("userid" + strconv.Itoa(i))} }() go func() {for i := 0; i < 10000; i++ {u.AllOnline()} }() time.Sleep(time.Second)}
  1. 我們有一個用戶的機構 ， 里面有個online字段是一個map，里面保存了在線的用戶信息
  2. 我們有一個添加在線用戶的方法AddOnline，方法里面使用了鎖，是因為map是并發不安全的
  3. 我們還有一個統計所有在線用戶的方法AllOnline
  4. 在AllOnline中，我們訪問u.online的map ， 我們加上了讀鎖 。這里的想法是訪問當前在線用戶的map，并賦值給online，然后釋放讀鎖
  5. 遍歷賦值的online查出在線用戶的數量
可能我們覺得這個是沒問題的 ， 但是當我們運行程序的時候會發現這里存在數據競爭：
gorun -race 10.go==================WARNING: DATA RACEWrite at 0x00c0000a0060 by goroutine 6:runtime.mapassign_faststr()...==================fatal error: concurrent map iteration and map write

推薦閱讀