阅读 22

go并发之路(四)—— 确定通道是否关闭

小知识,大挑战!本文正在参与“程序员必备小知识”创作活动。

本文同时参与「掘力星计划」,赢取创作大礼包,挑战创作激励金。

前文回顾

所以目前我们发现

  • 错误的超时机制的设计让我们没办法正确运行
  • 为了做出改变,我们希望最好有确定court通道是否关闭的办法

所以本章我们主要讨论如何确定court通道是否关闭,在此之前,我们不妨设想下,没有这个功能会给我造成什么样子的麻烦

  • 在不能更改channel状态的情况下,没有简单普遍的方式来检查channel是否已经关闭了

  • 关闭已经关闭的channel会导致panic,在不知道channel是否已经关闭的情况下去关闭channel是很危险的

  • 发送值到已经关闭的channel会导致panic,在不知道channel是否已经关闭的情况下去向channel发送值也是很危险的

读取数据时

每次从通道读取数据时,都可以读到通道本身是否关闭的状态,因此在读取数据时,我们可以轻松判断court通道是否关闭。

package main
import (
    "fmt"
)
func main() {
    c := make(chan int, 10)
    c <- 1
    c <- 2
    c <- 3
    close(c)
    for {
        i, isClose := <-c
        if !isClose {
            fmt.Println("channel closed!")
            break
        }
        fmt.Println(i)
    }
}
复制代码

写入数据时

我们期待这类似的功能,一个简单的函数让我们可以监测一个通道的状态

func main() {
    c := make(chan T)
    fmt.Println(IsClosed(c)) // false
    c <- DATA
    close(c)
    fmt.Println(IsClosed(c)) // true
}
复制代码

然而这中isClosed函数往往作用不大,(这也是为什么不会有这类函数的原因),因为就算有一个简单的 closed(chan T) bool函数来检查channel是否已经关闭,它的用处还是很有限的,就像内置的len函数用来检查缓冲channel中元素数量一样。原因就在于,已经检查过的channel的状态有可能在调用了类似的方法返回之后就修改了,因此返回来的值已经不能够反映刚才检查的channel的当前状态了。

尽管在调用closed(ch)返回true的情况下停止向channel发送值是可以的,但是如果调用closed(ch)返回false,那么关闭channel或者继续向channel发送值就不安全了(这样可能会造成panic,因为之前未关闭的通道可能会在此刻恰好关闭)。

使用通道的原则

事实上,go并不建议我们由接受者关闭通道,或者在有多个发送者时由其中一个发送者关闭通道,维持这条原则将保证永远不会发生向一个已经关闭的channel发送值或者关闭一个已经关闭的channel。

那么如何安全的打破这条原则?

我们可以使用panic/recover()模式来向通道中写入数据:

func SafeWrite(ch chan T, value T) (isClosed bool) {
    defer func() {
        if recover() != nil {
            // 在panic后,会进入这个if中,然后将返回值改变为true,代表通道是关闭的
            isClosed = true
        }
    }()
    
    ch <- value // 如果通道关闭,这里会报panic
    return false // 如果可以正常写入,这里会返回false,代表通道不是关闭的
}
复制代码
文章分类
后端
文章标签