1.sync.Mutex

在Go语言的sync包中，sync.Mutex是不可重入的互斥锁。这与Java可重入锁改变不同。

也就是说,当一个goroutine获得了Mutex的锁后，在释放锁之前它不能再次获取同一个Mutex。

2.sync.RWMutex

写锁重入导致死锁：

var lock sync.RWMutex

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

结果：fatal error: all goroutines are asleep - deadlock!

读锁写锁重入死锁

var lock sync.RWMutex

func test2() {
    lock.RLock()
    lock.Lock()
    lock.Unlock()
    lock.RUnlock()
}
func main() {
    //读写锁重入死锁
    test2()
}

输出结果：
fatal error: all goroutines are asleep - deadlock!

写锁对重入的读锁的影响，可能会出现死锁，当有写锁申请时会阻塞掉新的读锁申请，也就是说当同时有读锁和写锁同时申请获得同一个锁对象时，优先写锁获取（即写锁优先）。

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()
}

输出：fatal error: all goroutines are asleep - deadlock!

3.channel相关的死锁

同一个协程读写死锁：

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

    ch <- 3
    result := <-ch
    fmt.Println(result)
}

输出：fatal error: all goroutines are asleep - deadlock!

缓存为0 channel读取在后面导致死锁
一句话总结：无缓存的channel只有在receiver准备好后send才被执行。

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

输出：fatal error: all goroutines are asleep - deadlock!

读取协程放在前面就不会死锁：

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

输出：8

chan读写时，相互要求对方先读或者先写

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?"
    }
}

输出：fatal error: all goroutines are asleep - deadlock!

4.死锁发生的条件

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

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

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

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

参考

• https://blog.csdn.net/mingtiannihaoabc/article/details/125530573