关闭 Go 通道时的​​竞争条件

Question

以下 Go 代码示例在行 c <- byte(0) 和 close(c) 之间有一个竞态条件。使用go test -race 运行代码时会发出信号。

func TestRace(t *testing.T) {
    var c = make(chan byte, 20)
    go func() {
        defer func() {
            if r := recover(); r == nil {
                t.Error("expected panic error")
            }
        }()
        for i := 0; i < 25; i++ {
            c <- byte(0)
        }
        t.Error("expected a panic")
    }()
    close(c)
}

如何避免这种竞争状况？

编辑：根据 Icza 在他的 cmets 中的建议，解决方案如下：

func TestRace(t *testing.T) {
    var c = make(chan byte, 20)
    var done = make(chan struct{})
    go func() {
        for i := 0; i < 25; i++ {
            select{
            case c <- byte(0):
            case <-done:
                close(c)
                return
        }
    }()
    close(done)
}

这不会有竞争条件，并且是干净的。这是一个愚蠢的简单例子。有人告诉我选择会增加开销，但我没有调查它，因为它与我的用例无关。

Answer 1

通常，在通道上发送值的 goroutine 负责关闭它。关闭通道基本上是一个信号，表示将不会（可以）在其上发送更多值。

你没有这样做：你的新 goroutine 是发送值的那个，而你的另一个 goroutine 是关闭它的那个。

要摆脱竞争条件，只需按预期使用通道：将 close(c) 调用移动到在其上发送值的 goroutine，例如：

go func() {
    defer func() {
        if r := recover(); r == nil {
            fmt.Println("expected panic error")
        }
    }()
    for i := 0; i < 25; i++ {
        c <- byte(0)
    }
    close(c)
    fmt.Println("expected a panic")
}()
for x := range c {
    fmt.Println("Received:", x)
}

在Go Playground 上试用。