摘要：什么是死锁，在Go的协程外面死锁通常就是永恒阻塞了，你拿着我的货色，要我先给你而后再给我，我拿着你的货色又让你先给我，不然就不给你。我俩都这么想，这事就解决不了了。
本文分享自华为云社区《Golang并发操作中常见的死锁情景》，作者：Regan Yue 。
什么是死锁，在Go的协程外面死锁通常就是永恒阻塞了，你拿着我的货色，要我先给你而后再给我，我拿着你的货色又让你先给我，不然就不给你。我俩都这么想，这事就解决不了了。
第一种情景：无缓存能力的管道，本人写完本人读
先上代码：
func main() { ch := make(chan int, 0) ch <- 666 x := <- ch fmt.Println(x)}咱们能够看到这是一个没有缓存能力的管道，而后往里面写666，而后就去管道外面读。这样必定会呈现问题啊！一个无缓存能力的管道，没有人读，你也写不了，没有人写，你也读不了，这正是一种死锁！
fatal error: all goroutines are asleep - deadlock!解决办法很简略，开拓两条协程，一条协程写，一条协程读。
第二种情景：协程来晚了
func main() { ch := make(chan int,0) ch <- 666 go func() { <- ch }()}咱们能够看到，这条协程开拓在将数字写入到管道之后，因为没有人读，管道就不能写，而后写入管道的操作就始终阻塞。这时候你就有纳闷了，不是开拓了一条协程在读吗？然而那条协程开拓在写入管道之后，如果不能写入管道，就开拓不了协程。
第三种情景：管道读写时，互相要求对方先读/写
如果互相要求对方先读/写，本人再读/写，就会造成死锁。
func main() { chHusband := make(chan int,0) chWife := make(chan int,0) go func() { select { case <- chHusband: chWife<-888 } }() select { case <- chWife: chHusband <- 888 }}先来看看老婆协程，chWife只有能读出来，也就是老婆有钱，就给老公发个八百八十八的大红包。
再看看老公的协程，一看不得了，咋啦？老公也说只有他有钱就给老婆包个八百八十八的大红包。
两个人都说本人没钱，老公也给老婆发不了红包，老婆也给老公发不了红包，这就是死锁！
第四种情景：读写锁互相阻塞，造成隐形死锁
先来看一看代码：
func main() { var rmw09 sync.RWMutex ch := make(chan int,0) go func() { rmw09.Lock() ch <- 123 rmw09.Unlock() }() go func() { rmw09.RLock() x := <- ch fmt.Println("读到",x) rmw09.RUnlock() }() for { runtime.GC() }}这两条协程，如果第一条协程先抢到了只写锁，另一条协程就不能抢只读锁了，那么因为另外一条协程没有读，所以第一条协程就写不进。
如果第二条协程先抢到了只读锁，另一条协程就不能抢只写锁了，那么因为另外一条协程没有写，所以第二条协程就读不到。
点击关注，第一工夫理解华为云陈腐技术~