goroutine 泄漏的典型信号是内存持续上涨、NumGoroutine() 只增不减、pprof 显示大量 IO wait 或 chan receive 状态 goroutine；根本原因是本该退出的 goroutine 卡在阻塞操作且无人唤醒，需用 context.WithCancel 等确保所有路径调用 cancel。
goroutine 泄漏的典型信号是什么
程序内存持续上涨、runtime.NumGoroutine() 返回值只增不减、pprof 查看 /debug/pprof/goroutine?debug=2 显示大量处于 IO wait 或 chan receive 状态的 goroutine——这些是 goroutine 泄漏最直接的信号。
根本原因往往不是“开了太多 goroutine”，而是“本该退出的 goroutine 卡在了阻塞操作上，且无人唤醒或关闭”。常见于：未关闭的 channel 接收、无缓冲 channel 发送未被消费、time.Timer/Timer.Reset 后未 stop、http.Server.Shutdown 未等 handle 完成就返回。
- 用
select+default避免永久阻塞（适合非关键路径） - 所有 channel 操作必须有明确的关闭方和接收方生命周期对齐
- 启动 goroutine 前，确保它有明确的退出条件（如 context.Done()、done chan、超时控制）
context.WithCancel 是 goroutine 生命周期管理的核心
不要靠全局变量或标志位来通知 goroutine 退出。用 context.Context 是 Go 官方推荐且最可靠的方式，尤其搭配 context.WithCancel 或 context.WithTimeout。
关键点在于：cancel 函数必须在 ** 所有可能的退出路径 ** 上调用，包括 error return、defer、成功完成之后。漏掉一次，就可能泄漏一组 goroutine。
立即学习 “go 语言免费学习笔记（深入）”；
func doWork(ctx context.Context) {ch := make(chan int, 1) go func() { defer close(ch) // 确保 ch 关闭 select {case <-time.After(2 * time.Second): ch <- 42 case <-ctx.done():>select {case v := <-ch: fmt.println("got", v) case <-ctx.done(): return>}
channel 使用中三个高危陷阱
channel 是并发协作的枢纽，也是泄漏重灾区。以下行为极易引发泄漏：
- 向已关闭的 channel 发送数据 → panic，但若在 recover 中忽略，可能掩盖真实问题
- 从无缓冲 channel 接收，但发送方永不发送或已退出 → goroutine 永久挂起
- 用
for range ch遍历 channel，但 sender 忘记 close → range 永不结束
安全做法：
- channel 的 close 操作应由 sender 负责，且只能 close 一次
- receiver 应使用
val, ok := 判断是否关闭，而非依赖 range - 若需多路接收，优先用
select+ctx.Done()控制超时与退出
pprof 和 runtime.ReadMemStats 是定位泄漏的必备组合
仅靠日志或业务指标很难发现早期泄漏。必须定期采集运行时数据：
-
go tool pprof http://localhost:6060/debug/pprof/goroutine?debug=2查看活跃 goroutine 栈 -
go tool pprof http://localhost:6060/debug/pprof/heap查看堆内存分配峰值与对象数量 - 在关键路径调用
runtime.ReadMemStats(&ms)记录ms.NumGC和ms.HeapInuse，对比差值
特别注意：runtime.GC() 不解决泄漏，它只回收已不可达对象；如果 goroutine 还活着、还持有着 map/slice/struct 字段，对应内存就永远不会被释放。
真正难排查的，往往是那些“逻辑上该死却没死”的 goroutine——它们安静地占着内存和 fd，直到进程 OOM 或连接耗尽。
