登录
首页 >  Golang >  Go问答

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

来源:stackoverflow

时间:2024-04-13 15:24:36 436浏览 收藏

最近发现不少小伙伴都对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.Oncechans 和 sync.WaitGroups 通常就足够了。

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

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

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

声明:本文转载于:stackoverflow 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>