Goroutine 死锁：为什么会出现 "fatal error: all goroutines are asleep - deadlock!"？

"fatal error: all goroutines are asleep - deadlock!" 错误是由于 Go 运行时检测到所有 goroutine 均处于阻塞状态，且无法被唤醒，导致程序无法继续执行。 这种死锁通常发生在 goroutine 之间存在循环等待，且没有外部触发条件打破这种循环时。以下是具体原因分析和解决方案：

1. 循环等待与通道阻塞在原始代码中，两个 goroutine 通过通道 a 和 b 交替通信：

   goroutine1：从 a 接收数据后，向 b 发送数据。

   goroutine2：从 b 接收数据后，向 a 发送数据。

   当 goroutine2 执行最后一次迭代时，它会向 a 发送数据并退出。但此时 goroutine1 可能正在等待 b 的数据（因 goroutine2 已退出，b 通道无数据可接收），而 goroutine2 又等待 goroutine1 从 a 接收数据。两者互相等待，形成死锁。

2. WaitGroup 的同步问题WaitGroup 用于等待两个 goroutine 完成，但若 goroutine 因死锁无法退出，wg.Wait() 会永久阻塞，导致主 goroutine 也无法继续执行。

3. 通道关闭的时机虽然代码中使用了 defer close(a) 和 defer close(b)，但通道关闭发生在主 goroutine 退出前，此时两个 goroutine 可能已因死锁无法执行到关闭逻辑，导致资源未正确释放。

1. 打破循环等待在 goroutine1 的最后一次迭代中添加一个额外的接收操作（<-A），确保它能处理 goroutine2 的最后一条消息。修改后的代码如下：

   func main() { A := make(chan bool) B := make(chan bool) defer close(A) defer close(B) var wg sync.WaitGroup wg.Add(2) go func() { for i := 0; i < 10; i += 2 { if <-A { fmt.Println(i) B <- true } } <-A // 额外接收，确保处理最后一条消息 wg.Done() }() go func() { for i := 1; i < 10; i += 2 { if <-B { fmt.Println(i) A <- true } } wg.Done() }() A <- true wg.Wait()}

   关键修改：goroutine1 在循环结束后通过 <-A 接收一个额外值，避免因 goroutine2 退出导致 A 通道阻塞。

2. 使用带缓冲的通道若通信逻辑允许，可将无缓冲通道改为带缓冲通道（如 make(chan bool, 1)），减少严格同步的需求。但需注意缓冲大小需匹配实际场景。

3. 显式关闭通道在 goroutine 完成通信后显式关闭通道（而非依赖 defer），确保资源及时释放。例如：

   go func() { defer close(B) for i := 0; i < 10; i += 2 { if <-A { fmt.Println(i) B <- true } } wg.Done()}()

4. 使用 context 取消机制通过 context.Context 传递取消信号，在死锁发生前终止 goroutine。例如：

   ctx, cancel := context.WithCancel(context.Background())defer cancel()// 在 goroutine 中检查 ctx.Done()

1. 避免双向循环依赖：确保 goroutine 之间的通信链有明确的终止条件。
2. 使用超时或取消机制：通过 time.After 或 context 避免无限等待。
3. 工具检测：使用 go run -race 或静态分析工具（如 staticcheck）提前发现潜在死锁。

死锁的本质是 资源竞争与循环等待。在 Go 中，通道和同步原语（如 WaitGroup）需谨慎设计，确保每个 goroutine 都有明确的退出路径。通过添加额外接收操作、使用缓冲通道或显式关闭资源，可有效避免此类问题。