goroutine泄漏主因是协程无法正常退出，需通过context控制生命周期、正确关闭channel、避免阻塞及使用pprof监控来预防。
Go语言中的goroutine泄漏是一个常见但容易被忽视的问题。虽然goroutine轻量，但一旦创建却没有正确退出，长时间运行的程序会积累大量阻塞或空转的goroutine，导致内存增长、调度压力上升，甚至服务崩溃。解决这个问题的关键在于理解泄漏成因，并在编码阶段就引入预防机制。
明确goroutine泄漏的典型场景
goroutine泄漏本质是启动了协程却无法正常退出。常见原因包括：
- channel未关闭且接收方阻塞：向无缓冲channel发送数据时，若另一端没有接收或已退出，发送方会永久阻塞。
- for-select循环缺少退出条件：监听channel的goroutine如果没有收到关闭信号，会一直运行。
- context未传递或未使用：父goroutine取消后，子任务未感知，继续执行。
- 死锁或逻辑错误导致无法到达return：例如互斥锁未释放，或select中default分支缺失。
使用context控制生命周期
context是管理goroutine生命周期的标准方式。通过context.WithCancel、context.WithTimeout等函数创建可取消的上下文，将它传递给所有衍生的goroutine。
示例：ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
defer cancel()
<p>go func(ctx context.Context) {
for {
select {
case <-ctx.Done():
return // 正确退出
default:
// 执行任务
}
}
}(ctx)当上下文超时或被取消，ctx.Done()通道会关闭，goroutine能及时退出。
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
确保channel正确关闭与处理
channel是goroutine通信的核心，但使用不当极易引发泄漏。
- 发送方应避免向已关闭的channel写入（会panic），接收方要能处理channel关闭后的零值。
- 由发送方负责关闭channel（惯例），防止多个写入者造成重复关闭。
- 使用close(ch)显式关闭，配合range或ok := 判断通道状态。
done := make(chan bool)
go func() {
defer close(done)
// 处理任务
}()
<p>select {
case <-done:
// 完成
case <-time.After(3 * time.Second):
// 超时，避免无限等待
}监控与诊断泄漏
开发和生产环境中可通过以下方式发现潜在泄漏：
- pprof分析goroutine数量：访问/debug/pprof/goroutine查看当前协程堆栈。
- 日志记录goroutine启动与退出：尤其在关键服务中，添加trace信息。
- 单元测试中检测泄漏：利用runtime.NumGoroutine前后对比，或使用第三方库如leakcheck。
定期检查goroutine数量趋势，异常增长往往是泄漏的信号。
基本上就这些。goroutine泄漏不是突发问题，而是累积风险。只要在设计时考虑退出路径，合理使用context和channel，再辅以监控手段，就能有效避免。不复杂但容易忽略。
