关于go:golang中的锁竞争问题

索引：https://www.waterflow.link/articles/1666884810643

当咱们打印谬误的时候应用锁可能会带来意想不到的后果。

咱们看上面的例子：

package mainimport (    "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}// 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    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

咱们再看一个切片的例子：

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，所以底层会复制一个新的数组；同样另一个协程也是如此。

go  run -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加了一个足够大的容量

go  run -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 {    mu       sync.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 { // 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)}

1. 咱们有一个用户的机构，外面有个online字段是一个map，外面保留了在线的用户信息
2. 咱们有一个增加在线用户的办法AddOnline，办法外面应用了锁，是因为map是并发不平安的
3. 咱们还有一个统计所有在线用户的办法AllOnline
4. 在AllOnline中，咱们拜访u.online的map，咱们加上了读锁。这里的想法是拜访以后在线用户的map，并赋值给online，而后开释读锁
5. 遍历赋值的online查出在线用户的数量

可能咱们感觉这个是没问题的，然而当咱们运行程序的时候会发现这里存在数据竞争：

go  run -race 10.go==================WARNING: DATA RACEWrite 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 mainimport (    "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 RACERead at 0x00c00011e060 by goroutine 7:  main.User.AllOnline()

这个又是什么起因造成的呢？这是因为，当我门应用User作为参数时，间接复制了User的正本，因而sync.RWMutex也会被复制。

因为锁被复制了，所以对于同一个临界资源，处于不同锁的读写操作能够同时拜访。