package mainimport ( "fmt" "math/rand" "time")func boring(msg string) <-chan string { // Returns receive-only channel of strings. c := make(chan string) go func() { // We launch the goroutine from inside the function. for i := 0; ; i++ { c <- fmt.Sprintf("%s %d", msg, i) time.Sleep(time.Duration(rand.Intn(1e3)) * time.Millisecond) } }() return c // Return the channel to the caller.}func fanIn(input1, input2 <-chan string) <-chan string { c := make(chan string) go func() { for { c <- <-input1 } }() go func() { for { c <- <-input2 } }() return c}func main() { c := fanIn(boring("Joe"), boring("Ann")) for i := 0; i < 10; i++ { fmt.Println(<-c) } fmt.Println("You're both boring; I'm leaving.")}这是 Rob Pike 关于Go 并发模式的演讲中的一个示例。我理解扇入模式背后的想法,并且我理解在 main 中打印消息的顺序是不确定的:我们只打印 10 条结果证明已经准备好的消息。然而,我不完全理解的是调用的顺序以及什么阻塞了什么。仅使用无缓冲通道,因此根据文档,无缓冲通道会阻止发送方。该boring函数启动一个 goroutine,将字符串发送到c返回的无缓冲通道。如果我理解正确,这个内部 goroutine 会启动但不会阻塞boring。它可以立即将通道返回main给fanIn函数。但fanIn做几乎相同的事情:它从输入通道接收值并将它们发送到返回的自己的通道。阻塞是如何发生的?在这种情况下是什么阻止了什么?一个示意性的解释将是完美的,因为老实说,即使我有一个直观的理解,我也想了解它背后的确切逻辑。我的直观理解是,每次发送都boring阻塞,直到接收到值fanIn,但随后该值立即发送到另一个通道,因此它被阻塞,直到接收到值main。粗略地说,这三个功能由于使用了通道而紧密地绑定在一起
1 回答

30秒到达战场
TA贡献1828条经验 获得超6个赞
阻塞是如何发生的?在这种情况下是什么阻止了什么?
如果另一侧没有相应的接收操作(或者如果通道是nil
,则成为没有接收器的情况),则无缓冲通道上的每个发送都会阻塞。
考虑到main
调用boring
和fanIn
顺序发生的情况。特别是这一行:
c := fanIn(boring("Joe"), boring("Ann"))
有评估顺序:
boring("Joe")
boring("Ann")
fanIn
中的发送操作并在 中boring("Joe")
具有boring("Ann")
相应的接收操作fanIn
,因此它们会阻塞直到fanIn
运行。因此boring
产生了自己的 goroutine 以确保它在fanIn
可以开始接收之前返回通道。
中的发送操作在 中fanIn
具有相应的接收操作main
,因此它们将阻塞直到fmt.Println(<-c)
运行。因此fanIn
产生它自己的 goroutine(s) 以确保它在main
可以开始接收它之前返回输出通道。
finallymain
的执行让fmt.Println(<-c)
一切都开始运转。接收c
解除阻塞c <- <-input[1|2]
和接收<-input[1|2]
解除阻塞c <- fmt.Sprintf("%s %d", msg, i)
。
如果去掉 中的接收操作main
,main
仍然可以继续执行,程序马上退出,不会发生死锁。
- 1 回答
- 0 关注
- 111 浏览
添加回答
举报
0/150
提交
取消