Question

接收者总是阻塞直到有数据要接收为止

该测试应该失败，因为对于从通道进行的最后接收操作，没有相应的写操作：

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个已启动的goroutine从那里接收，然后结束。有了它，您的应用程序也结束了，它不会等待其他非main goroutine结束。参见No output from goroutine。

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

尝试从没有人（当前或曾经）准备好继续发送的频道中接收消息不是错误。如果确实如此，那是完全正常的。那是渠道的用例之一：它充当同步工具，您可以发送/接收，操作将阻塞，直到另一端也准备就绪。

在某些情况下，甚至在整个应用程序生命周期中被阻止的goroutine都是正常的，例如goroutine可能会等待诸如 CTRL + BREAK 之类的用户输入，用户可能永远不会按下它，并且应用可能会正常结束。

因此，这不被视为错误，并且不会为这些错误打印任何错误或警告消息。但是，如果您好奇，可以轻松实现它。只需在您的main()函数（及其应用程序）结束之前向您的main()添加一个延迟函数即可。在该打印中，正在运行的goroutine的数量：

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()函数不会在您的应用程序中等待其他goroutine结束，因此在调用延迟函数时它们可能仍处于活动状态，因此它们可能包含在或未包含在剩余的goroutine计数。如果您使用例如sync.WaitGroup等待它们结束，那么它们肯定不会包含在内。有关示例，请参见Prevent the main() function from terminating before goroutines finish in Golang。

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

1 个答案: