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

28次阅读

共计 4433 个字符,预计需要花费 12 分钟才能阅读完成。

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

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

咱们看上面的例子:

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))
}

下面的代码看起来貌似没有什么问题,然而却会导致死锁:

  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 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

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

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)
    }()}
  1. 咱们给 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)
}
  1. 咱们有一个用户的机构,外面有个 online 字段是一个 map,外面保留了在线的用户信息
  2. 咱们有一个增加在线用户的办法 AddOnline,办法外面应用了锁,是因为 map 是并发不平安的
  3. 咱们还有一个统计所有在线用户的办法 AllOnline
  4. 在 AllOnline 中,咱们拜访 u.online 的 map,咱们加上了读锁。这里的想法是拜访以后在线用户的 map,并赋值给 online,而后开释读锁
  5. 遍历赋值的 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 也会被复制。

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

正文完
 0