golang中的鎖競爭問題

slowquery發表於2022-10-27

索引：www.waterflow.link/articles/166688...

當我們列印錯誤的時候使用鎖可能會帶來意想不到的結果。

我們看下面的例子：

package main

import (
    "fmt"
    "sync"
)

type Courseware struct {
    mutex sync.RWMutex
    Id    int64
    Code   string
    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
}

// 3
func (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))
}

上面的程式碼看起來貌似沒有什麼問題，但是卻會導致死鎖：

更新課件時長的時候上鎖，避免出現資料競爭
判斷如果時長小於60秒的話，就報錯。但是注意這裡fmt.Errorf列印結構c會呼叫String()方法
我們看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 main

import (
    "fmt"
    "sync"
)

type Courseware struct {
    mutex sync.RWMutex
    Id    int64
    Code   string
    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))
}

go run 10.go
課件時長必須大於等於60秒： 0， id: 0


我們再看一個切片的例子：

```go
package main

import (
    "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，所以底層會複製一個新的陣列；同樣另一個協程也是如此。

go  run -race 10.go
[0 1]
[0 1]

注意：這裡的關鍵就是，兩個協程是否會同時訪問一個記憶體空間，這時導致資料競爭的關鍵。

我們稍微修改下上面的例子：

package main

import (
    "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)
    }()
}

我們給s加了一個足夠大的容量

go  run -race 10.go
[0 1]
==================
WARNING: DATA RACE
Write at 0x00c0000c0008 by goroutine 8:
  main.main.func2()
...

可以看到這就產生了資料競爭的問題。因為s的容量足夠大，所以兩個協程有可能操作同一個底層陣列的同一塊記憶體。

解決辦法也很簡單，重新copy一個s就行了。

下面我們繼續看一個map的例子：

package main

import (
    "strconv"
    "sync"
    "time"
)

// 1
type User struct {
    mu       sync.RWMutex
    online map[string]bool
}

// 2
func (u *User) AddOnline(id string) {
    u.mu.Lock()
    u.online[id] = true
    u.mu.Unlock()
}

// 3
func (u *User) AllOnline() int {
    u.mu.RLock()
    online := u.online // 4
    u.mu.RUnlock()

    sum := 0
    for _, o := range online { // 5
        if 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)
}

我們有一個使用者的機構，裡面有個online欄位是一個map，裡面儲存了線上的使用者資訊
我們有一個新增線上使用者的方法AddOnline，方法裡面使用了鎖，是因為map是併發不安全的
我們還有一個統計所有線上使用者的方法AllOnline
在AllOnline中，我們訪問u.online的map，我們加上了讀鎖。這裡的想法是訪問當前線上使用者的map，並賦值給online，然後釋放讀鎖
遍歷賦值的online查出線上使用者的數量

可能我們覺得這個是沒問題的，但是當我們執行程式的時候會發現這裡存在資料競爭：

go  run -race 10.go
==================
WARNING: DATA RACE
Write at 0x00c0000a0060 by goroutine 6:
  runtime.mapassign_faststr()

...

==================
fatal error: concurrent map iteration and map write

這是因為，在map內部，是hmap結構，主要包含後設資料（例如，計數器）和引用資料桶的指標。因此，online := u.online 不會複製實際資料，而是複製的指標，實際操作的還是同一片記憶體。

解決這個問題也不難：

我們可以把鎖的範圍擴大，像下面這樣：

func (u *User) AllOnline() int {
    u.mu.RLock()
    defer u.mu.RUnlock()
    online := u.online

    sum := 0
    for _, o := range online {
        if o {
            sum++
        }
    }
    return sum
}

另一種方法就是複製一個副本出來，像上面我們說的切片一樣：

func (u *User) AllOnline() int {
    u.mu.RLock()
    online := make(map[string]bool, len(u.online))
    for s, b := range u.online {
        online[s] = b
    }
    u.mu.RUnlock()

    sum := 0
    for _, o := range online {
        if o {
            sum++
        }
    }
    return sum
}

上面的例子中我們使用了*User定義了2個方法：

func (u *User) AddOnline(id string) {
    u.mu.Lock()
    u.online[id] = true
    u.mu.Unlock()
}

func (u *User) AllOnline() int {
    u.mu.RLock()
    online := make(map[string]bool, len(u.online))
    for s, b := range u.online {
        online[s] = b
    }
    u.mu.RUnlock()

    sum := 0
    for _, o := range online {
        if o {
            sum++
        }
    }
    return sum
}

我現在我們稍微修改下上面的列子：

package main

import (
    "strconv"
    "sync"
    "time"
)

type User struct {
    mu       sync.RWMutex
    online map[string]bool
}

func (u User) AddOnline(id string) {
    u.mu.Lock()
    u.online[id] = true
    u.mu.Unlock()
}

func (u User) AllOnline() int {
    u.mu.RLock()
    online := make(map[string]bool, len(u.online))
    for s, b := range u.online {
        online[s] = b
    }
    u.mu.RUnlock()

    sum := 0
    for _, o := range online {
        if 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)
}

現在我們直接使用User結構體定義這兩個方法，但是當我們執行程式的時候，報了資料競爭的錯誤：

go  run -race 10.go
==================
WARNING: DATA RACE
Read at 0x00c00011e060 by goroutine 7:
  main.User.AllOnline()

這個又是什麼原因造成的呢？這是因為，當我門使用User作為引數時，直接複製了User的副本，因此sync.RWMutex也會被複制。

因為鎖被複制了，所以對於同一個臨界資源，處於不同鎖的讀寫操作可以同時訪問。

本作品採用《CC 協議》，轉載必須註明作者和本文連結

【Golang】淺談協程併發競爭資源問題
2022-01-04
Golang
多執行緒程式設計的鎖問題解析（鎖競爭死鎖活鎖及Date Race等）
2017-01-05
執行緒程式設計
Oracle鎖競爭和管理 CUUG
2014-01-08
Oracle
wait和notify在鎖競爭中的執行順序
2015-12-28
AI
輕鬆檢測Golang併發的資料競爭
2019-02-16
Golang
【go】golang中鎖的用法-互斥鎖
2024-04-10
Golang
AQS原始碼探究之競爭鎖資源
2022-05-12
AQS原始碼
一個測試記錄：利用分段鎖來處理併發情況下的資源競爭問題
2022-05-22
用深度學習解決競爭性編碼問題 | DeepMind
2022-02-04
深度學習
MySQL中鎖的相關問題DTQU
2022-03-01
MySql
GOLANG中time.After釋放的問題
2017-07-29
Golang
主題公園的核心競爭力是什麼？
2022-05-17
java中synchronized鎖定物件問題
2016-03-14
Javasynchronized物件
分析現代體育遊戲中的競爭狀況
2012-12-09
遊戲
能幫你解決90%以上Java面試中的鎖問題（Java中的鎖）
2020-10-26
Java面試
在 Python 中測試競爭條件
2015-04-15
Python
人工智慧時代的競爭
2020-02-23
人工智慧
競爭性需求分析
2015-05-24
微軟在與蘋果的長期競爭中，再次領先
2024-04-15
微軟蘋果
oracle 解鎖的問題
2009-03-02
Oracle
MySQL實際應用中遇到的鎖問題薦
2013-12-18
MySql
解決SQL Server 2005中鎖的問題
2009-07-16
SQLServer
golang url解析問題
2016-10-12
Golang
阿里遊戲的競爭力不在阿里
2021-01-06
阿里遊戲
網際網路商業競爭中的“狼”與“羊”薦
2010-11-15
RAC 鎖管理與鎖問題的定位(二）
2012-03-28
RAC 鎖管理與鎖問題的定位（一）
2012-05-23
golang中關於死鎖的思考與學習
2023-03-18
Golang
BP-Wrapper：無鎖競爭的快取替換演算法系統框架
2021-06-13
APP快取演算法框架
golang中切片slice的引用問題
2017-09-26
Golang
測試MySQL鎖的問題
2021-06-24
MySql
oracle 鎖問題的解決
2011-08-25
Oracle
sql server死鎖的問題
2005-06-22
SQLServer
優質投資的特徵與競爭力
2020-05-30
特徵
多執行緒之間的競爭
2015-03-29
執行緒
大資料：國家競爭的前沿
2013-09-16
大資料
談談如何在面試中發掘程式猿的核心競爭力
2014-12-26
面試
2020年夏天就業競爭越發激烈，如何迅速提高自己的競爭力？
2020-07-23
就業

golang中的鎖競爭問題

相關文章