Channel关闭原则

不要在消费端关闭channel,不要在有多个并行的生产者时对channel执行关闭操作。
也就是说应该只在[唯一的或者最后唯一剩下]的生产者协程中关闭channel,来通知消费者已经没有值可以继续读了。只要坚持这个原则,就可以确保向一个已经关闭的channel发送数据的情况不可能发生。

暴力关闭channel的正确方法

如果想要在消费端关闭channel,或者在多个生产者端关闭channel,可以使用recover机制来上个保险,避免程序因为panic而崩溃。

func SafeClose(ch chan T) (justClosed bool) {
     defer func() {
        if recover() != nil {
            justClosed = false
        }
    }()
    close(ch)
    return true
}

使用这种方法明显违背了上面的channel关闭原则,然后性能还可以,毕竟在每个协程只会调用一次SafeClose,性能损失很小。
同样也可以在生产消息的时候使用recover方法。

礼貌关闭channel方法

还有不少人经常使用sync.Once来关闭channel,这样可以确保只会关闭一次

同样我们也可以使用sync.Mutex达到同样的目的。

要知道golang的设计者不提供SafeClose或者SafeSend方法是有原因的,
他们本来就不推荐在消费端或者在并发的多个生产端关闭channel,
比如关闭只读channel在语法上就彻底被禁止使用了。

优雅的关闭channel的方法

多个消费者,单个生产者.

多个生产者,单个消费者。


就上面这个例子,生产者同时也是退出信号channel的接受者,退出信号channel仍然是由它的生产者

多个生产者,多个消费者