本文详解 go 中 goroutine 与 channel 的协同设计，重点解决因通道未关闭、缺少同步机制导致的死锁问题，并提供基于 worker 模式和 waitgroup 的健壮并发分发方案。
本文详解 go 中 goroutine 与 channel 的协同设计，重点解决因通道未关闭、缺少同步机制导致的死锁问题，并提供基于 worker 模式和 waitgroup 的健壮并发分发方案。
在 Go 并发编程中，直接为每个请求启动 goroutine 并向共享结果通道（如 resultCh）发送数据看似简洁，但极易引发死锁（deadlock）——正如你在 Run() 函数末尾 for result := range resultCh 处遇到的问题。根本原因在于：resultCh 是一个无缓冲、未关闭的通道，而主 goroutine 在此处永久阻塞等待接收；与此同时，所有工作 goroutine（如 arithmetic.Exec、fibonacci.Exec 等）在向 resultCh 发送结果后即退出，但无人负责关闭该通道，也无机制通知主 goroutine “所有任务已完成”。更关键的是，你的当前设计中 resultCh 缺乏明确的生命周期管理：它既未被显式关闭，也未通过 sync.WaitGroup 或其他同步原语协调生产者与消费者。
✅ 推荐方案：采用 Worker 池模式（稳定、可扩展、防死锁）
相比为每个请求动态创建 goroutine 和临时通道（如 arithCh, fibCh），Worker 池是更优解：它复用固定数量的 goroutine 从统一任务通道读取请求，避免资源无限增长，且天然支持优雅关闭与同步。
以下是重构后的核心逻辑示例：
// 全局结果通道（带缓冲，避免发送阻塞）
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 <p>其中 handleRequest 可精简为纯分发逻辑（无需再创建新 channel/goroutine）：</p><pre class="brush:php;toolbar:false;">func handleRequest(request []string) {
switch request[0] {
case "sum", "sub", "mult", "div":
arithmetic.Exec(request, resultCh) // 直接调用，非 go arithmetic.Exec(...)
case "fibonacci":
fibonacci.Exec(request, resultCh)
case "reverse":
reverse.Exec(request, resultCh)
case "encode":
encode.Exec(request, resultCh)
}
}
? 关键改进点：
- ✅ 统一任务通道：所有请求经 requestCh 分发，worker 复用，避免 goroutine 泛滥；
- ✅ 显式关闭通道：close(requestCh) 触发所有 worker 退出循环，close(resultCh) 让结果消费者自然结束；
- ✅ WaitGroup 同步：确保所有 worker 完全退出后再关闭 resultCh，防止漏发；
- ✅ 缓冲结果通道：make(chan ..., 1024) 防止 worker 因结果通道满而阻塞；
- ❌ 移除冗余 channel（如 arithCh）：直接传参调用执行函数，消除不必要的 goroutine 层级和通道耦合。
⚠️ 若必须保留 per-request goroutine：务必添加超时与错误处理
若因业务特殊性需为每个请求启动独立 goroutine，则必须引入超时控制与 panic 恢复，并通过 sync.WaitGroup + close() 显式管理结果通道：
func distributor(request []string) {
var wg sync.WaitGroup
wg.Add(1)
go func() {
defer wg.Done()
select {
case resultCh <p>但此方式难以扩展，<strong>强烈推荐优先采用 Worker 池模式</strong>——它更符合 Go 的并发哲学：<em>“Don’t communicate by sharing memory, share memory by communicating.”</em>，且能有效规避死锁、资源泄漏与调度开销。</p><p><strong>总结</strong>：Go 并发的健壮性不在于“越多 goroutine 越好”，而在于<strong>清晰的通道所有权、明确的关闭时机、合理的同步机制</strong>。用 Worker 池替代动态 goroutine 创建，用 WaitGroup 协调生命周期，用缓冲通道缓解发送压力——三者结合，即可构建出高可靠、易维护的并发分发系统。</p>
