本文解析因通道无接收方导致的“all goroutines are asleep - deadlock”错误，重点说明done通道阻塞handle协程的根本原因，并提供基于sync.WaitGroup的简洁、健壮的并发控制替代方案。
本文解析因通道无接收方导致的“all goroutines are asleep - deadlock”错误，重点说明`done`通道阻塞`handle`协程的根本原因，并提供基于`sync.waitgroup`的简洁、健壮的并发控制替代方案。
在Go并发编程中，“fatal error: all goroutines are asleep - deadlock!” 是一个高频且极具迷惑性的运行时错误。它并非语法或逻辑错误，而是所有goroutine同时陷入永久阻塞状态——即没有一个goroutine能继续执行，系统无法推进。
在您提供的原始代码中，问题核心在于 done 通道的设计缺陷：
-
handle函数在每次处理完一个请求后执行done ； - 但
main函数中仅在写入9个请求之后才执行（且只消费一次）； - 此时5个
handlegoroutine 已全部启动，第一个写入done的goroutine会立即阻塞（因无接收者），其余goroutine在for r := range queue中等待新请求——而clientRequests通道尚未关闭，且main卡在前无法继续执行 <code>close(clientRequests)； - 最终：1个goroutine卡在
done （发送阻塞），4个卡在 <code>queue的range（接收阻塞），main卡在（接收阻塞）→ 全员休眠，触发死锁。
✅ 关键认知：通道操作是双向同步的。向无缓冲通道发送数据，必须有另一个goroutine同时准备接收；否则发送方永远阻塞。
done通道未被提前监听，是死锁的直接导火索。
更本质的问题是：done 通道在此场景中语义模糊——它既非用于通知“某任务完成”，也未设计为“计数器”（如用 len(done) 统计），反而成了单点瓶颈和同步陷阱。
立即学习“go语言免费学习笔记（深入）”；
推荐解法：用 sync.WaitGroup 替代 done 通道
WaitGroup 是Go标准库专为“等待一组goroutine完成”设计的轻量同步原语，天然规避通道死锁风险：
package main
import (
"fmt"
"sync"
)
type Request struct {
int32
}
const MaxOutstanding = 5
func handle(queue chan *Request, i int, wg *sync.WaitGroup) {
defer wg.Done() // 确保goroutine退出时计数器减1
for r := range queue {
fmt.Println(i, "---", r)
// 不再向done通道发送，彻底消除阻塞点
}
}
func Serve(clientRequests chan *Request, wg *sync.WaitGroup) {
// 启动MaxOutstanding个worker goroutine
for i := 0; i < MaxOutstanding; i++ {
wg.Add(1)
go handle(clientRequests, i, wg)
}
}
func main() {
clientRequests := make(chan *Request)
var wg sync.WaitGroup
// 启动服务端goroutine（不阻塞main）
go Serve(clientRequests, &wg)
// 发送50个测试请求
for i := int32(0); i < 50; i++ {
clientRequests <- &Request{i}
}
// 关闭输入通道，通知所有handle goroutine退出for-range循环
close(clientRequests)
// 等待所有handler goroutine执行完毕
wg.Wait()
fmt.Println("All handlers finished.")
}为什么此方案更优？
-
零死锁风险：
WaitGroup的Add/Done/Wait操作是原子且无阻塞的，不依赖通道通信； -
语义清晰：
wg.Wait()明确表达“等待所有worker结束”，比轮询done通道或手动计数更符合意图； -
资源可控：
close(clientRequests)是for range退出的唯一信号，确保每个goroutine优雅终止； -
可扩展性强：若需统计处理总数或错误，可在
handle内部加锁更新共享变量，无需额外通道。
注意事项
-
wg.Add()必须在go语句之前调用（如示例中wg.Add(1)在go handle(...)前），避免竞态； -
defer wg.Done()应置于handle函数首行，确保即使panic也能正确计数； - 若需处理动态增删worker，应结合
context或其他机制，WaitGroup本身不支持运行时调整。
通过摒弃不必要的通道、选用语义匹配的同步原语，即可将一段易出错的并发代码，转化为简洁、可靠、符合Go惯用法的实现。
