协程死锁
学完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() //通知垃圾回收器清理吧
}
}
