Goroutine泄漏主因是协程无法正常退出，常见于channel阻塞、死循环无退出、WaitGroup未完成及Context未监听；应使用Context传递取消信号并检查Done()通道，确保协程及时终止。
在 Golang 中，Goroutine 泄漏是一个常见但容易被忽视的问题。它不会立即显现，却可能在长时间运行的服务中导致内存耗尽、性能下降甚至服务崩溃。防止 Goroutine 泄漏的关键在于理解其生命周期管理机制，并合理设计退出逻辑。
理解 Goroutine 泄漏的原因
当一个 Goroutine 启动后，如果它无法正常退出，就会持续占用内存和调度资源，形成泄漏。常见原因包括：
- 阻塞在无缓冲或未关闭的 channel 上：例如从一个永远没有写入的 channel 读取数据，或向无人接收的 channel 发送数据。
- 死循环未设置退出条件：比如 for {} 循环中没有 break 或 return 条件。
- 等待 WaitGroup 但部分 Goroutine 未完成：主协程等待 Done() 调用，但某些协程因错误提前退出或陷入阻塞。
- Context 未传递或未监听取消信号：子 Goroutine 没有检查父级 Context 是否已取消。
使用 Context 控制生命周期
Context 是管理 Goroutine 生命周期的核心工具。通过它可以向下传递取消信号，确保所有派生协程能及时退出。
建议每个可能长时间运行的 Goroutine 都接收一个 context.Context 参数，并定期检查其 Done() 通道。
立即学习“go语言免费学习笔记（深入）”；
示例：func worker(ctx context.Context) {
for {
select {
case <-ctx.Done():
fmt.Println("worker exiting due to:", ctx.Err())
return
default:
// 执行任务
time.Sleep(100 * time.Millisecond)
}
}
}
<p>// 使用
ctx, cancel := context.WithCancel(context.Background())
go worker(ctx)
// 当需要停止时
cancel()
对于超时或截止时间场景，可使用 context.WithTimeout 或 context.WithDeadline，避免无限等待。
确保 Channel 正确关闭与处理
Channel 是 Goroutine 通信的主要方式，但使用不当极易引发泄漏。
- 不要向已关闭的 channel 发送数据：会 panic。应由发送方负责关闭，且仅关闭一次。
- 接收方应处理 channel 关闭的情况：使用 ok :=
- 避免 Goroutine 等待永远不会到来的数据：如启动一个 Goroutine 从 channel 读取，但无人写入。
解决方法之一是使用 context 结合 channel：
func readWithTimeout(ch <-chan int, timeout time.Duration) (int, bool) {
ctx, cancel := context.WithTimeout(context.Background(), timeout)
defer cancel()
<pre class="brush:php;toolbar:false;">select {
case val := <-ch:
return val, true
case <-ctx.Done():
return 0, false
}}
监控与检测 Goroutine 泄漏
开发阶段可通过以下方式发现潜在泄漏：
- pprof 分析 Goroutine 数量：访问 /debug/pprof/goroutine 可查看当前运行的协程堆栈。
- 测试中对比 Goroutine 计数：使用 runtime.NumGoroutine() 在操作前后统计数量变化。
- 使用 defer 和 recover 防止意外 panic 导致协程卡住。
线上服务建议集成监控指标，定期告警异常增长的 Goroutine 数量。
基本上就这些。只要每个启动的 Goroutine 都有明确的退出路径，并通过 Context 统一管理生命周期，就能有效避免泄漏问题。不复杂但容易忽略。
