Golang死锁场景总结

sync.Mutex、sync.RWMutex相关的死锁

1.读写锁RWMutex相关场景

都知道golang的读写锁中,只要读锁和读锁之间是不互斥的,写和读、写和写锁之间是互斥的,由于golang中是不支持锁的重入的(有的地方也叫做递归锁)

a.写锁与写锁、读写锁的重入导致死锁

写锁重入导致死锁

package main

import "sync"

var lock sync.RWMutex
func test1(){
	lock.Lock()
	lock.Lock()
	lock.Unlock()
	lock.Unlock()
}
func main(){
	//写锁重入死锁
	test1()
}

读写锁冲入导致死锁

package main

import "sync"

var lock sync.RWMutex
func test2(){
	lock.RLock()
	lock.Lock()
	lock.Unlock()
	lock.RUnlock()
}
func main(){
	//读写锁重入死锁
	test2()
}
b.需要注意的点,虽然读与读锁之间是不需要互斥的,但是,当两个读锁重入的时候,需要考虑对应锁对象的写锁是否会影响读锁的重入从而导致死锁

例如单独的两个读锁,他们这样是不会死锁的

package main

import "sync"
func test3()  {
	lock.RLock()
	lock.RLock()
	lock.RUnlock()
	lock.RUnlock()
}
func main(){
	test3()
}

但是需要注意写锁对重入的读锁的影响,可能会出现死锁,当有写锁申请时会阻塞掉新的读锁申请,也就是说当同时有读锁和写锁同时申请获得同一个锁对象时,优先写锁获取(即写锁优先)

package main

import (
	"sync"
	"time"
)

var lock sync.RWMutex

func main() {
	go func() {
		ReadRLock()
	}()
	//sleep 1秒后,ReadRLock正处于第二次获取锁的时机和WriteLock同时也在等ReadLock释放第一次获取的读锁,
	//二者竞争,写锁优先,导致ReadLock第二次获取读锁失败
	time.Sleep(time.Second)
	WriteLock()
}

func ReadRLock() {
	lock.RLock()
	defer lock.RUnlock()
	time.Sleep(time.Second * 2)
	lock.RLock()
	defer lock.RUnlock()
}


func WriteLock() {
	lock.Lock()
	defer lock.Unlock()
}

2.sync.Mutex互斥锁就不举例子了,只要不发生重入一般不会死锁,它和读写锁之间不会相互影响

下面这种是没问题的,不会发生死锁

package main

import (
	"sync"
)

var lock sync.Mutex
var lockRW sync.RWMutex
func main() {
	lock.Lock()
	lockRW.Lock()
	lockRW.Unlock()
	lock.Unlock()
}

通道相关操作的死锁

缓存为0的通道,导致的死锁

同一个协程读写

缓存为0的通道,没有人读,你也写不了,没有人写,你也读不了,这正是一种死锁!

func main() {
	ch := make(chan int, 0)

	ch <- 3
	result := <- ch
	fmt.Println(result)
}
读取通道协程来迟了

我们可以看到,这条协程开辟在将数字写入到通道之后,因为没有人读,通道就不能再继续写了,然后写入通道的操作就一直阻塞。可能疑惑不是开辟了一条协程在读吗?但是那条协程开辟在写入通道之后,如果不能写入通道,这个时候连协程都创建不了了。

package main

func main() {
	ch := make(chan int,0)
	ch <- 8
	go func() {
		result:=<- ch
		fmt.Println(result)
	}()
}

通道读写时,相互要求对方先读或者先写

package main

func main() {
	teacher := make(chan string, 0)
	student := make(chan string, 0)

	go func() {
		select {
		case <-teacher:
			student <- "yes,do over"
		}
	}()

	select {
	case <-student:
		teacher <- "HomeWork do over?"
	}
}

死锁触发的几个条件

  • 不可剥夺。线程已经获得的资源,在未使用完之前,不能被其他线程剥夺,只能在使用完后自己释放。

  • 请求保持。线程 T1 保持了一个资源 R1 占用,但是又提出另外一个资源 R2 请求,此时,资源 R2 被线程 T2 占用,于是 T1 线程必须等待,但又对自己保持的 R1 资源不释放。

  • 循环等待。死锁发生时,必然存在一个 “进程-资源环形链”,例如 进程p0 等待 p1 占用资源,p1 等待 p2 占用的资源, p2 等待 p0 占用的资源,形成了一个环形链。

  • 互斥。线程对资源访问是排斥的,如果一个线程占用了资源,那么其他线程必须处于等待状态,直到资源释放。

  • 0
    点赞
  • 5
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值