本文深入解析 go 中使用 goroutine 分发请求时常见的死锁成因，介绍基于 worker 模式的高并发处理方案，并提供可落地的 waitgroup + channel 协作实践。
本文深入解析 go 中使用 goroutine 分发请求时常见的死锁成因，介绍基于 worker 模式的高并发处理方案，并提供可落地的 waitgroup + channel 协作实践。
在你当前的 Run() 函数中，for result := range resultCh { fmt.Println(result) } 这一行导致了永久阻塞（deadlock），根本原因在于：resultCh 是一个无缓冲、未关闭的 channel，且主 goroutine 在 requestCh 循环结束后立即进入该 range，但此时所有工作 goroutine（如 fibonacci.Exec）已随 distributor 调用完成而退出，resultCh 再无发送者——range 永远等不到 close(resultCh)，程序卡死。
更深层的问题在于架构设计：你为每个请求都新建一个专用 channel（如 arithCh, fibCh）并启动 goroutine，这不仅资源开销大，还破坏了 channel 的复用性与可控性。Go 的并发哲学是 “不要通过共享内存来通信，而应通过通信来共享内存”，而你的实现却让每个任务独占通道，丧失了调度弹性。
✅ 推荐采用 Worker Pool（工作者池）模式，统一管理并发能力：
// 全局结果通道（带缓冲，避免阻塞发送）
var resultCh = make(chan map[string]string, 1024)
// 启动固定数量的工作协程（例如 8 个）
func startWorkers(wg *sync.WaitGroup, numWorkers int) {
for i := 0; i < numWorkers; i++ {
wg.Add(1)
go func() {
defer wg.Done()
for req := range requestCh { // 复用 requestCh，无需为每次请求建新 channel
var result map[string]string
switch req[0] {
case "sum", "sub", "mult", "div":
result = arithmetic.Calculate(req)
case "fibonacci":
result = fibonacci.Calculate(req)
case "reverse":
result = reverse.Process(req)
case "encode":
result = encode.Transform(req)
default:
result = map[string]string{"error": "unknown command"}
}
resultCh <- result // 发送结果（缓冲通道确保非阻塞）
}
}()
}
}在 Run() 中重构如下：
func Run() {
requestCh := make(chan []string, 1024) // 建议加缓冲，防 publisher 阻塞
idCh := make(chan string, 1024)
var wg sync.WaitGroup
// 启动发送器与 ID 生成器
go publisher.Sender(requestCh)
go makeID(idCh)
// 启动 8 个工作协程（可根据 CPU 核心数调整）
startWorkers(&wg, 8)
// 主循环：接收请求、注入 ID、分发
for request := range requestCh {
request = append(request, <-idCh)
// 直接发给 requestCh，由 worker 统一消费
// 注意：此处 requestCh 已被 worker 监听，无需再调 distributor()
}
// 关键：关闭输入通道，通知所有 worker 退出
close(requestCh)
// 启动结果消费 goroutine（避免阻塞主流程）
go func() {
for res := range resultCh {
fmt.Println(res)
}
}()
// 等待所有 worker 完成
wg.Wait()
// 可选：关闭 resultCh，使结果消费者能自然退出
close(resultCh)
}⚠️ 关键注意事项：
- 永远不要对未关闭的无缓冲 channel 执行 range —— 这是 Go 中最常见死锁源头；
- 避免为每个请求创建新 channel：channel 是轻量级的通信原语，但频繁创建/销毁违背 Go 的设计范式；
- 合理设置 channel 缓冲区：make(chan T, N) 可缓解生产者-消费者速率不匹配问题；
- WaitGroup 必须与 goroutine 生命周期严格对应：Add() 在 go 前，Done() 在 goroutine 末尾（通常用 defer）；
- 关闭 channel 的责任归属单一：通常由发送方（或协调者）关闭，接收方只读不关。
通过 Worker Pool 模式，你将获得：✅ 可控的并发数、✅ 清晰的生命周期管理、✅ 高效的 channel 复用、✅ 易于监控与扩缩容的架构基础。这才是 Go 并发编程的惯用之道。
