为什么没有接收者被阻塞的错误？

Question

Receivers always block until there is data to receive

这个测试应该会失败，因为对于最后一个来自通道的接收操作，没有相应的写入：

package main

import "fmt"

func main() {
    c := make(chan int)    
    for i := 0; i < 4; i++ { // 4 async reads
      go func() {
            fmt.Println("received:", <-c)
         }()

    }    
    // just 3 writes, 1 write is missing
    c <- 1   
    c <- 2 
    c <- 3   
}

然而脚本并没有在读取 goroutine 中失败并显示错误消息，但它成功打印了 3 个值：

为什么会这样，或者我对同步有什么误解？

Answer 1

这里没有死锁，因为 main goroutine 没有被阻塞。它在 c 上发送 3 个值，这些值成功，因为有 4 个启动的 goroutines 从它接收，然后它结束。它也会结束你的应用程序，它不会等待其他非 main goroutines 结束。参见。

死锁意味着所有 goroutine 都被阻塞。这里不是这种情况。

尝试从没有人（当前或曾经）准备发送的频道接收不是错误。如果是事实，那是完全正常的。这是通道的一个用例：它充当同步工具，您可以发送/接收并且操作将阻塞，直到另一端也准备就绪。

在某些情况下，即使一个 goroutine 在整个应用程序生命周期内被阻塞也是正常的，例如goroutine 可能会等待用户输入，例如 CTRL+BREAK，用户可能永远不会按下，应用程序可能会正常结束。

因此这不被视为错误，并且不会为这些打印错误或警告消息。但是，如果您好奇的话，实现起来也很容易。只需向您的 main() 添加一个延迟函数，它将在您的 main() 函数（以及您的应用程序）结束之前调用最后一件事。在该打印中运行 goroutines 的数量：

func main() {
    defer func() {
        fmt.Println("Remaining goroutines:", runtime.NumGoroutine()-1) //-1 for main
    }()

    // your code
}

加上这个，输出将是：

received: 1
received: 2
received: 3
Remaining goroutines: 1

如果您将循环更改为启动 14 个 goroutine 而不是 1 个，输出将显示还有 11 个剩余的 goroutine。

最后说明：由于在您的应用程序中 main() 函数不会等待其他 goroutines 结束，因此在调用延迟函数时它们可能仍然处于活动状态，因此它们可能包含也可能不包含在剩余的 goroutines 计数中。如果你会使用例如sync.WaitGroup等他们完结，那肯定不收录了。有关示例，请参阅。

为什么没有接收者被阻塞的错误？

Why there is no error that receiver is blocked?

channel

go

goroutine