goroutine泄漏指协程因阻塞或死锁无法退出，持续占用资源；2. 示例中无缓冲通道未被接收导致发送goroutine永久阻塞。
Go语言中的goroutine泄漏是常见但容易被忽视的问题。虽然goroutine轻量，但如果创建后未能正确退出，长时间运行的程序可能耗尽内存或调度器资源。下面通过实际示例介绍如何检测和排查goroutine泄漏。
什么是goroutine泄漏
当一个goroutine被启动后，由于通道读写阻塞、死锁、循环未退出等原因，无法正常结束执行，就形成了泄漏。这些“僵尸”goroutine会一直占用内存和调度资源。
例如：
func main() {
ch := make(chan int)
go func() {
val := <-ch
fmt.Println("Received:", val)
}()
// 忘记向ch发送数据，goroutine永远阻塞
time.Sleep(2 * time.Second)
}
这个例子中，子goroutine等待从无缓冲通道接收数据，但主函数没有发送，导致该goroutine永不退出。
立即学习“go语言免费学习笔记（深入）”；
使用pprof检测goroutine数量
Go内置的net/http/pprof包可用于观察当前运行的goroutine数量。
步骤如下：
- 导入pprof：在main中加入 import _ "net/http/pprof"
- 启动HTTP服务：go func() { log.Println(http.ListenAndServe("localhost:6060", nil)) }()
- 运行程序后访问 http://localhost:6060/debug/pprof/goroutine
可查看当前活跃的goroutine堆栈。例如添加查询参数?debug=1，输出更易读。
命令行也可用：
go tool pprof http://localhost:6060/debug/pprof/goroutine (pprof) top
若发现goroutine数量持续增长，基本可判定存在泄漏。
模拟泄漏与修复示例
考虑一个常见的错误模式：从通道读取直到关闭，但生产者未关闭通道。
func leakyWorker() {
ch := make(chan string)
go func() {
for msg := range ch {
fmt.Println(msg)
}
}()
// 忘记 close(ch)，worker永远等待
}
修复方式很简单：确保发送方在完成时关闭通道。
go func() {
ch <- "hello"
close(ch)
}()
另一个常见场景是select配合超时，但未处理default或未退出循环：
go func() {
for {
select {
case <-time.After(1 * time.Second):
// 定时任务
}
// 缺少退出条件
}
}()
应引入上下文控制生命周期：
go func(ctx context.Context) {
ticker := time.NewTicker(1 * time.Second)
defer ticker.Stop()
for {
select {
case <-ticker.C:
fmt.Println("tick")
case <-ctx.Done():
return
}
}
}(context.Background())
使用GODEBUG检测异常增长
运行程序时设置环境变量：
GODEBUG=gctrace=1,goprobe=1 ./your-app
或启用goroutine分析：
GODEBUG=gcshrinkstackoff=1
更直接的是使用-race检测数据竞争，有时并发问题间接导致goroutine阻塞。
也可在代码中主动检查：
n := runtime.NumGoroutine()
fmt.Printf("当前goroutine数量: %d\n", n)
在关键路径打印数量变化，有助于定位泄漏点。
基本上就这些。关键是养成习惯：每个启动的goroutine都要明确退出路径，优先使用context控制生命周期，结合pprof定期检查。不复杂但容易忽略。
