Go语言中goroutine死锁的典型原因与正确同步方案-Golang-PHP中文网

Go语言中goroutine死锁的典型原因与正确同步方案

本文解析因通道无接收方导致的“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个 handle goroutine 已全部启动，第一个写入 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语言（Golang）1.26.0

Go语言（Golang）1.26.0版本官方下载，版本号 1.26.0，适合旧项目维护、兼容性测试和指定版本开发环境搭建。

下载

推荐解法：用 `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 <h3>为什么此方案更优？</h3>