为什么戈鲁丁漏水

Question

我在第30页上读到了12 Go最佳做法和遭遇以及有趣的例子。

func sendMsg(msg, addr string) error {
    conn, err := net.Dial("tcp", addr)
    if err != nil {
        return err
    }
    defer conn.Close()
    _, err = fmt.Fprint(conn, msg)
    return err
} 

func broadcastMsg(msg string, addrs []string) error {
    errc := make(chan error)
    for _, addr := range addrs {
        go func(addr string) {
            errc <- sendMsg(msg, addr)
            fmt.Println("done")
        }(addr)
    }

    for _ = range addrs {
        if err := <-errc; err != nil {
            return err
        }
    }
    return nil
}

func main() {
    addr := []string{"localhost:8080", "http://google.com"}
    err := broadcastMsg("hi", addr)

    time.Sleep(time.Second)

    if err != nil {
        fmt.Println(err)
        return
    }
    fmt.Println("everything went fine")
}

前面提到的程序员在上面提到的代码中出现了这种情况：

the goroutine is blocked on the chan write
the goroutine holds a reference to the chan
the chan will never be garbage collected

为什么戈鲁蒂河在这里被封锁了？主线程被阻塞，直到它从goroutine接收到数据。在它继续for循环之后。不?

为甚麽陈婉娴永远不会被收垃圾？因为我没有关闭通道，戈鲁丁完成了吗？

Answer 1

我看到的一个问题是，在goroutines开始后，在broadcastMsg()内部：

for _ = range addrs {
    if err := <-errc; err != nil {
        return err
    }
}

如果从nil接收到非error，则broadcastMsg()将立即返回该错误，并且不会从通道接收进一步的值，这意味着更多的errc将永远不会被解除阻塞，因为errc是未缓冲的。

可能的修正

一个可能的解决方法是使用一个缓冲通道，在这种情况下，这个通道足够大到不阻塞任何一个goroutines：

errc := make(chan error, len(addrs))

或者，即使从频道接收到一个非nil的error，接收的数量仍然是它发送的数量的两倍：

var errRec error
for _ = range addrs {
    if err := <-errc; err != nil {
        if errRec == nil {
            errRec = err
        }
    }
}
return errRec

或者如在幻灯片#33上的链接对话中所提到的:使用“退出”通道来防止broadcastMsg()完成/返回后继续阻塞已启动的大猩猩。

Answer 2

您有两个地址的列表(localhost，google)。对于每个地址，您都要发送一条消息(嗨)，每个地址使用一个goroutine。而戈鲁蒂将错误(可能为零)发送到errc信道。

如果您向一个通道发送某种东西，您还需要从该通道读取值的东西，否则它将阻塞(除非它是一个缓冲通道，但即使是缓冲通道一旦缓冲区满了，也会阻塞)。

所以你的阅读循环是这样的：

for _ = range addrs {
    if err := <-errc; err != nil {
        return err
    }
}

如果第一个地址返回一个不为零的错误，则循环返回。以后的错误值永远不会从通道中读取，因此它会阻塞。