详解Golang并发操作中常见的死锁情形

什么是死锁，在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()
  }
}

这两条协程，如果第一条协程先抢到了只写锁，另一条协程就不能抢只读锁了，那么因为另外一条协程没有读，所以第一条协程就写不进。

如果第二条协程先抢到了只读锁，另一条协程就不能抢只写锁了，那么因为另外一条协程没有写，所以第二条协程就读不到。

关于详解Golang并发操作中常见的死锁情形的文章就介绍至此，更多相关Golang 并发死锁内容请搜索编程宝库以前的文章，希望大家多多支持编程宝库！

etcd是使用Go语言开发的一个开源的、高可用的分布式key-value存储系统，可以用于配置共享和服务的注册和发现。类似项目有zookeeper和consul。etcd具有以下特点：完全复制：集群中的每个节点都 ...