当主/父 Goroutine 退出或返回时，未完成的 Goroutine 会发生什么？

在 Go 语言中，当主 Goroutine 返回或退出时，所有未完成的 Goroutine 都会被终止。如果主 Goroutine 返回，但未关闭已发送的通道，则剩余的 Goroutine 将继续运行，但它们发送到该通道的数据将丢失。这种资源泄漏可能会在通道被垃圾回收后被清除。如果通道无缓冲，未完成的 Goroutine 会阻塞并保持资源分配，直到程序终止。关闭通道会触发恐慌并杀死程序。为了避免这些问题，建议使用缓冲通道或确保所有 Goroutine 在主 Goroutine 返回前完成。

我正在阅读go编程语言书籍，第8.4章中有这个例子

func mirroredQuery() string{
    responses := make(chan string, 3)
    go func() { responses <- request("asia.gopl.io") }()
    go func() { responses <- request("americas.gopl.io") }()
    go func() { responses <- request("europe.gopl.io") }()
    return <- responses // return the quickest response
}

还有这条评论

如果我们使用无缓冲的通道，两个速度较慢的 goroutine 会在尝试将其响应发送到没有 goroutine 接收的通道时陷入困境。

这个评论本身就有道理。但是当 mirroredquery 在缓冲情况下返回时，两个慢速 goroutine 会发生什么？他们是否仍然跑完或被取消？

编辑：我知道如果主 gorountine 退出，那么 2 个较慢的 gorountine 将会“蒸发”，无论它们是否正在运行。但是如果主 goroutine 还在运行，mirroredquery() 已经返回了，那么 2 个慢速 goroutine 会跑完吗？基本上，mirroredquery 返回后 responses 是否仍然存在？如果是这样，那么原则上这两个慢协程似乎可以完成；如果没有，那么我们仍然像无缓冲的情况一样存在泄漏吗？

正确答案

当 main goroutine 返回时，整个运行时系统会突然退出。因此，任何陷入等待在无缓冲或完整通道上发送的 goroutine 都将不复存在。它们不会取消，也不会运行，也不会等待。 Think of it as the flash paper being set on fire.

我们可以将其称为 goroutine 泄漏，就像我们可以引用在程序终止“泄漏”之前未关闭或释放的任何资源（例如打开的文件）一样。但由于整个过程终止了，什么也没有剩下。这里没有真正的泄漏。这不是一次干净的清理，但系统确实进行了清理。

Here's a Playground link, as an example.

（如果你使用 Go 系统本身未定义的东西，你可能会以这种方式得到各种泄漏。例如，在旧的 System V 共享内存世界中，你可以创建共享内存段（shm_open），并且如果你永远不要关闭和取消链接它们，它们会持续存在。这是设计使然：它们的作用很像文件系统中的文件，只不过它们存在于内存中，而不是某种磁盘驱动器或其他什么地方。但这就是远远超出正常的日常 Go 编程。）

重新编辑：如果main goroutine没有退出，因此程序仍在运行，其他 goroutine 继续运行（或等待）直到它们运行没有事情要做并返回自己，或者做一些导致他们退出的事情（例如调用 runtime.Goexit，或者做一些导致恐慌的事情）。在这种情况下，那就是：等待响应，然后将响应发送到通道中，然后返回。假设他们得到响应，他们会将响应放入频道中。假设将响应放入通道有效（不会恐慌且不会阻塞），那么它们就会返回。返回后，它们就完成了并且蒸发了。通道本身持续存在并保存字符串：这是一种资源泄漏，尽管很小，尤其是在玩具程序中。

如果通道本身没有留下任何引用，则通道本身及其中的字符串将被垃圾收集；这会清理泄漏的资源。由于我们假设 mirroredQuery 已返回，并且此时剥离的 goroutine 的最后一个也已返回，这是对通道的最后一个引用，因此现在频道可以被GCed。 （这种情况是否发生以及何时发生取决于运行时。）在这些 goroutine 的最后一个完成之前，仍然至少有一个对通道的引用，从而防止通道（以及字符串）被 GC 掉.

如果通道无缓冲，两个“失败”的 goroutine 将在尝试发送到通道时阻塞。这将导致这些 goroutine 保留，进而导致通道保留，进而导致资源保持分配状态，直到整个程序终止。所以这将是“糟糕的”。

如果 mirroredQuery 关闭通道，两个“失败”的 goroutine 可能会尝试在关闭的通道上发送，这将导致它们调用恐慌代码，这将导致杀死该程序。那也将是“糟糕的”。实现所需结果的最简单代码是使通道缓冲。

如果其中一个 goroutine 等待（等待响应）几年，那么这些年就会保留这些“泄漏”的资源。这也会“糟糕”（轻微），所以我们希望确保他们不会永远等待。但这对于小型演示程序来说是不切实际的。

今天关于《当主/父 Goroutine 退出或返回时，未完成的 Goroutine 会发生什么？》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！