Golang如何避免goroutine泄漏_网络技术_宿州市腾雀网络科技有限公司

Go 中 goroutine 泄漏指 goroutine 启动后因阻塞在 select 等操作上而永不终止，并非内存未释放。

Go 里 goroutine 泄漏不是“内存没释放”，而是 goroutine 启动了却永远卡在 select、 或 time.Sleep 上，既不退出也不被回收——它持续占着栈内存和调度资源，积少成多就会拖垮服务。

goroutine 泄漏最常见原因：没给退出信号。比如一个后台轮询任务，写成无限循环却不检查是否该停：

go func() {
    for { // 没有退出条件 → 泄漏
        doWork()
        time.Sleep(5 * time.Second)
    }
}()

正确做法是把 ctx.Done() 塞进 select，并确保上层调用方能主动 cancel()：

向无接收者的 channel 发送数据、从永不关闭的 channel 接收数据，都会永久阻塞——这是泄漏高发区。

立即学习“go语言免费学习笔记（深入）”；

靠线上报警发现泄漏太晚。单元测试里就要卡住它：

runtime.NumGoroutine() 是最轻量的探测器，但需注意：系统 goroutine 本身会波动，建议 sleep 后多采样一次，或用 time.AfterFunc 等待更久
直接集成 uber-go/goleak：在 TestMain 里加 goleak.VerifyNone(m)，它会自动扫描测试前后新增且未退出的 goroutine，并打出初始调用栈
避免在测试中用 time.Sleep 硬等——改用 sync.WaitGroup 或 context.WithTimeout 显式等待完成
HTTP handler 测试时，记得触发 http.Close() 或用 httptest.NewUnstartedServer 控制生命周期

线上发现 runtime.NumGoroutine() 持续上涨？下一步不是重启，是抓现场：

启用 net/http/pprof 后访问 http://localhost:6060/debug/pprof/goroutine?debug=2，看完整调用栈
重点关注状态为 chan receive、select、semacquire 且栈帧集中在你代码某几行的 goroutine
用 go tool pprof 下载两个时间点的快照，执行 diff -base 找出新增 goroutine 的共性栈路径
别只信 “goroutine 数量”，要结合 debug.ReadGCStats 看 NumGoroutine 是否与 GC 次数强相关——若 GC 频繁但 goroutine 不降，基本坐实泄漏

真正难防的泄漏，往往藏在“它应该会停”的假设里：比如以为某个 channel 肯定会被关闭，或某个 HTTP 连接肯定会断。实际得靠 context 显式传递取消信号、用 goleak 在 CI 里卡住测试、再用 pprof 快照定位到具体哪一行 select 卡死了——这三步缺一不可。