17370845950

goroutine泄漏典型表现为内存持续上涨、CPU不降及pprof显示大量goroutine阻塞在chan receive/select；定位需用runtime.NumGoroutine()打点日志并访问/debug/pprof/goroutine?debug=2查堆栈。

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

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

• 用 runtime.NumGoroutine() 在关键点打日志，观察数量是否回落
• HTTP 服务下访问 /debug/pprof/goroutine?debug=2 查看完整堆栈
• 所有带循环的 goroutine 必须有明确退出条件，避免无休止 for {}

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

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

• 若使用 for range ch，channel 关闭后自动退出循环 —— 这是安全的惯用法
• 若用 select 配合 case v, ok := ，需显式检查 ok 并 break
• 绝不要在多个 goroutine 中都写 if ch != nil { close(ch) }

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 负责生命周期同步。

• wg.Add(n) 必须在 goroutine 启动前执行，且不能被并发调用
• 每个 goroutine 结束前必须调用 wg.Done()，推荐用 defer wg.Done()
• 若 goroutine 可能因 channel 关闭提前退出，defer 仍能保证 Done 执行

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 简洁。

• 需要传值、背压、或解耦生产/消费节奏 → 用 channel
• 只关心“它们干完了没”，且无数据交互 → 用 WaitGroup
• 既要等结束，又要收集返回结果 → channel 更自然（如 chan result）
• 超时控制、取消传播 → 应优先考虑 context.Context，而非靠 channel + timer 拼接

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