Go 避免协程 Goroutine 泄露的措施

引言

在 Golang 并发编程中，Goroutine 以轻量、高效著称，一句 go func() 就能轻松创建协程。

但如果忽略协程的退出逻辑，很容易导致 Goroutine 泄露—— 即协程无法正常退出，一直占用系统内存和调度资源。​

这种泄露在短时间内可能不明显，但长期运行的服务中，泄露的 Goroutine 会持续累积，最终导致内存飙升、CPU 使用率异常，甚至引发服务崩溃。

今天就来分享 5 个实战中验证有效的措施，帮你从根源避免 Goroutine 泄露。

避免 Goroutine 泄露的措施

（一）正确关闭通道

正确关闭通道：避免发送 / 接收方阻塞。

通道（channel）是 Goroutine 间通信的核心，但如果使用不当，很容易导致 Goroutine 永久阻塞。

关键原则是：明确通道的关闭责任方，避免 “发送方一直发，接收方已退出” 或反之。​

反例（泄露场景）：

func leakDemo() {
    ch := make(chan int)
    // 启动协程发送数据，但无人接收
    go func() {
        for i := 0; i ++ {
            ch  i // 发送方阻塞，协程无法退出
        }
    }()
    // 函数退出后，ch 未关闭，发送方协程一直阻塞
}

正例（正确关闭通道）：​

接收方明确知道接收次数，用 range 接收（通道关闭后自动退出）​

func correctChannel1() {
    ch := make(chan int, 5)
    // 发送方：发送完成后关闭通道
    go func() {
        for i := 0; i  i++ {
            ch         close(ch) // 发送方完成后关闭通道
    }()
    // 接收方：用 range 接收，通道关闭后自动退出
    go func() {
        for num := range ch {
            fmt.Println("接收数据：", num)
        }
        fmt.Println("接收方协程正常退出")
    }()
    time.Sleep(time.Second)
}

（二）使用 Context

使用 Context 控制协程生命周期

context.Context 是 Golang 官方提供的协程生命周期管理工具，支持 “取消信号”“超时控制”，尤其适合嵌套协程场景。

核心是：父协程通过 Context 向子协程传递退出信号，子协程监听信号并退出。​

示例（超时控制避免泄露）：

func useContextDemo() {
    // 创建带 1 秒超时的 Context
    ctx, cancel := context.WithTimeout(context.Background(), 1*time.Second)
    defer cancel() // 确保资源释放

    go func() {
        for {
            select {
            case ctx.Done():
                // 收到超时/取消信号，协程退出
                fmt.Println("协程退出，原因：", ctx.Err())
                return
            default:
                // 模拟业务逻辑
                fmt.Println("协程运行中...")
                time.Sleep(200 * time.Millisecond)
            }
        }
    }()

    time.Sleep(1500 * time.Millisecond)
}

关键说明：​

• 当 ctx.Done() 触发时，子协程必须主动退出（避免阻塞）​

• 嵌套协程场景中，可通过 context.WithCancel(parentCtx) 传递信号，实现 “一键取消所有子协程”​

（三）避免通道单向阻塞​

避免无缓冲通道的单向阻塞​。

无缓冲通道（unbuffered channel）的发送和接收是 “同步” 的 —— 发送方会阻塞到接收方接收数据，反之亦然。

如果一方未准备好，就会导致 Goroutine 永久阻塞。​

反例（无缓冲通道泄露）：

func unbufferedLeak() {
    ch := make(chan int) // 无缓冲通道
    go func() {
        ch 方阻塞，等待接收方接收
    }()
    // 忘记启动接收方，发送方协程永久阻塞
}

正例（避免单向阻塞）：​

• 场景 1：明确双方都准备好，再使用无缓冲通道​

• 场景 2：用带缓冲通道（buffered channel），避免同步阻塞

func bufferedCorrect() {
    ch := make(chan int, 1) // 带 1 个缓冲的通道
    go func() {
        ch  1 // 发送方不会阻塞（缓冲未满）
    }()
    // 后续接收数据（即使延迟，也不会导致发送方阻塞）
    go func() {
        num :=  fmt.Println("接收数据：", num)
    }()
    time.Sleep(time.Second)
}

（四）用 WaitGroup

用 WaitGroup 等待协程批量完成​。

当需要启动多个协程并行执行，且主协程需等待所有子协程完成后再退出时，sync.WaitGroup 是最佳选择 —— 它能避免 “主协程提前退出，子协程成为孤儿协程”。​

示例（WaitGroup 正确用法）：

func waitGroupDemo() {
    var wg sync.WaitGroup
    taskCount := 3

    // 启动 3 个协程执行任务
    for i := 0; i  {
        wg.Add(1) // 每启动一个协程，计数器 +1
        go func(taskID int) {
            defer wg.Done() // 协程退出前，计数器 -1
            fmt.Printf("任务 %d 执行中...\n", taskID)
            time.Sleep(500 * time.Millisecond)
            fmt.Printf("任务 %d 完成\n", taskID)
        }(i)
    }

    wg.Wait() // 主协程阻塞，等待所有子协程完成
    fmt.Println("所有任务执行完毕，主协程退出")
}

关键注意点：​

• wg.Add(n) 必须在协程启动前调用（避免协程先退出导致 wg.Done() 早于 wg.Add()）​

• 子协程中必须调用 wg.Done()（即使发生错误，也要用 defer 确保执行）​

（五）监控协程数量

监控协程数量：及时发现泄露迹象​。

Golang 提供 runtime.NumGoroutine() 函数，可获取当前运行的 Goroutine 数量。在服务中定期监控该数值，若发现持续增长，大概率存在泄露。​

示例（监控协程数量）：

func monitorGoroutine() {
    // 定期打印协程数量
    go func() {
        ticker := time.NewTicker(2 * time.Second)
        defer ticker.Stop()
        for range ticker.C {
            fmt.Printf("当前 Goroutine 数量：%d\n", runtime.NumGoroutine())
        }
    }()

    // 模拟业务协程
    go func() {
        time.Sleep(5 * time.Second)
    }()

    time.Sleep(10 * time.Second)
}

常见问题

Q1. 协程泄露会有哪些具体影响？​

• 内存占用持续升高：每个 Goroutine 默认占用 2KB 栈内存（可动态扩容），泄露过多会导致 OOM；​

• CPU 调度压力增大：系统需持续调度泄露的 Goroutine，导致正常业务协程调度延迟；​

• 服务稳定性下降：长期运行后可能触发系统资源限制，导致服务崩溃。​

Q2. 如何快速排查 Goroutine 泄露？​

• 用 runtime.NumGoroutine() 监控数量变化；​

• 结合 pprof 工具分析 Goroutine 堆栈；​

• 重点排查：未关闭的通道、未监听的 Context、无缓冲通道的单向阻塞场景。​

Q3. Context 和 WaitGroup 该怎么选？​

• 用 WaitGroup：主协程需等待所有子协程完成（如批量任务执行）；​

• 用 Context：需要主动取消协程（如超时、用户取消操作）、嵌套协程场景；​

• 混合使用：复杂场景中，可通过 Context 传递取消信号，WaitGroup 等待子协程优雅退出。​

总结​

Goroutine 泄露的核心原因是 “协程缺乏明确的退出条件”—— 要么阻塞在通道操作上，要么陷入无限循环。避免泄露的关键的是：​

1. 明确通道的关闭责任，避免单向阻塞。

2. 用 Context 控制协程生命周期，支持超时 / 取消。

3. 批量协程场景用 WaitGroup 同步等待。

4. 定期监控 runtime.NumGoroutine()，及时发现异常。

7. ​

这些措施在实际开发中简单易落地，只要养成 “创建协程时就考虑退出逻辑” 的习惯，就能大幅降低泄露风险，保障 Golang 服务的稳定性。​

如果大家关于 Go 协程泄露的措施还有哪些不清楚的地方，欢迎大家在评论区交流～～～