如何避免Go goroutine泄漏_Go并发资源管理技巧

Goroutine 泄漏必然发生而非偶发，因未显式控制退出会导致内存持续增长、调度变慢；须用 context 管理生命周期，避免无出口 for 循环或未监听的 select。

Go 中的 goroutine 泄漏不是“偶尔发生”，而是只要没显式控制退出，就一定会发生——它不报错、不 panic，只悄悄吃内存、拖慢调度，直到某天线上告警突增。

用 context 控制生命周期，别信“它自己会结束”

很多人写 go func() { for { ... } }() 就完事，以为业务逻辑跑完 goroutine 就自动回收。错：只要 for 没出口、select 没监听 ，它就永远卡在运行队列里。

• 必须用 context.WithCancel 或 WithTimeout 创建可取消上下文，并在启动 goroutine 时传入
• 在 select 中始终把 作为第一分支，且不能放在 default 后面
• 调用 cancel() 的位置要明确：比如 HTTP handler 返回前、任务完成回调里、或 defer 中（如果生命周期确定）

func worker(ctx context.Context) {
    for {
        select {
        case <-ctx.Done():
            return // 必须有这一行
        default:
            doWork()
            time.Sleep(100 * time.Millisecond)
        }
    }
}
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
defer cancel() // 这里 defer 是安全的，因为 ctx 生命周期明确
go worker(ctx)

channel 操作不配 close 或 select 超时，等于主动制造阻塞点

无缓冲 channel 的发送/接收是同步的；一旦一方消失，另一方就永久挂起。pprof 里看到大量 chan send 或 chan receive 状态的 goroutine，90% 是这个原因。

• 不要对无缓冲 channel 做单向写入，除非你 100% 确保有且仅有一个接收者在运行
• 接收方必须检查 ok（v, ok := ），否则从已关闭 channel 读取会持续返回零值，可能引发逻辑错误
• 优先用带超时的 select，而不是裸写
• 发送方完成任务后，应主动 close(ch)，而非靠 GC “等它死”

ch := make(chan int, 1) // 改用带缓冲，避免一写就阻塞
go func() {
    select {
    case ch <- 42:
    case <-time.After(1 * time.Second):
        // 超时处理，不卡住
    }
}()
// 接收端
select {
case v := <-ch:
fmt.Println(v)
case <-time.After(1 * time.Second):
fmt.Println("timeout")
}

测试阶段用 goleak 卡死泄漏，别等上线才看 runtime.NumGoroutine()

runtime.NumGoroutine() 只能告诉你“数量涨了”，但不知道哪来的、为什么没退。而 goleak 能直接定位到泄漏 goroutine 的启动栈，是测试期最有效的守门员。

• 单元测试加 defer goleak.VerifyNone(t)，失败时立刻打印泄漏 goroutine 的完整调用链
• 整个包测试用 TestMain + goleak.VerifyTestMain(m)，避免跨测试函数的残留干扰
• 注意：不能和 t.Parallel() 混用，否则会误报——并行测试请统一走 VerifyTestMain
• 忽略标准库 goroutine 用 goleak.IgnoreTopFunction("runtime.gopark")，但别滥用，先确认是不是真无关

最常被忽略的一点：第三方库（比如 sql.DB、http.Client、日志上报器）内部启动的 goroutine，不会因为你 main 函数结束就自动停。它们往往需要显式调用 Close() 或 Stop()。查文档，别假设。