# 前言今天在研究一个问题[“使用 Go 实现任意 goroutine 的暂停, 继续的功能”]。下面是代码 ```go package main import ( "fmt" "sync" "time" ) func Task(i int) { fmt.Println("消息： ", i) } var wg sync.WaitGroup func main() { // 准备一个任务，任务需要处理10件事情 taskList := 10 // 任务开关 taskFlag := make(chan int, 1) taskCh := make(chan int, 1) // 准备一个后台协程，处理任务 go func() { defer fmt.Println("任务结束") // 开关 for { select { case task, ok := <-taskCh: if !ok { return } Task(task) case t, ok := <-taskFlag: fmt.Println("---", ok) fmt.Println("任务被取消:", time.Duration(t)*time.Second) time.Sleep(time.Second * time.Duration(t)) } } }() for i := 0; i < taskList; i++ { taskCh <- i // i 等于 if i == 5 { fmt.Println("任务暂停2秒") taskFlag <- 2 } } close(taskCh) close(taskFlag) wg.Wait() } ``` 但是运行的结果如下所示 ```bash 消息： 0 消息： 1 消息： 2 消息： 3 消息： 4 任务暂停2秒消息： 5 --- true 任务被取消: 2s 消息： 6 消息： 7 消息： 8 --- false 任务被取消: 0s 消息： 9 --- false 任务被取消: 0s 任务结束 ``` 从上面的运行结果所示，我们会看到`case t, ok := <-taskFlag:` 这个select分支的代码仍然会被执行，但是taskFlag这个chan我们只传递了一次值但是他执行了三次，真的是太奇怪了，我在go.dev上并没有查到关于select的详细说明，在此吐槽一下go官方做的文档，感觉语法没有太多的解释，都是性能调优的教程占多数。 # 研究下面我写了一个实验的代码 ```go package main import ( "fmt" "time" ) func main() { ch1 := make(chan int, 1) ch2 := make(chan int, 100000) go func() { for { select { case i := <-ch1: fmt.Println("ch1: ", i) case i := <-ch2: fmt.Println("ch2: ", i) } } }() for i := 1; i <= 10; i++ { time.Sleep(time.Second) ch1 <- i if i == 5 { ch2 <- i } } close(ch1) close(ch2) time.Sleep(10 * time.Second) } ``` 这个代码有一个很奇特的地方，下面是运行结果 ```bash ch1: 1 ch1: 2 ch1: 3 ch1: 4 ch1: 5 ch2: 5 ch1: 6 ch1: 7 ch1: 8 ch1: 9 ch1: 0 ch2: 0 ch1: 0 ch2: 0 ch1: 0 ch2: 0 ch1: 0 ch2: 0 ... ``` 可以从运行结果看到，我们的ch1和ch2在前面执行的时候是没有问题的，但是当执行完for循环后，ch1和ch2就会疯狂的往下打印一，此时按道理来说通道已经关闭了，不应该会执行的. ## 原因在一番存在下来，我发现go的select并不会检查通道是否关闭，当通道没有关闭的时候就会一直读取通道，直到通道有值在传递。但是如果当通道为0时他就和你在for循环里写`i := <-ch1`的效果一模一样，他读取关闭的通道是一直可以读取的，返回的是初始值。但是你写通道是会panic,这个确实是值得注意的点，当然go的通道其实是存在第二个参数的，就是检查通道是否存在关闭`i, ok := <-ch1`，ok这个参数就是判断读取的通道是否关闭的，如果是true说明通道的值是正常的，反之。所以我们回到之前的案例，我们应该这样子改程序就正常了。 ```go package main import ( "fmt" "sync" "time" ) func Task(i int) { fmt.Println("消息： ", i) } var wg sync.WaitGroup func main() { // 准备一个任务，任务需要处理10件事情 taskList := 10 // 任务开关 taskFlag := make(chan int, 1) taskCh := make(chan int, 1) // 准备一个后台协程，处理任务 go func() { defer func() { close(taskCh) close(taskFlag) }() defer fmt.Println("任务结束") // 开关 for { select { case task, ok := <-taskCh: if !ok { return } Task(task) case t, ok := <-taskFlag: fmt.Println("---", ok) fmt.Println("任务被取消:", time.Duration(t)*time.Second) time.Sleep(time.Second * time.Duration(t)) } } }() for i := 0; i < taskList; i++ { // time.Sleep(time.Second) taskCh <- i // i 等于 if i == 5 { fmt.Println("任务暂停2秒") taskFlag <- 2 } } wg.Wait() time.Sleep(time.Second) } ``` 运行结果 ```bash 消息： 0 消息： 1 消息： 2 消息： 3 消息： 4 任务暂停2秒消息： 5 --- true 任务被取消: 2s 消息： 6 消息： 7 消息： 8 消息： 9 ``` 此时程序运行的结果就正常了 # 总结 go语言的chan对读取并不会管通道关没关闭，但是写在关闭的通道就会panic。这种情况下我建议还是在读端关闭比较好。但是这个还是得看业务场景来。不过go语言这个chan真的是一个值得吐槽的地方。没有严格现在关闭后的读取，不过在有缓冲区的情况下这个应该也是被设计考量的范围吧，不过这个坑现在踩过了，以后就不会踩了