Go并发同步Mutex典型易错使用场景
目录
- 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:
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 Vet指令
我们当然不想程序运行了才发现死锁,我们可以通过go vet指令来在运行前检查我们的代码是否存在lock copy问题:
检查原理
检查是通过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方法中尝试再次获取锁时,获取不到,触发了死锁。
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:
解决策略
1.可以引入一个第三方的锁,大家都依赖这个锁进行业务处理,比如现在政府推行的一站式政务服务中心。
2.解决持有等待问题,比如社区不需要看到网签中心的证明才给开居住证明。
以上就是Go并发同步Mutex典型易错使用场景的详细内容,更多关于Go Mutex易错场景的资料请关注我们其它相关文章!