16 Go并发编程（三）：死锁 —— Go并发编程的陷阱

协程死锁

学完Go的协程与通道，我们已经对Go的并发编程有大概的了解，可以说go的并发程序还是很容易编写的，只要深刻理解go的协程和通道设计，日常使用不会出现很大问题。但凡事都有些许例外情况，就像你去登山越野，即使你手中有路线图，但现实环境还是有出入的，你还是有可能踩到陷阱。Go的并发编程有些情况会造成死锁导致程序退出。

所谓死锁，Go运行时报错有个有趣的说法：

fatal error：all goroutines are asleep-deadlock —— 所有的协程都在睡觉，可以理解为所有的协程都在等待资源

下面演示几种造成死锁的情况：

1.自我阻塞

一个没有缓存的管道必须有另一个协程的读取才能写入，否则当前协程永远都在等待写入管道。

/*自己阻塞自己*/
func BaseDeadlock01() {
    //申请一个没有缓存的管道
    ch := make(chan int, 0)
    ch <- 123
    x := <-ch //零缓存的管道，有写必须由另一个协程读，否则死锁
    fmt.Println(x)
}

2.协程开迟了

一个屋缓存的管道，必须先开启另一个协程才能写入，否则协程等同于没开——死锁。

/*协程开晚了*/
func Baseeadlock02() {
    ch := make(chan int)
    
    //数据应在协程开开启后才写入
    ch <- 123
    
    go func() {
        x := <-ch
        fmt.Println(x)
    }()
}

3.互抢资源

管道读写时,相互要求对方先读/写,自己在写/读,造成死锁

//演示一个钱货交易的例子
func BaseDeadlock03() {
    //无缓存的钱包通道
    chMoney := make(chan int)
    //无缓存的货物通道
    chGoods := make(chan int)
    
    //商户子协程：先给钱再发货！
    go func() {
        for {
            select {
            case <-chMoney:
                fmt.Println("先给钱再给货！！！")
                chGoods <- 100
            }
        }

    }()
    
    //客户主协程：先发货再给钱
    for {
        select {
        case <-chGoods:
            fmt.Println("先发货再给钱！！！")
            chMoney <- 100
        }
    }

}

4.隐性死锁

有些情况是子协程直接互相等待各自需要的资源，主协程没有发现而导致隐性死锁，这类死锁运行时不会报错退出，但会直接卡死其中的两个子协程，占用系统资源

/*读写锁定相互阻塞,形成隐形死锁*/
func BaseDeadlock04() {

    //无缓存的钱包通道
    chMoney := make(chan int)
    //无缓存的货物通道
    chGoods := make(chan int)
    
    //商户子协程：先给钱再发货！
    go func() {
        for {
            select {
            case <-chMoney:
                fmt.Println("先给钱再给货！！！")
                chGoods <- 100
            }
        }

    }()
    ∂
    //客户主协程：先发货再给钱
    go func() {
        for {
            select {
            case <-chGoods:
                fmt.Println("先发货再给钱！！！")
                chMoney <- 100
            }
        }
    }()
    
    //主协程并不知道其调用的两个子协程在互抢各自都不释放的资源
    for {
        time.Sleep(time.Second)
        runtime.GC() //通知垃圾回收器清理吧
    }

}