使用 select 语句的程序可以避免 go 中的死锁

IT行业相对于一般传统行业，发展更新速度更快，一旦停止了学习，很快就会被行业所淘汰。所以我们需要踏踏实实的不断学习，精进自己的技术，尤其是初学者。今天golang学习网给大家整理了《使用 select 语句的程序可以避免 go 中的死锁》，聊聊，我们一起来看看吧！

这个问题很可能已经被我找不到答案了，所以我们开始吧：

我有一个 go 函数，可以使用 select 语句发送或接收“消息”（无论哪一个可用）：

func seek(name string, match chan string) {
select {
case peer := <-match:
    fmt.printf("%s sent a message to %s.\n", peer, name)
case match <- name:
    // wait for someone to receive my message.

我使用无缓冲通道在 4 个不同的 go 例程上启动此函数（最好使用缓冲区 och 1，但这只是实验性的）：

people := []string{"anna", "bob", "cody", "dave"}
match := make(chan string)
for _, name := range people {
    go seek(name, match, wg)

现在，我刚刚开始使用 go，并且认为由于我们使用的是无缓冲通道，因此“select”的发送和接收语句都应该阻塞（没有人等待发送消息，因此您可以' t 接收，并且没有人等待接收，所以你无法发送），这意味着函数之间不会进行任何通信，也称为死锁。然而运行代码告诉我们事实并非如此：

API server listening at: 127.0.0.1:48731
Dave sent a message to Cody.
Anna sent a message to Bob.
Process exiting with code: 0

我向你们可爱的人们提出的问题是为什么会发生这种情况？编译器是否意识到这些函数想要在同一通道中读/写并安排它发生？或者“select”语句是否不断检查是否有人可以使用该频道？

抱歉，如果这个问题很难回答，我还是个新手，对幕后的运作方式没有那么丰富的经验:)

解决方案

现在，我刚刚开始使用 go，并且认为由于我们使用的是无缓冲通道，因此“select”的发送和接收语句都应该阻塞（没有人等待发送消息，因此您可以'没有收到，并且没有人等待接收，因此您无法发送）

这实际上是不正确的；事实上，有多个 goroutine 等待接收，也有多个 goroutine 等待发送。当一个 goroutine 执行像你这样的 select 时：

select {
case peer := <-match:
    fmt.Printf("%s sent a message to %s.\n", peer, name)
case match <- name:
    // Wait for someone to receive my message.

它同时等待发送和接收。由于您有多个例程执行此操作，因此每个例程都会找到发送者和接收者。没有什么会阻挡。由于多个case同时解锁，selects会随机选择case。

今天带大家了解了的相关知识，希望对你有所帮助；关于Golang的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~