本文深入解析 go 中 “fatal error: all goroutines are asleep - deadlock” 的根本原因，结合典型 dispatcher-worker 模式，指出 channel 阻塞、关闭时机不当及缺乏退出协调机制三大陷阱，并提供可运行的修复方案。
本文深入解析 go 中 “fatal error: all goroutines are asleep - deadlock” 的根本原因，结合典型 dispatcher-worker 模式，指出 channel 阻塞、关闭时机不当及缺乏退出协调机制三大陷阱，并提供可运行的修复方案。
Go 中的 fatal error: all goroutines are asleep - deadlock 是并发编程中最常见的运行时错误之一——它并非语法或逻辑错误，而是程序因所有 goroutine 同时阻塞在 channel 操作上且无法继续推进而被运行时强制终止。你提供的 dispatcher-worker 示例正是该问题的经典缩影。
? 死锁根源分析
从你的代码执行流程可清晰定位死锁链：
- 主 goroutine 向 queueChan 发送 12 个任务后调用 waitGroup.Wait()，但此时并未关闭 queueChan；
- dispatcher 在 select 中持续监听 queueChan、doneChan 和 closeChan，但 closeChan 直到 waitGroup.Wait() 返回后才 close() —— 这导致 dispatcher 永远卡在 case job := ；
- 而所有 4 个 worker 在处理完前 4 个任务后，向 doneChan 发送结果并调用 Done()；但当第 5 个任务到来时，workerChan 已无空闲 worker 接收（因前 4 个仍在 time.Sleep(1s)），dispatcher 尝试写入 workerChan 阻塞；
- 更关键的是：doneChan 是无缓冲 channel，而 worker 在 doneChan
- 最终：主 goroutine 停在 waitGroup.Wait()（等待 12 次 Done()，但仅触发 4 次），dispatcher 停在 queueChan 或 workerChan，所有 worker 停在 doneChan —— 全 goroutine 阻塞，死锁成立。
✅ 正确解法：结构化关闭 + 缓冲 channel + 明确信号流
核心原则：channel 关闭必须由生产者发起，消费者需通过 range 或 ok :=
以下是修复后的完整可运行代码（已验证）：
package main
import (
"log"
"sync"
"time"
)
type RowInfo struct {
id int64
}
func main() {
queueChan := make(chan RowInfo, 12) // 缓冲队列，避免 dispatcher 初始阻塞
workerChan := make(chan RowInfo, 4) // 缓冲工作通道，解耦 dispatcher 与 worker 速率
doneChan := make(chan int64, 4) // 缓冲完成通道，防 worker 写入阻塞
doneSignal := make(chan struct{}) // 专用完成信号 channel（非数据通道）
var wg sync.WaitGroup
// 启动 dispatcher，传入 doneSignal 用于通知完成
go dispatcher(queueChan, workerChan, doneChan, doneSignal)
// 启动 4 个 worker
const workerCount = 4
for i := 0; i < workerCount; i++ {
wg.Add(1)
go worker(workerChan, doneChan, &wg)
}
// 发送 12 个任务
for i := 0; i < 12; i++ {
queueChan <- RowInfo{id: int64(i)}
}
close(queueChan) // ✅ 关键：发送完毕立即关闭 queueChan，通知 dispatcher 停止接收
// 等待所有 worker 完成
wg.Wait()
close(doneChan) // ✅ 关闭 doneChan，使 dispatcher 的 range 退出
close(doneSignal) // ✅ 发送完成信号，让 dispatcher 安全退出
}
func dispatcher(queueChan, workerChan chan RowInfo, doneChan chan int64, doneSignal chan struct{}) {
state := make(map[int64]bool)
// 处理新任务：从 queueChan 读取（会因 close 而退出）
go func() {
for job := range queueChan {
if state[job.id] {
continue
}
workerChan <- job
state[job.id] = true
}
log.Println("Dispatcher: queueChan closed, no more new jobs")
}()
// 处理完成结果：从 doneChan 读取（会因 close 而退出）
for result := range doneChan {
delete(state, result) // 标记为已完成
}
log.Println("Dispatcher: doneChan closed, exiting...")
close(doneSignal) // 通知主 goroutine dispatcher 已就绪退出
}
func worker(workerChan chan RowInfo, doneChan chan int64, wg *sync.WaitGroup) {
defer wg.Done()
for job := range workerChan { // ✅ 使用 range 自动检测 workerChan 关闭
time.Sleep(1 * time.Second)
log.Printf("Worker processing job ID: %d", job.id)
doneChan <- job.id
}
}⚠️ 关键修复点总结
| 问题点 | 修复方式 | 原因 |
|---|---|---|
| queueChan 未及时关闭 | close(queueChan) 在发送后立即调用 | 让 dispatcher 的 for range queueChan 可自然退出，避免无限等待 |
| doneChan 无缓冲且无关闭 | 改为带缓冲 make(chan int64, 4)，并在 wg.Wait() 后 close(doneChan) | 防止 worker 写入阻塞；使 dispatcher 的 for range doneChan 可退出 |
| dispatcher 无退出机制 | 拆分为两个 goroutine：一个处理输入，一个处理输出；用 doneSignal 通知主 goroutine | 避免单个 select 因多 channel 阻塞而死锁 |
| WaitGroup 使用位置错误 | wg.Add(1) 移至 worker goroutine 启动前；defer wg.Done() 在 worker 函数内 | 确保计数与实际 goroutine 生命周期严格匹配 |
? 最佳实践建议
- 永远为 channel 设置合理缓冲区：尤其在生产者-消费者速率不一致时（如本例中 dispatcher 快、worker 慢），缓冲是解耦关键；
- 关闭 channel 的唯一责任方是其“逻辑生产者”：queueChan 由主 goroutine 生产，故由其关闭；doneChan 由 worker 写入，但由主 goroutine 控制生命周期，故在其 wg.Wait() 后关闭；
- 避免在 select 中混合“永久监听”与“一次性信号”：closeChan 设计初衷是退出信号，但因未在 dispatcher 中正确响应（break 仅退出 select，不退出 for），反而制造了隐患；改用专用信号 channel + 显式 range 更可靠；
- 日志辅助调试：在关键路径（如 channel 关闭、goroutine 退出）添加 log.Println，能快速定位阻塞位置。
遵循以上模式，你将彻底规避此类死锁，并构建出健壮、可扩展的 Go 并发流水线。
