贝利信息

如何在Golang中管理多个goroutine_Golang channel与WaitGroup协作技巧

日期:2026-01-22 00:00 / 作者:P粉602998670
goroutine泄漏典型表现为内存持续上涨、CPU不降及pprof显示大量goroutine阻塞在chan receive/select;定位需用runtime.NumGoroutine()打点日志并访问/debug/pprof/goroutine?debug=2查堆栈。

goroutine 泄漏的典型表现和快速定位方法

启动大量 goroutine 后程序内存持续上涨、CPU 占用不降,或 pprof 显示大量 goroutine 处于 chan receiveselect 等待状态,基本可以判定存在泄漏。根本原因常是 channel 未关闭 + 接收端未退出,或 WaitGroupAdd/Done 不配对。

channel 关闭时机必须由发送方决定

channel 是并发安全的,但关闭行为本身不是原子操作;多个 goroutine 同时 close(ch) 会 panic:panic: close of closed channel。因此,**只有唯一发送方(或经协调的发送方)才能调用 close()**,接收方只负责读取直到 ok == false

go func() {
    defer wg.Done()
    for i := 0; i < 5; i++ {
        ch <- i
    }
    close(ch) // ✅ 唯一关闭点
}()

WaitGroup 与 channel 组合使用的正确模式

常见错误是把 wg.Add(1) 放在 goroutine 内部,导致主 goroutine 提前等待;或忘记 wg.Done(),造成死锁。标准协作结构是:启动前 Add,退出前 Done,channel 负责数据传递,WaitGroup 负责生命周期同步。

ch := make(chan int, 3)
var wg sync.WaitGroup

// 启动 3 个 worker for i := 0; i < 3; i++ { wg.Add(1) go func(id int) { defer wg.Done() for v := range ch { fmt.Printf("worker %d got %d\n", id, v) } }(i) }

// 发送数据 for i := 0; i < 5; i++ { ch <- i } close(ch)

wg.Wait() // 等待所有 worker 退出

何时该用 channel,何时该用 WaitGroup

channel 不是万能同步原语。它适合传递数据、控制流(如退出信号)、或实现生产者-消费者模型;WaitGroup 只解决“等一组 goroutine 结束”这一个事。混用时容易过度设计 —— 比如仅为了等结束而创建无缓冲 channel 做通知,不如直接用 WaitGroup 简洁。

真正难的不是语法,是判断哪个 goroutine 该关 channel、哪个该关自己、哪个该被 WaitGroup 等 —— 这取决于你定义的职责边界。一旦发送方结束,就该关 channel;一旦 worker 完*部任务(包括处理完 channel 关闭),就该 Done;没有明确的“最后一个”概念,只有清晰的状态契约。