Go：context —— goroutine 泄漏是怎么发生的

先看一个 bug —— 它长得非常正常

// 一个「先返回最快的那个」的经典实现
func fastest(urls []string) string {
    ch := make(chan string)          // ← 无缓冲

    for _, url := range urls {       // 假设有 3 个 url
        go func() {
            ch <- fetch(url)         // 各自去抓,谁快谁先写进 ch
        }()
    }

    return <-ch                      // 拿到第一个就返回!
}

看起来很聪明，也确实能工作：它返回最快的那个结果。

但它每调用一次，就泄漏两个 goroutine。永久地。

两种修法

// ✅ 修法一:给 channel 加缓冲,让所有人都能发完就走
func fastest(urls []string) string {
    ch := make(chan string, len(urls))   // ← 缓冲 = goroutine 数
    for _, url := range urls {
        go func() { ch <- fetch(url) }()  // 现在谁都不会阻塞
    }
    return <-ch    // 慢的那两个把结果写进缓冲,然后正常退出。
}                  // 结果没人读,但 goroutine 死了,内存会被回收。

// ✅ 修法二(更好):用 context 真的把它们取消掉
func fastest(ctx context.Context, urls []string) string {
    ctx, cancel := context.WithCancel(ctx)
    defer cancel()                       // ← 函数一返回,就取消所有子请求

    ch := make(chan string, len(urls))
    for _, url := range urls {
        go func() {
            ch <- fetchWithCtx(ctx, url)  // ctx 取消 → 这个 HTTP 请求真的会被中断
        }()
    }
    return <-ch
}
// 修法二不只是「不泄漏 goroutine」,它还【真的停掉了那两个网络请求】——
// 省下了带宽,也省下了下游服务的负载。

五种泄漏姿势

select {
case ch <- v:
case <-ctx.Done():
    return    // 没人要了,我走
}

context：Go 的取消机制

// context 的全部 API,就这四个方法:
type Context interface {
    Done() <-chan struct{}    // 一个 channel。取消时它会被【close】
    Err() error               // 为什么取消的:Canceled / DeadlineExceeded
    Deadline() (time.Time, bool)
    Value(key any) any        // ← 这个方法是个后悔药,见下
}

// 关键洞察:取消信号就是【一个被 close 的 channel】。
// 因为 close 会让【所有】等待的接收方同时被唤醒 —— 这是天然的广播机制。

正确的用法

func handler(w http.ResponseWriter, r *http.Request) {
    ctx := r.Context()      // ← HTTP 框架已经给了你一个 ctx
                            //    客户端断开连接时,它会被自动取消!

    ctx, cancel := context.WithTimeout(ctx, 3*time.Second)
    defer cancel()          // ← 【永远写这一行】

    result, err := doWork(ctx)   // ctx 一路传下去
    ...
}

func doWork(ctx context.Context) (Result, error) {
    // ① 传给会阻塞的调用
    req, _ := http.NewRequestWithContext(ctx, "GET", url, nil)
    resp, err := http.DefaultClient.Do(req)   // ctx 取消 → 这个请求真的会被中断

    // ② 在长循环里检查
    for _, item := range items {
        select {
        case <-ctx.Done():
            return nil, ctx.Err()    // 被取消了,赶紧走
        default:
        }
        process(item)
    }

    // ③ 传给数据库
    rows, err := db.QueryContext(ctx, "SELECT ...")   // 用带 Context 的版本!
    ...
}

func slowWork(ctx context.Context) {
    time.Sleep(10 * time.Second)   // ❌ 它不知道 ctx 是什么。
}                                   //    取消?没门。这 10 秒必须走完。

// ✅
func slowWork(ctx context.Context) error {
    select {
    case <-time.After(10 * time.Second):
        return nil
    case <-ctx.Done():
        return ctx.Err()            // 可以被取消了
    }
}

// ❌ context 不是一个「万能背包」
ctx = context.WithValue(ctx, "userID", 42)
ctx = context.WithValue(ctx, "db", dbConn)         // ❌❌❌
ctx = context.WithValue(ctx, "config", cfg)        // ❌❌❌

func doWork(ctx context.Context) {
    db := ctx.Value("db").(*sql.DB)   // 运行时类型断言 —— 编译器帮不了你
    // 这个函数的【真实依赖】,在签名上一个字都看不出来。
}

errgroup：Go 最接近「结构化并发」的东西

import "golang.org/x/sync/errgroup"

func fetchAll(ctx context.Context, urls []string) ([]Result, error) {
    g, ctx := errgroup.WithContext(ctx)   // ← 注意:它返回一个【新的 ctx】
    g.SetLimit(10)                        // 限流:最多 10 个并发

    results := make([]Result, len(urls))

    for i, url := range urls {            // Go 1.22+:循环变量按轮独立,不用再 i := i
        g.Go(func() error {
            r, err := fetch(ctx, url)
            if err != nil {
                return err                // ← 【任何一个返回 error】
            }                             //    → ctx 被取消 → 其他所有 fetch 立刻中断
            results[i] = r                //    各写各的下标 —— 不需要锁
            return nil
        })
    }

    if err := g.Wait(); err != nil {      // 等所有 goroutine 结束
        return nil, err                   // 返回【第一个】错误
    }
    return results, nil
}

怎么抓住泄漏

① 生产环境：pprof

import _ "net/http/pprof"        // 就这一行,它会自动注册 handler

func main() {
    go func() {
        log.Println(http.ListenAndServe("localhost:6060", nil))
    }()
    // ... 你的服务
}

# 看当前有多少个 goroutine
$ curl -s localhost:6060/debug/pprof/goroutine?debug=1 | head -1
goroutine profile: total 10523        # ← 10523 个?!你只有 8 个核。

# 看它们卡在哪(按栈聚合,这是最有用的视图)
$ curl -s "localhost:6060/debug/pprof/goroutine?debug=1"

goroutine profile: total 10523
10000 @ 0x43c5f6 0x40c8fb 0x40c8d5 0x7a3d4c 0x46d001
#     ^^^^^^ 一万个 goroutine 卡在【同一个地方】—— 找到凶手了
#	main.fetchAll.func1(...)
#		/app/fetch.go:42 +0x8c        ← 就是这一行
#	created by main.fetchAll
#		/app/fetch.go:40 +0x105

# 【关键诊断】:如果一个栈上聚集了成千上万个 goroutine,那就是泄漏点。

② 测试环境：goleak

import "go.uber.org/goleak"

func TestMain(m *testing.M) {
    goleak.VerifyTestMain(m)     // ← 就这一行
}
// 每个测试跑完后,它会检查有没有 goroutine 还活着。
// 有 → 测试失败,并打印出它的栈。

// 单个测试:
func TestFetch(t *testing.T) {
    defer goleak.VerifyNone(t)
    ...
}

③ 监控：把 goroutine 数量画成曲线

// 暴露成 Prometheus 指标
runtime.NumGoroutine()

// 你要看的是【趋势】,不是绝对值:
//   · 平稳波动     → 健康
//   · 单调上升,永不回落 → 【泄漏】。而且这条曲线会一路涨到 OOM。
//
// 这条曲线是 Go 服务最重要的监控指标之一,甚至比 CPU 和内存更早报警。

下一章：三门语言都讲完了。现在给它们出同一道题，逐行对照。你会发现差异不在语法上 —— 在「谁替你管生命周期」这件事上。