“纵有疾风来，人生不言弃”，这句话送给正在学习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 语句中关闭通道会出现恐慌？》的详细介绍，大家都掌握了吧！