goroutine 漏了

一个 goroutine 的栈才 2KB，一万个也就 20MB——真正吃掉内存的是它手里攥着的东西。GC 从卡住的 goroutine 出发还能走到那些对象，就一个都不敢回收。所以现象往往是：内存曲线爬坡、goroutine 数曲线也爬坡，重启就好，跑三天就 OOM。

四种长得不一样，症状是同一个：栈顶永远停在 chan send / chan receive / select / semacquire。看 pprof 时，认这几个词就够了。

func fetch(url string) string {

    ch := make(chan string)
    go func() {
        ch <- get(url)  // 超时后没人收
    }()                 // 卡死在这一行

    select {
    case r := <-ch:
        return r
    case <-time.After(time.Second):
        return "timeout"
    }
}  // 函数返回了，goroutine 没有

func fetch(ctx context.Context,
           url string) string {
    ch := make(chan string, 1)
    go func() {
        ch <- get(url)  // 缓冲里一放
    }()                 // 立刻收工

    select {
    case r := <-ch:
        return r
    case <-ctx.Done():
        return "timeout"
    }
}  // 两个都能走掉

这是线上最经典的一例：接口 QPS 1000、超时率 2%，一分钟就漏 1200 个 goroutine，一天下来一百多万。而修复只是给 channel 加一格缓冲——让发送方不必等人接。

1. 1

   装监控先把探头挂上，只多两行。

   import _ "net/http/pprof" go func() { http.ListenAndServe("localhost:6060", nil) }()
2. 2

   数一下第一行就是总数，不用打开任何界面。

   $ curl -s 'localhost:6060/debug/pprof/goroutine?debug=1' | head -1 goroutine profile: total 40213
3. 3

   隔五分钟再数涨了才是泄漏。只是「数字大」不算——高并发服务本来就几万个。

   # 40213 → 47986 → 55702，斜率稳定 = 确诊
4. 4

   存两份快照要的是「多出来的那批」，不是全部。

   $ curl -so t1.pb.gz 'localhost:6060/debug/pprof/goroutine' $ sleep 300 $ curl -so t2.pb.gz 'localhost:6060/debug/pprof/goroutine'
5. 5

   只看差量-base 把老底子减掉，剩下的就是这五分钟新漏的。

   $ go tool pprof -http=:8080 -base t1.pb.gz t2.pb.gz
6. 6

   看完整栈debug=2 会把每个 goroutine 的状态和已经等了多久都写出来。等了 12 分钟的那一堆，就是嫌疑人。

   $ curl -s 'localhost:6060/debug/pprof/goroutine?debug=2' > g.txt $ grep -c 'chan receive' g.txt