如何优雅的关闭channel？

一、channel使用存在的不方便地方

1、在不改变channel自身状态的情况下，无法获知一个channnel是否关闭。

2、关闭一个已经关闭的channel，会导致panic。因此，如果关闭channel的一方在不知道channel是否关闭状态时就去贸然关闭channel是件很危险的事。

3、向一个已经关闭的channel发送数据会导致panic。因此，如果向channel发送数据的一方不知道channel是否处于关闭状态就贸然向channel发送数据是很危险的事情。

一个比较粗糙的检查channel是否关闭的函数：

func IsClosed(ch <-chan interface{}) bool {
    select {
    case <-ch:
        return true
    default:
    }
    return false
}

func main() {
    c := make(chan interface{})
    fmt.Println(IsClosed(c))  // false
    close(c)
    fmt.Println(IsClosed(c)) // true
}

上面的代码其实存在很多问题。

首先，IsClosed函数是一个有副作用的函数。每调用一次，都会读出channel里面的一个元素，改变了channel的状态，这不是一个好函数，干活就干活，还顺手牵羊？

其次，IsClosed函数返回的结果仅代表调用时候的那个瞬间，并不能保证调用之后不会有其他goroutine对这个channel进行了一些操作，改变了这个channel的状态。比如：IsClosed函数返回true，但这时有另外一个goroutine关闭了这个channel，这时候我们就会拿着这个过时的"channel未关闭"信息，向其发送数据，就会导致panic的发生。

当然，一个channel不会被重复关闭两次，如果IsClosed函数返回的结果是true,说明channel是真的关闭了。

有一句广泛流传的关闭channel的原则：

不要从一个 receiver 侧关闭 channel，也不要在有多个 sender 时，关闭 channel。

向channel发送元素的就是sender，因此sender可以决定何时不发送数据，并且关闭channel。但是如果有多个sender，某个sender同样没法确定其他sender的情况。这时候也不能贸然的关闭channel。

有两个不优雅关闭channel的方法：

1、使用defer-recover机制，放心大胆地关闭channel或者向channel发送数据，即使发生了panic，有defer-recover在兜底。

2、使用sync.Once来保证只关闭一次。

二、如何优雅关闭channel

根据sender和receiver的个数，可以分为以下几种情况：

1、一个sender，一个receiver

2、一个sender，M个receiver

3、N个sender，一个receiver

4、N个sender，M个receiver

对于1，2这两种情况，只有一个sender，直接从sender段关闭就好。

第3种情形下，优雅关闭channel的方法是：唯一的receiver发出一个关闭channel的信号，senders监听到关闭信号后，停止发送数据。

func main() {
    rand.Seed(time.Now().UnixNano())

    const Max = 10000
    const NumSenders = 1000

    dataChan := make(chan int, 100)
    stopChan := make(chan struct{})

    // senders
    for i := 0; i < NumSenders; i++ {
        go func() {
            for {
                select {
                // 监听关闭channel的信号，退出
                case <-stopChan:
                    return
                // 给dataChan中发送数据
                case dataChan <- rand.Intn(Max):
                }
            }
        }()
    }

    // receiver
    go func() {
        // 从dataChan中遍历数据
        for value := range dataChan {
            // 如果value的值为9999，通知sender停止发送数据
            if value == Max-1 {
                fmt.Println("send stop signal to senders.")
                close(stopChan)
                return
            }
            fmt.Println(value)
        }
    }()

    select {
    // 阻塞一小时退出
    case <-time.After(time.Hour):
    }
}

这里的stopCh就是信号channel，它本身只有一个sender，因此可以直接关闭它。senders收到了关闭信号后，select分支case<-stopCh被选中，退出函数，不再发送数据。

需要说明的是，上面的代码并没有明确关闭dataCh。在Go语言中，对于一个channel，如果最终没有任何goroutine引用它，不管channel有没有被关闭，最终都会被GC回收。所以在这种情形下，所谓的优雅地关闭channel就是不关闭channel，让GC代劳。

最后一种情况，优雅关闭channel的方法是：any one of them says “let’s end the game” by notifying a moderator to close an additional signal channel。

和第三种情况不同，这里有M个receiver，如果，采用第3种解决方案，由receiver直接关闭stopCh的话，就会重复关闭一个channel，导致panic。因此需要增加一个中间人，M个receiver都向它发送关闭dataCh的"请求"，中间人收到第一个请求后，就会直接下达关闭dataCh的指令（通过关闭stopCh,这时就不会发生重复关闭的情况，因为stopCh的发送方只有中间人一个）。另外这里N个sender也可以向中间人发送关闭dataCh的请求。

func main() {
    rand.Seed(time.Now().UnixNano())

    const Max = 10000
    const NumReceivers = 10
    const NumSenders = 1000

    dataCh := make(chan int, 100)
    stopCh := make(chan struct{})

    // 这里必须是一个有缓冲的channel
    toStop := make(chan string, 1)

    var stoppedBy string

    // 中间人
    go func() {
        // 接收到了关闭channel的请求
        stoppedBy = <-toStop
        // 发送关闭dataCh的信号
        close(stopCh)
    }()

    // senders
    for i := 0; i < NumSenders; i++ {
        go func(id string) {
            for {
                value := rand.Intn(Max)
                // 如果value=0，则给中间人发送关闭channel的信号
                if value == 0 {
                    select {
                    case toStop <- "sender#" + id:
                    // 此处是为了防止toStop这个channel阻塞
                    default:
                    }
                    return
                }

                select {
                // 监听关闭channel的信号
                case <-stopCh:
                    return
                case dataCh <- value:
                }
            }
        }(strconv.Itoa(i))
    }

    // receivers
    for i := 0; i < NumReceivers; i++ {
        go func(id string) {
            for {
                select {
                // 监听关闭信号，退出，停止接收数据
                case <-stopCh:
                    return
                // 接收数据
                case value := <-dataCh:
                    // 如果接收到了9999，则给中间人发送关闭channel的信号
                    if value == Max-1 {
                        select {
                        case toStop <- "receiver#" + id:
                        default:
                        }
                        return
                    }
                    fmt.Println(value)
                }
            }
        }(strconv.Itoa(i))
    }

    select {
    case <-time.After(time.Hour):
    }

}

代码里toStop就是中间人的角色，使用它来接收senders和receivers发送过来的关闭dataCh请求。

这里将toStop声明成了一个缓冲型的channel。假设toStop声明的是一个非缓冲型的channel，那么第一个发送的关闭dataCh请求可能会丢失。因为无论是sender还是receiver都是通过select语句来发送请求，如果中间人所在的goroutine没有准备好，那么select语句就不会被选中，直接走default选项了，什么都不做。这样，第一个关闭dataCh的请求就会丢失。

如果把toStop的容量声明成Num(senders) + Num(receivers)，那么发送dataCh请求的部分可以改写成更简洁的形式：

func main() {
	rand.Seed(time.Now().UnixNano())

	const Max = 10000
	const NumReceivers = 10
	const NumSenders = 1000

	dataCh := make(chan int, 100)
	stopCh := make(chan struct{})

	// 这里必须是一个有缓冲的channel
	toStop := make(chan string, NumSenders+NumReceivers)

	var stoppedBy string

	// 中间人
	go func() {
		// 接收到了关闭channel的请求
		stoppedBy = <-toStop
		// 发送关闭dataCh的信号
		close(stopCh)
	}()

	// senders
	for i := 0; i < NumSenders; i++ {
		go func(id string) {
			for {
				value := rand.Intn(Max)
				// 如果value=0，则给中间人发送关闭channel的信号
				if value == 0 {
					toStop <- "sender#" + id
					return
				}

				select {
				// 监听关闭channel的信号
				case <-stopCh:
					return
				case dataCh <- value:
				}
			}
		}(strconv.Itoa(i))
	}

	// receivers
	for i := 0; i < NumReceivers; i++ {
		go func(id string) {
			for {
				select {
				// 监听关闭信号，退出，停止接收数据
				case <-stopCh:
					return
				// 接收数据
				case value := <-dataCh:
					// 如果接收到了9999，则给中间人发送关闭channel的信号
					if value == Max-1 {
						toStop <- "receiver#" + id
						return
					}
					fmt.Println(value)
				}
			}
		}(strconv.Itoa(i))
	}

	select {
	case <-time.After(time.Hour):
	}
}

直接向toStop发送请求，因为toStop容量足够大，所以不用担心阻塞，自然也就不用select语句再加一个default case来避免阻塞。

可以看到，这里同样没有真正关闭dataCh,同第3种情况。

参考链接：

https://golang.design/go-questions/channel/graceful-close/