本文详解 go 中使用 goroutine 实现请求分发时常见的死锁原因，并提供基于 worker 模式、sync.waitgroup 与 channel 生命周期管理的健壮并发架构方案。
本文详解 go 中使用 goroutine 实现请求分发时常见的死锁原因，并提供基于 worker 模式、sync.waitgroup 与 channel 生命周期管理的健壮并发架构方案。
在您提供的代码中，Run() 函数通过 for request := range requestCh 持续接收请求并调用 distributor(request)，而 distributor 为每类请求（如 "sum"、"fibonacci"）启动新 goroutine 执行任务，并向全局 resultCh 发送结果。但随后的 for result := range resultCh 会永久阻塞——因为 resultCh 从未被关闭，且没有 goroutine 负责在所有工作完成后关闭它，导致主 goroutine 在 range 处死锁。
根本问题在于：未协调 goroutine 生命周期与 channel 关闭时机。Go 的 range 语句仅在 channel 被显式关闭后退出；而您的设计中，resultCh 是一个无缓冲或未指定容量的 channel，且没有任何机制通知“所有结果已发送完毕”。
✅ 推荐方案：采用 Worker 池模式（而非为每个请求启一个 goroutine）
Worker 模式更高效、可控，避免 goroutine 泛滥，且天然适配持续请求流。核心思想是：预启动固定数量的工作协程，共用一个输入 channel（如 taskCh），由主逻辑统一派发任务。
以下是重构后的关键结构（精简可运行示例）：
// 全局结果通道（带缓冲，避免发送阻塞）
var resultCh = make(chan map[string]string, 1024)
func Run() {
requestCh := make(chan []string)
idCh := make(chan string)
go publisher.Sender(requestCh)
go makeID(idCh)
// 启动固定数量 Worker（例如 8 个）
const workerCount = 8
var wg sync.WaitGroup
for i := 0; i < workerCount; i++ {
wg.Add(1)
go worker(&wg, requestCh, idCh, resultCh)
}
// 主 goroutine：接收结果并输出（不再 range 未关闭的 channel）
go func() {
for res := range resultCh {
fmt.Println("Result:", res)
}
}()
// 等待所有 Worker 退出（需配合优雅关闭逻辑）
// 注意：此处不直接 wg.Wait()，因 Worker 需长期运行
// 实际中应监听 shutdown 信号，见下文注意事项
}
// Worker：单个协程，循环处理请求
func worker(wg *sync.WaitGroup, reqCh <-chan []string, idCh <-chan string, resCh chan<- map[string]string) {
defer wg.Done()
for req := range reqCh { // 当 reqCh 关闭时退出
// 添加 ID（注意：需确保 idCh 有值，否则此处可能阻塞）
id, ok := <-idCh
if !ok {
continue // idCh 已关闭，跳过
}
req = append(req, id)
// 分发执行（直接调用，非启动新 goroutine）
var result map[string]string
switch req[0] {
case "sum", "sub", "mult", "div":
result = arithmetic.Exec(req)
case "fibonacci":
result = fibonacci.Exec(req)
case "reverse":
result = reverse.Exec(req)
case "encode":
result = encode.Exec(req)
default:
result = map[string]string{"error": "unknown command"}
}
resCh <- result
}
}⚠️ 关键注意事项
- 永远不要为每个请求 go f()：易导致 goroutine 泛滥（数万并发时内存/调度开销剧增），且难以统一管控生命周期。
-
Channel 关闭原则：
- 只有发送方能安全关闭 channel（close(ch)）；
- range ch 仅在 channel 关闭后退出；
- 若需通知“停止接收”，应关闭 requestCh（如收到 shutdown 信号），Worker 自然退出。
-
WaitGroup 使用场景：
sync.WaitGroup 适用于有限、可预期数量的 goroutine（如启动 N 个 Worker）。对于持续服务，不应 wg.Wait() 阻塞主 goroutine，而应通过信号（如 os.Signal）触发关闭流程：sigCh := make(chan os.Signal, 1) signal.Notify(sigCh, os.Interrupt, syscall.SIGTERM) <-sigCh // 等待中断信号 close(requestCh) // 让所有 Worker 退出 wg.Wait() // 等待 Worker 清理完成 close(resultCh) // 最后关闭结果通道
-
避免死锁的黄金法则：
检查所有 range 和
✅ 总结
您遇到的死锁源于 resultCh 的 range 永不终止。正确解法是：
① 弃用 per-request goroutine，改用固定 Worker 池复用协程；
② 明确 channel 所有权与关闭责任（requestCh 由主 goroutine 关闭，resultCh 可长期存在，由消费者 goroutine 独立消费）；
③ 用 sync.WaitGroup 管理 Worker 启停，用信号驱动优雅关闭。
如此，系统既能高并发处理请求，又能避免资源泄漏与死锁，符合生产级 Go 服务的设计范式。
