Go 语言 Goroutine 泄露：实战案例分析与排查指南

三月 1, 2026

技术

在 Go 语言开发中，Goroutine 泄露是一个非常隐蔽但致命的问题。它通常发生在一个 Goroutine 被启动后，因为某种逻辑阻塞（比如等待一个永远不会关闭的 Channel 或获取不到锁）而永远无法结束，导致内存逐渐耗尽。

和内存泄漏不同，Goroutine 泄露更难发现——因为 Goroutine 本身占用很小（通常只有几 KB），但成千上万个泄露的 Goroutine 会形成"蚂蚁搬家"效应，最终拖垮整个服务。

本文将分享 4 个实战中非常典型的 Goroutine 泄露案例，并提供排查工具和预防原则。

1. 典型的 Channel 阻塞泄露

这是最常见的场景：发送者在等待接收者，但接收者因为某种逻辑提前退出了。

案例代码

func handleRequest() {
    ch := make(chan int) // 注意：这是一个无缓冲 Channel

    go func() {
        val := doSomeWork()
        ch <- val // 如果外层函数提前返回，这里将永久阻塞
    }()

    // 模拟某种超时或错误判断
    if err := validate(); err != nil {
        return // 逻辑退出，Goroutine 泄露！
    }

    fmt.Println(<-ch)
}

泄露原因

ch 是无缓冲 Channel。当 validate() 返回错误时，主函数直接结束，不再有人从 ch 中读取数据。后台的子 Goroutine 会一直卡在 ch <- val 这一行，永远等待一个永远不会到来的接收者。

解决方案

方案一：使用有缓冲 Channel

ch := make(chan int, 1) // 缓冲容量为 1

即使没人接收，发送操作也能完成（写入缓冲区后返回），不会阻塞。

方案二：使用 Context 控制

func handleRequest(ctx context.Context) {
    ch := make(chan int)

    go func() {
        defer close(ch) // 确保退出时关闭 Channel
        val := doSomeWork()
        select {
        case ch <- val:
        case <-ctx.Done():
            return // 收到取消信号时退出
        }
    }()

    if err := validate(); err != nil {
        return // 子 Goroutine 会通过 ctx.Done() 感知到退出
    }

    fmt.Println(<-ch)
}

2. 只有发送没有接收的"僵尸"协程

这种情况常出现在并发任务分发中，如果逻辑分支覆盖不全，就会留下"尾巴"。

案例：并发请求取最快结果

func getFirstResponse() string {
    ch := make(chan string)

    // 启动三个协程去请求
    for i := 0; i < 3; i++ {
        go func() {
            ch <- fetchData() // 发送后等待接收
        }()
    }

    return <-ch // 只取第一个回来的结果
}

诊断结果

在这个例子中，每调用一次 getFirstResponse()，就会泄露 2 个 Goroutine：

第一个 fetchData() 返回后，值被 <-ch 消费，发送端正常退出
剩下两个 Goroutine 永远卡在 ch <- fetchData()，等待一个永远不会到来的接收者

随着请求量的增加，Goroutine 数量会呈线性增长，内存占用（RSS）也会持续攀升。

解决方案

方案一：使用带缓冲的 Channel

func getFirstResponse() string {
    ch := make(chan string, 3) // 缓冲大小等于 Goroutine 数量

    for i := 0; i < 3; i++ {
        go func() {
            ch <- fetchData()
        }()
    }

    return <-ch
}

方案二：使用 select + default 避免阻塞

func getFirstResponse() string {
    ch := make(chan string)

    for i := 0; i < 3; i++ {
        go func() {
            select {
            case ch <- fetchData():
            default:
                // 如果 Channel 满了，直接退出，不阻塞
            }
        }()
    }

    return <-ch
}

3. time.Ticker 忘记 Stop

虽然 time.After 在触发后会被自动回收，但 time.NewTicker 如果不手动调用 Stop()，它持有的资源和相关的底层协程不会立即释放。

案例代码

func watch(ctx context.Context) {
    ticker := time.NewTicker(1 * time.Second)

    for {
        select {
        case <-ctx.Done():
            // 错误：这里直接 return，没有调用 ticker.Stop()
            return
        case <-ticker.C:
            doSomething()
        }
    }
}

后果

虽然 Go 1.23+ 对定时器做了很多优化，但在老版本中：

频繁创建 Ticker 而不关闭，会导致底层定时器堆积
增加 GC 扫描负担
在高并发场景下，变相导致资源泄露

解决方案

始终记得使用 defer：

func watch(ctx context.Context) {
    ticker := time.NewTicker(1 * time.Second)
    defer ticker.Stop() // 确保退出时释放

    for {
        select {
        case <-ctx.Done():
            return
        case <-ticker.C:
            doSomething()
        }
    }
}

4. 互斥锁（Mutex）死锁导致的泄露

如果一个 Goroutine 在尝试获取锁时发生死锁，它也会永远停留在运行队列中，无法被 GC 回收。

案例代码

func worker(mu *sync.Mutex) {
    mu.Lock()
    defer mu.Unlock()

    // 如果这里发生了 panic 且没被 recover
    // 或者存在一种逻辑让代码执行不到 Unlock
    if condition {
        return // 忘记解锁，或者在没有 defer 的情况下直接返回
    }

    doSomething()
}

泄露表现

虽然这更像是逻辑死锁，但从监控上看：

Goroutine 数量会因为后续任务不断进入并卡在 Lock() 处而飙升
泄露的 Goroutine 持有 Mutex 锁，导致更多 Goroutine 形成等待链
最终导致服务完全不可用

解决方案

始终坚持使用 defer unlock
避免在锁内执行阻塞操作
使用errgroup 或 context 控制超时

func worker(ctx context.Context, mu *sync.Mutex) {
    mu.Lock()
    defer mu.Unlock()

    // 使用 context 控制耗时操作
    select {
    case <-ctx.Done():
        return
    default:
        doSomething()
    }
}

5. 如何排查 Goroutine 泄露？

pprof：排查泄露的"银弹"

通过访问 /debug/pprof/goroutine?debug=1，你可以看到当前所有 Goroutine 的堆栈信息。

诊断步骤：

看数量：如果 runtime.numGoroutine 持续增长不下降，基本确定泄露
看堆栈：如果发现成千上万个 Goroutine 都卡在同一行代码（如 chan send），那就是泄露源

使用示例：

import _ "net/http/pprof"

func main() {
    go func() {
        http.ListenAndServe(":6060", nil)
    }()
    // 访问 http://localhost:6060/debug/pprof/goroutine?debug=1
}

命令行分析：

# 导出 Goroutine 数据
go tool pprof http://localhost:6060/debug/pprof/goroutine

# 查看 Top Goroutine
(pprof) top10

# 查看调用关系
(pprof) traces

6. 预防原则

设计原则

谁启动，谁负责关闭
- 启动一个 Goroutine 时，必须明确知道它什么时候会结束
- 如果不确定，使用 context 或 errgroup 管理生命周期
使用 Context
- 在现代 Go 开发中，尽量将 context.Context 传递给所有耗时任务
- 通过 ctx.Done() 或 ctx.Err() 通知子协程退出
警惕无缓冲 Channel
- 除非你确定读写双方的步调完全一致
- 否则优先考虑带缓冲的 Channel：make(chan T, 1) 或 make(chan T, 1024)
- 或使用 select 配合超时处理
资源释放要 defer
- 始终在创建资源后立即 defer 释放：defer ticker.Stop()、defer file.Close()

代码审查清单

启动的 Goroutine 是否有明确的退出机制？
Channel 是否都有对应的接收者？
使用 time.NewTicker 后是否调用了 Stop()？
使用 defer 确保锁、文件等资源释放？
是否使用 context 控制超时和取消？

总结

Goroutine 泄露是 Go 开发中的"隐形杀手"。它不像内存泄漏那样显而易见，而是通过 Goroutine 数量的缓慢累积，最终在某个临界点爆发。

核心要点：

场景	预防措施
Channel 阻塞	使用缓冲 Channel 或 select + default
并发任务泄露	确保所有任务都有对应的退出机制
Ticker 泄露	始终使用 defer ticker.Stop()
Mutex 死锁	坚持使用 defer unlock
排查工具	pprof + 监控 Goroutine 数量

你想针对某个具体的业务场景（比如数据库连接池、Web 接口）让我帮你做一次 Goroutine 泄露的代码审查吗？