为何某些操作会引发通道阻塞，而另一些则不会？

对于一个Golang开发者来说，牢固扎实的基础是十分重要的，golang学习网就来带大家一点点的掌握基础知识点。今天本篇文章带大家了解《为何某些操作会引发通道阻塞，而另一些则不会？》，主要介绍了，希望对大家的知识积累有所帮助，快点收藏起来吧，否则需要时就找不到了！

我发现一些文章（以及 golang 自己的文档）描述通道操作的方式与我在现实中看到的不一致。

它与 go 如何阻塞通道读/写有关。我现在在多个地方读到，只要 goroutine 看到对通道的读取或写入，它就会阻塞执行，这意味着它要么等待接收数据，要么等待另一个 goroutine 从通道接收数据。

但是如果您查看以下示例，这显然不是第二次写入时发生的情况。

package main

import (
    "fmt"
)

func firstfunc(ch chan string) {
    fmt.println("firstfunc hello", <-ch)
    fmt.println("firstfunc() carries on getting called")
}

func secondfunc(ch chan string) {
    fmt.println("secondfunc hello", <-ch)
    fmt.println("secondfunc() carries on getting called")
}

func main() {
    fmt.println("main() started")
    c1 := make(chan string)
    c2 := make(chan string)

    go firstfunc(c1)
    go secondfunc(c2)

    c1 <- "john"
    c2 <- "bob"

    fmt.println("main() ended")
}

这就是我解释 go 执行此代码的方式：

1. 它打印 main() 启动的消息，创建通道 c1 和 c2 并将 firstfunc 和 secondaryfunc goroutines 排队（但此时不执行它们）
2. 它到达 c1 <-“john” 并阻塞它，直到另一个 goroutine 从该通道读取数据
3. 此时它会调度firstfunc从c1读取并继续执行其余代码直到函数结束
4. main() 再次重新安排，下一行是 c2 <- "bob"，此时我认为 main() 应该再次阻塞，就像它对 "john" 所做的那样，并等待 secondaryfunc 从中读取数据继续。但事实并非如此。输出：

main() started
firstFunc Hello John
firstFunc() carries on getting called
main() ended

它并不是简单地阻止对“bob”的写入，而是继续执行直到 main() 完成并且从不调度 secondaryfunc。

这现在已经成为我学习 go 的一个障碍，因为我不确定是我不相信这些文章还是我的理解有差距。

我非常感谢对此的帮助。

解决方案

无缓冲的通道写入将阻塞，直到另一个 goroutine 从中读取。当这种情况发生时，读取和写入 goroutine 都会被启用。此后，无法保证如何执行。

在您的示例中，firstFunc 从通道读取后，它将运行直到完成。主 goroutine 写入通道二，这会启用 secondFunc，但在它有机会完成写入之前，主 goroutine 就结束了。

这里的问题是，有很多可能的执行顺序，而您碰巧观察到一个特定的顺序。

它不会阻塞，因为有 2 个通道监听器（firstFunc 和 secondaryFunc） 。它们按随机顺序读取您的消息（以先醒来者为准）。所以阻塞是存在的，但对于活跃的监听者来说是观察不到的。您会看到的唯一一件事是，有时您会首先看到firstFunc 的输出，有时会看到secondFunc 的输出

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