目录
  • Mutex的4种易错使用场景
    • 1.Lock/Unlock 不成对出现
    • 2.Copy 已使用的 Mutex
    • 3.重入
    • 4.死锁
  • 解决策略

    Mutex的4种易错使用场景

    1.Lock/Unlock 不成对出现

    Lock/Unlock 没有成对出现，就可能会出现死锁或者是因为Unlock一个未加锁的Mutex而导致 panic。

    忘记Unlock的情形

    • 代码中有太多的 if-else 分支，可能在某个分支中漏写了 Unlock；
    • 在重构的时候把 Unlock 给删除了；
    • Unlock 误写成了 Lock。

    忘记Lock的情形一般是误删除了或者注释掉了Lock。

    eg:

    func main() {
   var mu sync.Mutex
   defer mu.Unlock()
   fmt.Println("oh, missing Lock!")
}

    error result:

    Go并发同步Mutex典型易错使用场景

    2.Copy 已使用的 Mutex

    实际上sync包下的同步原语在使用后都是不可复制的，原因在于Mutex是有状态的，其state的值时刻在变化，如果复制一个已经加锁的Metux对象给一个新的变量，可能这个变量刚初始化就显示被加锁了，这显然是不合理的。

    eg:以下代码在调用 foo 函数的时候，调用者会复制 Mutex 变量 c 作为 foo 函数的参数，不幸的是，复制之前已经使用了这个锁，这就导致，复制的 Counter 是一个带状态 Counter，从而会导致死锁。

    type Counter struct {
   sync.Mutex
   Count int
}
func main() {
   var c Counter
   c.Lock()
   defer c.Unlock()
   c.Count++
   foo(c) // 复制锁
}
// 这里Counter的参数是通过复制的方式传入的
func foo(c Counter) {
   c.Lock()
   defer c.Unlock()
   fmt.Println("in foo")
}

    error result:还好有Go的协程死锁检查机制，程序运行后会快速失败而不是一直hang住。

    Go并发同步Mutex典型易错使用场景

    Go Vet指令

    我们当然不想程序运行了才发现死锁，我们可以通过go vet指令来在运行前检查我们的代码是否存在lock copy问题:

    Go并发同步Mutex典型易错使用场景

    检查原理

    检查是通过copylock分析器静态分析实现的。这个分析器会分析函数调用、range 遍历、复制、声明、函数返回值等位置，有没有锁的值 copy 的情景，以此来判断有没有问题。

    通过源码我们可以看到实现了Lock或者Unlock接口的struct都支持copylock检查。

    var lockerType *types.Interface
 // Construct a sync.Locker interface type.
 func init() {
     nullary := types.NewSignature(nil, nil, nil, false) // func()
     methods := []*types.Func{
     types.NewFunc(token.NoPos, nil, "Lock", nullary),
     types.NewFunc(token.NoPos, nil, "Unlock", nullary),
 }
 lockerType = types.NewInterface(methods, nil).Complete()
 }

    3.重入

    Mutex不像Java中的ReentrantLock拥有可重入的功能，主要是因为其实现中没有标记位记录哪个goroutine 拥有这把锁，所以Mutex是一个不可重入锁,而一旦误用Mutex的重入就会报错。

    eg:

    func foo(l sync.Locker) {
   fmt.Println("in foo")
   l.Lock()
   bar(l)
   l.Unlock()
}
func bar(l sync.Locker) {
   l.Lock()
   fmt.Println("in bar")
   l.Unlock()
}
func main() {
   l := &sync.Mutex{}
   foo(l)
}

    error result:我们可以看到当在bar方法中尝试再次获取锁时，获取不到，触发了死锁。

    Go并发同步Mutex典型易错使用场景

    4.死锁

    两个或两个以上的进程（或线程，goroutine）

    执行过程中，因争夺共享资源而处于一种互相等待的状态，如果没有外部干涉，它们都将无法推进下去，此时，我们称系统处于死锁状态或系统产生了死锁。

    死锁产生的4个必要条件

    如果想避免死锁，我们只要思考如何打破以下任意条件就可以。

    • 1.互斥： 至少一个资源是被排他性独享的，其他线程必须处于等待状态，直到资源被释放。
    • 2.持有和等待：goroutine 持有一个资源，并且还在请求其它 goroutine 持有的资源，也就是咱们常说的“吃着碗里，看着锅里”的意思。
    • 3. 不可剥夺：资源只能由持有它的 goroutine 来释放。
    • 4.环路等待：一般来说，存在一组等待进程，P={P1，P2，…，PN}，P1 等待 P2 持有的

    资源，P2 等待 P3 持有的资源，依此类推，最后是 PN 等待 P1 持有的资源，这就形成
    了一个环路等待的死结。

    eg:在这里我们以办理居住证业务，举一个简单的环路等待导致死锁的例子:

    //办理居住证
func main() {
   // 网签中心证明
   var psCertificate sync.Mutex
   // 社区证明
   var propertyCertificate sync.Mutex
   var wg sync.WaitGroup
   wg.Add(2) // 需要网签中心和社区都处理
   // 网签中心处理goroutine
   go func() {
      defer wg.Done() // 网签中心处理完成
      psCertificate.Lock()
      defer psCertificate.Unlock()
      // 检查材料
      time.Sleep(5 * time.Second)
      // 请求社区的证明
      propertyCertificate.Lock()
      propertyCertificate.Unlock()
   }()
   // 社区处理goroutine
   go func() {
      defer wg.Done() // 社区处理完成
      propertyCertificate.Lock()
      defer propertyCertificate.Unlock()
      // 检查材料
      time.Sleep(5 * time.Second)
      // 请求网签中心的证明
      psCertificate.Lock()
      psCertificate.Unlock()
   }()
   wg.Wait()
   fmt.Println("成功完成")
}

    error result:

    Go并发同步Mutex典型易错使用场景

    解决策略

    1.可以引入一个第三方的锁，大家都依赖这个锁进行业务处理，比如现在政府推行的一站式政务服务中心。

    2.解决持有等待问题，比如社区不需要看到网签中心的证明才给开居住证明。

    以上就是Go并发同步Mutex典型易错使用场景的详细内容，更多关于Go Mutex易错场景的资料请关注其它相关文章！

    声明：本站所有文章，如无特殊说明或标注，均为本站原创发布。任何个人或组织，在未征得本站同意时，禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益，可联系我们进行处理。