Go sync.WaitGroup 内存泄露问题解析

Go 中的 sync.WaitGroup 本身不会直接造成内存泄漏，但它极易掩盖真正的 goroutine 泄漏问题：当 Add 与 Done 调用不匹配（如 panic、提前返回导致 Done 未执行），或 goroutine 在任务中无限阻塞时，wg.Wait() 将永久挂起，使大量 goroutine 及其默认至少 2KB 的栈内存持续驻留，最终引发内存持续增长和 OOM 崩溃；文中深入剖析了典型错误模式（如 defer wg.Done() 在 panic 时失效）、安全修复方案（结合 recover 的统一 defer），并推荐更健壮的替代方案 errgroup.Group，帮助开发者从根本上规避这类隐蔽而致命的资源泄漏风险。

WaitGroup 不是内存泄漏的直接原因，但它会掩盖 goroutine 泄漏，让泄漏更难被发现、更难被回收——最终表现为内存持续上涨、OOM 崩溃。

WaitGroup.Add 和 Done 调用不匹配

这是最常见也最隐蔽的问题：Add(1) 了，但某个 goroutine 因 panic、提前 return 或逻辑跳过，没走到 Done()。结果 wg.Wait() 永远阻塞，所有已启动的 goroutine 都卡在那儿不动，栈内存（2KB 起）持续累积。

• 典型错误写法：go func() { defer wg.Done(); doWork() }() —— 如果 doWork() panic，defer wg.Done() 根本不会执行
• 正确做法：把 recover 和 Done 绑定在同一个 defer 里：defer func() { if r := recover(); r != nil { /* log */ } wg.Done() }()
• 更稳妥方式：改用 errgroup.Group，它自动处理 panic + Done + 上下文取消，不用手写

goroutine 内部阻塞导致 WaitGroup 无法退出

WaitGroup 只管“计数归零”，不管 goroutine 是否还活着。如果 goroutine 卡在 、select {}、time.Sleep 或网络等待上，Done() 永远不会被调用，wg.Wait() 就永远等下去。

• 例如：go func() { wg.Add(1); —— 这个 goroutine 启动即永久阻塞，wg.Add(1) 还在函数体外，根本没进 goroutine，更别说 Done()
• 修复关键：所有可能阻塞的操作，必须包裹在 select 中监听 ctx.Done()，并在收到时主动 return
• 别依赖 runtime.GC() —— 它对卡住的 goroutine 无效，栈内存不会被回收

WaitGroup 被跨 goroutine 复用或误共享

WaitGroup 不是线程安全的“可复制对象”。把它作为值传递（比如方法接收者是 WaitGroup 而非 *WaitGroup），会导致每个 goroutine 操作的是自己的副本，wg.Wait() 永远等不到真实计数归零。

• 错误示例：func (wg WaitGroup) Do() { wg.Add(1); go func() { wg.Done() }() } —— wg 是拷贝，Add 和 Done 影响的是不同实例
• 必须传指针：func (wg *WaitGroup) Do() { wg.Add(1); go func() { wg.Done() }() }
• 更危险的是：多个 goroutine 同时调用 wg.Add(n) 而没加锁 —— Add 本身不是原子操作，可能导致计数错乱

真正难排查的，从来不是 wg.Wait() 卡住，而是那些“看起来执行完了”的 goroutine 其实卡在 select 或 channel 上，还在偷偷吃内存。pprof 查 /debug/pprof/goroutine?debug=2 时，重点盯 chan receive、semacquire、select 这几类堆栈，比盯着 WaitGroup 本身有用得多。

今天关于《Go sync.WaitGroup 内存泄露问题解析》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！