在go语言中，当主协程（main goroutine）过早退出时，其内部启动的子协程（goroutine）中的defer语句可能不会被执行。这并非调度问题，而是一个典型的竞态条件，因为主协程的生命周期结束会导致整个程序终止，从而中断尚未完成的子协程。为确保子协程中的defer语句能够正常执行，必须通过明确的同步机制来管理协程的生命周期，例如使用sync.waitgroup或通道（channel），以等待所有子协程完成其任务。
在Go语言的并发编程中，defer语句提供了一种优雅的方式来确保函数退出前执行清理操作。然而，当defer语句被放置在一个独立的goroutine中时，其行为可能会与预期有所不同，尤其是在主协程（main goroutine）提前退出的场景下。
现象分析：Goroutine中Defer未执行
考虑以下Go程序示例，它启动了一个子协程并在其中使用了defer语句：
package main
import (
"fmt"
"time"
)
func main() {
fmt.Println("1")
defer fmt.Println("-1") // 主协程的defer
go func() {
fmt.Println("2")
defer fmt.Println("-2") // 子协程的defer
time.Sleep(9 * time.Second) // 子协程模拟耗时操作
}()
time.Sleep(1 * time.Second) // 主协程等待1秒
fmt.Println("3")
}运行上述代码，我们得到的输出通常是：
1 2 3 -1
观察发现，子协程内部的defer fmt.Println("-2")并未被执行。这是因为main函数，即主协程，在启动子协程后仅等待了1秒。而子协程内部的time.Sleep(9 * time.Second)需要更长的时间才能完成。当主协程的time.Sleep(1 * time.Second)结束后，主协程继续执行fmt.Println("3")，然后执行其自身的defer fmt.Println("-1")，最终main函数退出，整个程序随之终止。此时，尚未完成的子协程（仍在执行time.Sleep）会被强制终止，其内部的defer语句自然也就没有机会执行。
立即学习“go语言免费学习笔记（深入）”；
误区澄清：并非调度问题
有人可能会误认为这是一个goroutine调度问题，并尝试使用runtime.Gosched()来解决。runtime.Gosched()的作用是让出当前goroutine的CPU时间片，允许其他goroutine运行。它有助于改善调度公平性，但并不能保证一个goroutine在主协程退出前完成。本例中，main协程的退出是程序终止的根本原因，Gosched无法改变这一点。因此，这本质上是一个竞态条件问题：主协程和子协程之间存在竞争，主协程的提前退出导致子协程无法完成其预期任务。
解决方案：显式协程同步
要确保子协程中的defer语句能够被执行，我们必须在主协程退出前，显式地等待子协程完成其工作。Go语言提供了多种并发同步原语来实现这一目标，其中最常用且适合此场景的是sync.WaitGroup。
使用 sync.WaitGroup
sync.WaitGroup用于等待一组goroutine完成。它的工作方式如下：
- Add(delta int): 增加计数器的值。通常在启动goroutine之前调用，表示有一个新的goroutine需要等待。
- Done(): 减少计数器的值。通常在goroutine内部，通过defer调用，表示该goroutine已完成。
- Wait(): 阻塞当前goroutine，直到计数器归零。通常在主协程中调用，等待所有注册的goroutine完成。
下面是使用sync.WaitGroup改进后的代码示例：
package main
import (
"fmt"
"sync" // 引入sync包
"time"
)
func main() {
var wg sync.WaitGroup // 声明一个WaitGroup
fmt.Println("1")
defer fmt.Println("-1") // 主协程的defer
wg.Add(1) // 增加计数器，表示有一个goroutine需要等待
go func() {
defer wg.Done() // goroutine完成后，减少计数器
fmt.Println("2")
defer fmt.Println("-2") // 子协程的defer
time.Sleep(9 * time.Second) // 子协程模拟耗时操作
fmt.Println("子协程完成任务")
}()
time.Sleep(1 * time.Second) // 主协程等待1秒
fmt.Println("3")
wg.Wait() // 阻塞主协程，直到所有注册的goroutine完成
fmt.Println("主协程等待结束")
}运行这段代码，我们将得到预期的输出：
1 2 3 主协程等待结束 子协程完成任务 -2 -1
通过wg.Wait()，主协程会一直等待，直到子协程执行完其time.Sleep(9 * time.Second)并调用wg.Done()。此时，子协程的函数体正常退出，其内部的defer fmt.Println("-2")得以执行。随后，主协程解除阻塞，继续执行fmt.Println("主协程等待结束")，最后main函数退出，其自身的defer fmt.Println("-1")也被执行。
使用通道（Channel）进行同步
除了sync.WaitGroup，通道（channel）也是Go语言中常用的同步机制。如果子协程需要向主协程传递结果，或者进行更复杂的通信，通道会是更好的选择。 例如，可以通过一个无缓冲通道来发送一个完成信号：
package main
import (
"fmt"
"time"
)
func main() {
done := make(chan struct{}) // 创建一个用于发送完成信号的通道
fmt.Println("1")
defer fmt.Println("-1")
go func() {
defer func() {
fmt.Println("-2") // 子协程的defer
close(done) // goroutine完成后关闭通道，发送完成信号
}()
fmt.Println("2")
time.Sleep(9 * time.Second)
fmt.Println("子协程完成任务")
}()
time.Sleep(1 * time.Second)
fmt.Println("3")
<-done // 阻塞主协程，直到从通道接收到信号（通道关闭或有值发送）
fmt.Println("主协程等待结束")
}此示例中，子协程在defer中关闭done通道，主协程通过
注意事项与最佳实践
- 明确生命周期管理： 在Go并发编程中，始终要明确goroutine的生命周期。如果一个goroutine的任务是独立的且不影响主程序的退出，可以不等待。但如果其结果或副作用对程序后续逻辑至关重要，或者包含资源清理（如defer），则必须进行同步。
- defer的绑定： defer语句是绑定到其所在函数的生命周期的。当函数正常返回、遇到panic或者其所在的goroutine被强制终止时，defer语句才会被执行。
- 避免“提升”defer： 将子协程的defer逻辑“提升”到主协程中是一种临时的、不规范的解决方案。它掩盖了子协程未完成的根本问题，并且如果子协程有其独立的清理任务，这种做法将导致资源泄漏或逻辑错误。
- 资源清理： defer在Go中常用于资源清理，如关闭文件、释放锁、数据库连接等。若goroutine中的defer未能执行，可能导致资源泄漏或系统状态不一致。
总结
Go语言中goroutine的defer语句未执行，通常是由于主协程过早退出，导致子协程被强制终止。这不是Go调度器的问题，而是需要显式同步的竞态条件。通过使用sync.WaitGroup或通道等同步机制，我们可以确保主协程等待所有子协程完成其任务，从而保证defer语句能够按预期执行，实现健壮的并发程序。正确管理goroutine的生命周期是编写高质量Go并发代码的关键。
