Go语言防止Goroutine泄露的技巧

Go语言中goroutine泄露常表现为内存持续增长、pprof显示大量处于runtime.gopark状态的goroutine，以及HTTP响应变慢但CPU占用偏低——这往往不是高负载所致，而是因goroutine未正确响应取消信号而永久阻塞；核心在于必须让每个goroutine主动监听ctx.Done()，将sleep、I/O等阻塞操作置于select语句中并始终包含ctx.Done()分支，而非简单地传入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 函数中。

今天带大家了解了的相关知识，希望对你有所帮助；关于Golang的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~