Go语言如何用Context防止Goroutine泄露

本文深入剖析了Go语言中goroutine泄露的典型症状（如内存持续增长、pprof显示大量runtime.gopark状态goroutine、HTTP响应变慢但CPU使用率偏低）及其根本原因——未正确监听context.Done()导致goroutine在select或time.Sleep中永久阻塞；文章强调，防止泄露的关键不在于简单传递context，而在于让goroutine主动响应取消信号，通过将阻塞操作置于select中并始终包含ctx.Done()分支，结合标准库I/O方法对context的原生支持，真正实现goroutine的可取消与及时回收。

goroutine 泄露的典型表现是什么

程序内存持续上涨、pprof 查到大量 runtime.gopark 状态的 goroutine、HTTP 服务响应变慢但 CPU 不高——这些往往不是负载问题，而是 goroutine 没被正确回收。最常见的是：启动了 goroutine 去做 I/O 或等待信号，但没监听 ctx.Done()，导致它永远卡在 select 或 time.Sleep 里。

用 context.WithCancel 启动 goroutine 的标准写法

关键不是“加 context”，而是让 goroutine 主动响应取消信号。下面这种写法是错的：

go func() {
    time.Sleep(5 * time.Second) // 不检查 ctx，cancel 了也停不下来
    doWork()
}()

正确做法是把阻塞操作放进 select，并始终包含 ctx.Done() 分支：

• 所有 I/O 调用（如 http.Client.Do、net.Conn.Read）优先传入带 timeout 的 context.Context，而不是自己 sleep + retry
• 自定义等待逻辑必须用 select 包裹，且 case 是必选项，不能只 log
• 如果 goroutine 内部调用了第三方库（比如数据库驱动），确认它是否接受 context.Context 参数；不支持的库要手动包装超时逻辑

为什么 context.WithTimeout 和 context.WithCancel 行为不同

两者都产生可取消的 context，但触发时机和用途有实质差异：

• context.WithCancel：需要你显式调用返回的 cancel() 函数，适合“外部主动终止”场景，比如 HTTP handler 中用户断连
• context.WithTimeout：内部自动启动一个 timer，到点自动调用 cancel()，适合“最长执行时间”约束，比如 RPC 调用不能超过 2s
• 别混用：context.WithTimeout(parent, 0) 不等于立即取消，它等价于 context.WithCancel；而 context.Background().WithDeadline(...) 是非法的，必须用 context.WithDeadline

容易被忽略的 goroutine 泄露点

很多泄露不是出在主流程，而是边缘 case 或封装过深的地方：

• defer 里启动 goroutine（比如日志上报、指标打点），但没传 context，也没做 done channel 判断
• channel 操作未配对：向无缓冲 channel 发送数据前没确保有人接收，或从已关闭 channel 读取时没处理 ok==false 就继续循环
• 使用 sync.WaitGroup 等待 goroutine 结束，但忘记 wg.Add(1) 或 wg.Done()，导致 wg.Wait() 永远阻塞
• HTTP handler 中启 goroutine 处理耗时任务，却把 http.ResponseWriter 或 request.Body 闭包进去——连接断开后 response 已失效，但 goroutine 还在试图写它

真正难排查的泄露，往往藏在第三层依赖的 callback 里，或者超时后仍持有资源的 defer 函数中。

今天关于《Go语言如何用Context防止Goroutine泄露》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！