Go channel FAQ
close channel 设计理念
func closechan(c *hchan) {
// 关闭一个 nil channel, 抛出 panic
if c == nil {
panic(plainError("close of nil channel"))
}
}
为什么关闭一个已经关闭的 channel 会 panic ?
官方这样设计的初衷，应该是希望开发者不要依赖于 close 函数，而是要求开发者通过合理设计 goroutine + channel 工作流来提高程序的健壮性。
如何检测 channel 关闭
package main
import (
"fmt"
"time"
)
func main() {
ch := make(chan int)
go func() {
if val, ok := <-ch; !ok {
// channel 已关闭
fmt.Println("channel closed")
} else {
fmt.Printf("val = %d", val)
}
}()
ch <- 1024
close(ch)
time.Sleep(time.Second)
}
如何实现健壮的 channel close 方法
关闭一个已经关闭的 channel 会 panic, 实现一个方法，可以让调用方无需考虑边界情况，直接调用即可。
下面的代码只是作为技术解决方案探究，没有任何实际意义 (不要应用在你的任何业务代码中)。
1. recover
通过 recover 函数捕获 panic, 可以保证关闭一个已经关闭的 channel 报错不会导致程序终止。
package main
import (
"fmt"
)
func main() {
defer func() {
if err := recover(); err != nil {
fmt.Printf("recover err: %v\n", err)
}
}()
ch := make(chan int)
close(ch)
// 关闭一个已经关闭的 channel
close(ch)
}
2. sync.Once
通过 sync.Once 方法保证 close(channel) 只会被调用一次。
package main
import (
"sync"
)
type myChan struct {
ch chan int
once sync.Once
}
func (c *myChan) close() {
c.once.Do(func() {
close(c.ch)
})
}
func main() {
ch := &myChan{
ch: make(chan int),
}
ch.close()
// 关闭一个已经关闭的 channel
ch.close()
}
3. atomic.CAS
通过 atomic.CAS 方法保证 close(channel) 只会被调用一次。
package main
import "sync/atomic"
type myChan struct {
ch chan int
closed int32
}
func (c *myChan) close() {
if atomic.CompareAndSwapInt32(&c.closed, 0, 1) {
close(c.ch)
}
}
func main() {
ch := &myChan{
ch: make(chan int),
}
ch.close()
// 关闭一个已经关闭的 channel
ch.close()
}
4. context.Context
通过 context.Context 保证 close(channel) 的操作顺序同步。
package main
import (
"context"
)
type myChan struct {
ch chan int
ctx context.Context
cancel context.CancelFunc
}
func (c *myChan) close() {
select {
case <-c.ctx.Done():
return
default:
close(c.ch)
// 事件同步
c.cancel()
}
}
func main() {
ctx, cancel := context.WithCancel(context.Background())
ch := &myChan{
ch: make(chan int),
ctx: ctx,
cancel: cancel,
}
ch.close()
// 关闭一个已经关闭的 channel
ch.close()
}
channel 最佳实践
channel 类型作为参数时，指定操作类型 (读/写) 使用 select + default处理多个channel轮询场景永远不要在读取方向关闭 channel, 只在写入端关闭 channel不要依赖任何应用层实现的 channel关闭检测方法函数，应该将channel的读写操作进行分离 (通过不同的goroutine)，并实现只在一个写入端关闭 channel使用 context.Context控制channel的生命周期充分考虑缓冲和非缓冲 channel的使用场景无缓冲 channel提供了阻塞机制，虽然避免了数据竞态，但是当数据较多时降低了性能，而且可能引发死锁缓冲 channel虽然避免了阻塞，但是有潜在的数据竞态，而且需要考虑缓冲区大小，设计不合理容易浪费资源
channel 和锁如何选择？
当你发现使用锁使程序变得复杂时，可以试试使用 channel 会不会使程序变得简单。
锁的使用场景
访问共享数据结构中的缓存信息 保存应用程序上下文和状态信息 保护某个结构内部状态和完整性 高性能要求的临界区代码
channel 的使用场景
线程 (goroutine) 通信 并发通信 异步操作 任务分发 传递数据所有权 数据逻辑组合 (如 Pipeline, FanIn FanOut 等并发模式)
官方给出的建议是除了特殊的、底层的应用程序外，其他情况最好使用 channel 或其他同步原语来完成 (但是从大多数开源组件实现代码来看，并没有遵守官方的建议)。