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 占用的资源，形成了一个环形链。

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