本文解析 go 程序中看似“goroutine 泄漏”的现象，指出其本质常是竞态导致的统计时机偏差，并通过代码示例说明如何正确等待协程退出、避免误判内存泄漏。
本文解析 go 程序中看似“goroutine 泄漏”的现象，指出其本质常是竞态导致的统计时机偏差，并通过代码示例说明如何正确等待协程退出、避免误判内存泄漏。
在 Go 开发中，调用 runtime.NumGoroutine() 返回值异常（如预期 1 却显示 3）常被误认为存在 goroutine 泄漏。但真实情况往往并非内存泄漏，而是竞态条件（race condition）下对 goroutine 生命周期的误判。
以原始代码为例：主循环中启动 10 个 goroutine 向带缓冲通道 ch 发送数据，同时用 select 配合 time.Tick 实现超时控制。问题核心在于：
- time.Tick(1 * time.Second) 创建的是永不关闭的 ticker，其底层 goroutine 会持续运行直至程序退出；
- 更关键的是，10 个 worker goroutine 执行 time.Sleep(2 * time.Second) 后才尝试写入 ch，而主 goroutine 的 select 循环仅执行 10 次（每次最多等待 1 秒），实际只能接收 ≤8 个值（因超时触发 2 次），剩余至少 2 个 goroutine 仍在 Sleep 中阻塞——它们尚未结束，NumGoroutine() 自然将其计入。
因此，输出 3 通常包含：
- 1 个 main goroutine
- 1 个 time.Tick 内部 goroutine（长期存活）
- 1+ 个尚未完成 Sleep 并写入 channel 的 worker goroutine
这并非泄漏，而是生命周期未同步的正常现象。若强制等待所有 goroutine 结束，结果将符合预期：
package main
import (
"log"
"runtime"
"sync"
"time"
)
func main() {
for round := 1; round <= 1; round++ { // 简化为单轮便于观察
ch := make(chan int, 10)
var wg sync.WaitGroup
// 启动 10 个 goroutine，使用 WaitGroup 跟踪
for i := 1; i <= 10; i++ {
wg.Add(1)
go func(i int) {
defer wg.Done()
time.Sleep(2 * time.Second)
select {
case ch <- i:
default: // 避免阻塞（若 channel 已满且无人接收）
}
}(i)
}
// 接收最多 10 个值，或超时退出
timeout := time.After(3 * time.Second) // 延长超时，确保能覆盖 Sleep
for i := 1; i <= 10; i++ {
select {
case j := <-ch:
log.Println("received:", j)
case <-timeout:
log.Println("timeout, stopping receive")
goto drain // 跳出接收循环
}
}
drain:
// 关闭 channel 并等待所有 goroutine 完成
close(ch)
wg.Wait()
// 此时所有 worker 已退出，Ticker 仍存在 —— 若需彻底清理，应使用 time.NewTimer 或手动 stop
log.Println("Active goroutines:", runtime.NumGoroutine())
}
}⚠️ 关键注意事项：
- time.Tick 不可关闭，其 goroutine 会伴随程序整个生命周期；生产环境推荐使用 time.NewTimer + timer.Stop() 或 time.AfterFunc 替代；
- 切勿依赖 NumGoroutine() 判断泄漏——它仅反映瞬时数量，无法区分“活跃”与“即将退出”；
- 真正的 goroutine 泄漏典型特征：goroutine 数量随时间单调递增（如每秒增长），且对应协程因 channel 阻塞、锁等待或无限循环而永远无法退出；
- 调试泄漏首选工具：pprof（net/http/pprof）查看 goroutine profile，配合 -debug=2 启动参数获取堆栈信息。
总结：NumGoroutine() 显示异常 ≠ 内存泄漏。应结合同步原语（sync.WaitGroup）、可取消的定时器（context.WithTimeout + time.AfterFunc）及 pprof 分析，才能准确定位和解决真正的协程泄漏问题。
