如何在 Go Concurrency Patterns fan-in 示例中推理 Go 通道阻塞？

Question

package main

import (

    "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。粗略地说，这三个功能由于使用了通道而紧密地绑定在一起

Answer 1

阻塞是如何发生的？在这种情况下是什么阻止了什么？如果另一侧没有相应的接收操作（或者如果通道是nil，则成为没有接收器的情况），则无缓冲通道上的每个发送都会阻塞。考虑到main调用boring和fanIn顺序发生的情况。特别是这一行：c&nbsp;:=&nbsp;fanIn(boring("Joe"),&nbsp;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仍然可以继续执行，程序马上退出，不会发生死锁。