当我关闭发送方时，为什么仍然会恐慌“在关闭的通道上发送”？

最近发现不少小伙伴都对Golang很感兴趣，所以今天继续给大家介绍Golang相关的知识，本文《当我关闭发送方时，为什么仍然会恐慌“在关闭的通道上发送”？》主要内容涉及到等等知识点，希望能帮到你！当然如果阅读本文时存在不同想法，可以在评论中表达，但是请勿使用过激的措辞~

我有一个 stopchan 来通知发送者关闭通道，还有一个 sync.once 来确保只有一个发送者可以关闭通道，但我仍然收到“在关闭的通道上发送”恐慌，为什么？

func muitiSenderClose() {
    const SenderNum = 3

    wg := sync.WaitGroup{}
    wg.Add(SenderNum)

    intChan := make(chan int)

    stopChan := make(chan struct{})

    once := sync.Once{}
    for i := 0; i < SenderNum; i++ {
        go func(i int) {
            defer wg.Done()
            needStop := false
            for {
                select {
                case <-stopChan:
                    needStop = true
                case intChan <- 1:
                case intChan <- 2:
                case intChan <- 3:
                }

                if needStop {
                    break
                }
            }
            once.Do(func() {
                fmt.Printf("%d want to close chan\n",i)
                close(intChan)
            })
            fmt.Println("End. [sender] %id", i)
        }(i)
    }
    sum := 0
    for e := range intChan {
        fmt.Printf("Receive %d\n", e)
        sum += e
        if sum > 10 {
            close(stopChan)
            fmt.Printf("Got %d\n", sum)
            break
        }
    }
    fmt.Println("End. [receiver]")

    wg.Wait()
}

解决方案

go并发能力非常强大。协调并发非常很难。幸运的是，go 标准库有很多工具可以帮助解决这个问题。您可能应该熟悉 context 包。

context.Context 在幕后使用完成通道（类似于 stopChan），但具有其他机制，例如取消链。它们还在整个 go 标准库中用于 http、数据库和其他阻塞类型请求。

正如 @JimB 所提到的，通常在协调生产者/消费者时很少需要 sync.Once 。 chans 和 sync.WaitGroups 通常就足够了。

无论如何，这是使用 context.Context 对代码进行的协调修复：

https://play.golang.org/p/QwszE_bW41X

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《当我关闭发送方时，为什么仍然会恐慌“在关闭的通道上发送”？》文章吧，也可关注golang学习网公众号了解相关技术文章。