• 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也会被复制。

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

  • 相关阅读:
    数字孪生:物流数据可视化
    FastAdmin框架实现数据表的增删改查
    页面路由跳转 - 文件 File对象数据传递
    java毕业设计技术的装潢公司网站开发(附源码、数据库)
    微服务的灰度发布就该这样设计
    BigDecimal简单介绍
    Git分布式版本控制工具
    swagger
    系统平台搭建细节
    基于python的AI五子棋实现(极大极小值搜索和alpha beta剪枝)
  • 原文地址:https://www.cnblogs.com/liuyuede123/p/16834425.html