“纵有疾风来，人生不言弃”，这句话送给正在学习Golang的朋友们，也希望在阅读本文《为什么在 defer 语句中关闭通道会出现恐慌？》后，能够真的帮助到大家。我也会在后续的文章中，陆续更新Golang相关的技术文章，有好的建议欢迎大家在评论留言，非常感谢！
问题内容在下面的示例中，go 例程将值泵入无缓冲通道，并且主函数对其进行迭代。
package main
import (
"fmt"
"strconv"
)
var chanstr chan string
func main() {
go pump()
fmt.println("iterating ...")
for val := range chanstr {
fmt.printf("fetched val: %s from channel\n", val)
}
}
func pump() {
defer close(chanstr)
chanstr = make(chan string)
for i := 1; i <= 5; i++ {
fmt.printf("pumping seq %d into channel\n", i)
chanstr <- "val" + strconv.itoa(i)
}
//close(chanstr)
}
该函数出现紧急情况并输出以下内容：
iterating ...
pumping seq 1 into channel
pumping seq 2 into channel
fetched val: val1 from channel
......
fetched val: val4 from channel
pumping seq 5 into channel
panic: close of nil channel
goroutine 5 [running]:
main.pump()
C:/personal/gospace/go-rules/test.go:26 +0x1a6
created by main.main
C:/personal/gospace/go-rules/test.go:11 +0x4e但是，如果我评论 defer 语句并在 goroutine pump 中的 for 循环之后立即关闭，接收器不会恐慌。
这两种情况有什么区别？ 看起来 defer 在收到值之前关闭通道，但常规关闭会等待。
此外，当我使用竞争检测器进行构建时，即使在常规关闭中，它也会标记潜在的竞争条件（我无法每次都重新创建竞争）。这是否意味着这两种方式都不适合优雅地关闭通道？
更新：
对于所有评论，我知道问题是什么。我必须在 main() 函数的第一行创建通道。不过，我在 windows 上运行 go1.12，并且观察到了这种行为。
显然我没有伪造输出。我一直使用 defer 语句重新创建恐慌，甚至当我在 pump() 中的 for 循环之后立即关闭通道时，也没有发生过恐慌。
解决方案
您的代码在不同方面都非常活泼：
在 goroutine 实际初始化通道之前，您有可能（事实上，很有可能）开始从
for val循环中的通道读取数据，从而导致死锁。iterating ... pumping seq 1 into channel fatal error: all goroutines are asleep - deadlock!事实上，这是我观察到的在本地或演示中按原样执行代码的唯一行为。
如果我添加延迟，
fmt.println("iterating ...") time.sleep(10 * time.millisecond) // delay ensures the channel has been created for val := range chanstr {然后我会观察您注意到的行为：
iterating ... pumping seq 1 into channel fetched val: val1 from channel pumping seq 2 into channel pumping seq 3 into channel fetched val: val2 from channel fetched val: val3 from channel pumping seq 4 into channel pumping seq 5 into channel fetched val: val4 from channel fetched val: val5 from channel panic: close of nil channel原因是您正在调用
close(chanstr)，而chanstr仍然为零。如果您在创建通道后调用defer：func pump() { chanstr = make(chan string) defer close(chanstr)你会解决这个问题。
要解决这两个竞争，您需要在调用 goroutine 之前初始化通道。完整代码：
package main
import (
"fmt"
"strconv"
)
var chanstr chan string
func main() {
chanstr = make(chan string)
go pump(chanstr)
fmt.println("iterating ...")
for val := range chanstr {
fmt.printf("fetched val: %s from channel\n", val)
}
}
func pump(chanstr chan string) {
defer close(chanstr)
for i := 1; i <= 5; i++ {
fmt.printf("pumping seq %d into channel\n", i)
chanstr <- "val" + strconv.itoa(i)
}
}为了进一步说明问题是 defer close(chanstr) 立即评估 chanstr（虽然它仍然是 nil），请考虑以下（不推荐！）替代解决方案：
package main
import (
"fmt"
"strconv"
"time"
)
var chanStr chan string
func main() {
go pump()
fmt.Println("iterating ...")
time.Sleep(10 * time.Millisecond)
for val := range chanStr {
fmt.Printf("fetched val: %s from channel\n", val)
}
}
func pump() {
defer func() {
close(chanStr)
}()
chanStr = make(chan string)
for i := 1; i <= 5; i++ {
fmt.Printf("pumping seq %d into channel\n", i)
chanStr <- "val" + strconv.Itoa(i)
}
}在这种情况下，延迟函数是 chanstr 的闭包，因此 chanstr 的计算被延迟到实际执行。在此版本中，当延迟函数执行时，chanstr 不再为 nil，因此无需恐慌。
理论要掌握，实操不能落！以上关于《为什么在 defer 语句中关闭通道会出现恐慌？》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注编程网公众号吧！
