golang中的锁竞争问题

索引: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也会被复制。

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

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 218,546评论 6 507
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 93,224评论 3 395
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 164,911评论 0 354
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,737评论 1 294
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,753评论 6 392
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,598评论 1 305
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,338评论 3 418
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 39,249评论 0 276
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,696评论 1 314
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,888评论 3 336
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 40,013评论 1 348
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,731评论 5 346
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,348评论 3 330
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,929评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 33,048评论 1 270
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 48,203评论 3 370
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,960评论 2 355

推荐阅读更多精彩内容