为何该 goroutine 未被正确释放？

小伙伴们对Golang编程感兴趣吗？是否正在学习相关知识点？如果是，那么本文《为何该 goroutine 未被正确释放？》，就很适合你，本篇文章讲解的知识点主要包括。在之后的文章中也会多多分享相关知识点，希望对大家的知识积累有所帮助！

我正在阅读“go 中的并发”，并发现了这个 goroutine 泄漏的示例：

func main() {

    var wg sync.waitgroup

    dowork := func(strings <-chan string) <-chan interface{} {
        completed := make(chan interface{})
        go func() {
            defer fmt.println("dowork exited.")
            defer close(completed)
            defer wg.done()
            fmt.println("a")
            for s := range strings {
                fmt.println(s)
            }
            fmt.println("b")
        }()
        return completed
    }

    wg.add(1)
    dowork(nil)
    fmt.println("waiting")
    wg.wait()

    fmt.println("done.")
}

字符串通道永远不会写入任何字符串，并且包含 dowork 的 goroutine 将在进程的生命周期中保留在内存中。

我不明白 - 为什么？

我如何理解这段代码：

• 因为 strings 是 nil range-loop 刚刚跳过的。作为 nil 上的任何范围：

  slice := []int{10, 20, 30, 40, 50}
  slice = nil
  for i := range slice {
     fmt.Println(i)
  }
  fmt.Println("Done")

• fmt.println("dowork exited.") 将被执行

• close(完成)将被执行

但我发现它是这样工作的。为什么？

解决方案

由于字符串为零，因此范围循环被跳过。

这个假设是不正确的。在 go 中，从 nil 通道读取总是会阻塞。这是在 language specification 中定义的（感谢 @peterso 挖掘出链接）：

从零通道接收永远阻塞。

还有 a post on the Go Design Patterns blog 进一步详细说明了此行为并强调了它有用的一些情况。

无论如何，可以通过一个最小的示例（playground）轻松地重现此行为：

func main() {
    var s chan string
    <- s
}

这个程序永远不会完成（在演示中，它会因 all goroutine 睡着而崩溃 - deadlock）。

因为从 nil 通道读取（在您的示例中为 strings）将永远阻塞（因为无法将任何内容写入 nil 通道），所以 dowork goroutine 将永远不会完成，因此会发生泄漏。

理论要掌握，实操不能落！以上关于《为何该 goroutine 未被正确释放？》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！