本文解析因未正确处理goroutine生命周期导致的“伪内存泄漏”现象，重点说明runtime.numgoroutine()异常偏高并非真正泄漏，而是竞态下goroutine尚未退出所致，并提供可复现的验证方式与健壮写法。
本文解析因未正确处理goroutine生命周期导致的“伪内存泄漏”现象，重点说明runtime.numgoroutine()异常偏高并非真正泄漏，而是竞态下goroutine尚未退出所致，并提供可复现的验证方式与健壮写法。
在Go程序中，观察到runtime.NumGoroutine()返回值持续高于预期（如示例中循环结束后仍为3而非1），常被误认为存在goroutine泄漏。但实际案例中，这往往不是内存泄漏，而是一种时序竞态（race condition）导致的观测偏差。
关键问题出在以下逻辑：
go func(i int) {
time.Sleep(2 * time.Second) // ① goroutine休眠2秒
ch <- i // ② 然后尝试发送到带缓冲的channel
}(i)虽然ch是容量为10的缓冲通道，且主goroutine仅循环接收10次，看似能全部收完——但注意：time.Tick(1 * time.Second)创建的timeout通道每秒触发一次，而主goroutine的select语句在超时后直接进入下一轮循环，并不等待所有goroutine完成。当timeout在第1秒和第2秒触发两次（即发生2次"timeout"日志），意味着有2个goroutine的ch <- i操作永远无法执行——因为它们仍在Sleep中，而主goroutine已退出该轮for循环，且ch作用域结束，后续无任何goroutine再从该channel接收数据。
此时，这2个goroutine会永久阻塞在ch <- i上（向已无接收者的满缓冲channel发送），成为“僵尸goroutine”，直到程序退出。这就是NumGoroutine()显示为3（1个main + 2个阻塞goroutine）的根本原因。
立即学习“go语言免费学习笔记（深入）”；
✅ 正确做法：使用同步机制确保所有goroutine安全退出。推荐使用sync.WaitGroup：
package main
import (
"log"
"runtime"
"sync"
"time"
)
func main() {
for round := 1; round <= 10; round++ {
ch := make(chan int, 10)
var wg sync.WaitGroup
// 启动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) // 总超时延长至3秒
for i := 0; i < 10; i++ {
select {
case j, ok := <-ch:
if ok {
log.Println("received:", j)
}
case <-timeout:
log.Println("round", round, "timeout")
goto cleanup
}
}
cleanup:
// 关闭channel并等待所有goroutine退出
close(ch)
wg.Wait()
log.Println("Processes", runtime.NumGoroutine())
}
}⚠️ 注意事项：
- 永远不要依赖time.Tick作为单次超时：它持续发送时间戳，应改用time.After；
- 避免向无人接收的channel发送：使用select+default非阻塞发送，或显式close(ch)后配合range接收；
- WaitGroup必须在goroutine内调用Done()，且Add()需在go前调用；
- runtime.NumGoroutine()仅作调试参考，不能替代pprof等专业分析工具判断真实泄漏。
总结：所谓“goroutine泄漏”，90%源于未合理协调并发生命周期。通过sync.WaitGroup、context取消、channel关闭约定等手段主动管理，才能写出真正健壮的Go并发代码。
