为什么你的 Go 协程也会泄漏？一次十万 Goroutine 暴增引发的 OOM 血案复盘

前言的观点是。打工人的深夜噩梦

凌晨三点，手机疯狂震动。Promeus 告警轰炸：内存使用率 90%，Goroutine 数量 120000+。我从床上弹起来心里只有一个念头：完了又是 Goroutine 泄漏。不过，

作为基础架构组的老油条。我见过太多因为 Channel 使用不当导致的惨案。今天就用这次线上事故，带你手撕 Goroutine 泄漏的底层原理。顺便教你三招“优雅关闭 Channel”的绝活。

说到事故现场，十万协程是怎么炼成的

问题代码长这样

// 某消息处理服务的主要原因
type MessageProcessor struct {
taskChan chan *Task
}
func ProcessMessages {
for {
task := <-p.taskChan
        go p.handleTask // 每个任务起一个 Goroutine
    }
}
func  handleTask {
    result := doHeavyWork
    // 致命问题：向一个可能没人接收的 Channel 发送数据
    task.ResultChan <- result // 💣 这里会永久阻塞
}

看起来人畜无害对吧？但当上游调用方因为超时或异常提前退出，不再从 ResultChan 读取数据时这个 Goroutine 就永远卡在发送操作上成为僵尸协程。

泄漏的本质这方面。GMP 调度器的无奈

Go 的 GMP 模型中，Goroutine被调度到逻辑处理器上执行。当 Goroutine 阻塞在 Channel 操作时：

1. G 进入等待队列不会被回收。 老实说，
2. 栈内存+ 闭包捕获的变量全部驻留内存。
3. 十万个泄漏协程 = 至少 200MB 基础开销 + 业务对象内存。

至于用人话说。Goroutine 不是线程，但泄漏起来比线程还狠。

再看排查实战，pprof 火眼金睛

Step ：抓取 Goroutine Profile

import _ "net/http/pprof"
func main {
go func {
http.ListenAndServe
}
// 业务代码...
}

线上环境执行：

# 抓取当前 Goroutine 快照
curl http://localhost:6060/debug/pprof/goroutine?debug=> goroutine.txt
# 或者用交互式分析
go tool pprof http://localhost:6060/debug/pprof/goroutine

Step ：定位泄漏特征

打开 goroutine.txt,会看到大量类似堆栈：

goroutine :main..handleTask /app/processor.go: +0x125 created by main..ProcessMessages /app/processor.go: +0x8a...

• : 阻塞在 Channel 发送操作已持续数分钟。
• 堆栈完全一致 → 同一段代码批量泄漏。

Step ：火焰图可视化

# 生成 SVG 火焰图
go tool pprof -http=: http://localhost:6060/debug/pprof/goroutine

浏览器中可以看到 handleTask 占据了% 的 Goroutine 数量 ,板上钉钉。

三种优雅关闭 Channel 的常用方法

至于方案一，Context 超时控制

func handleTask {
result := doHeavyWork
select {
case task.ResultChan <- result:
        // 发送成功
    case <-ctx.Done:
        // 上游已取消，放弃发送
        log.Warn
    case <-time.After:
        // 限流兜底超时
        log.Error
    }
}
// 调用方
func caller {
    ctx, cancel := context.WithTimeout, time.Second)
    defer cancel
    task := &Task{ResultChan: make} // 带缓冲更好
    go processor.handleTask
    select {
    case result := <-task.ResultChan:
        handleResult
    case <-ctx.Done:
        return // 超时直接返回，不再等待
    }
}

主要思想：Select `多路复用` 给 Channel 操作加上“逃生通道”。

再看方案二，带缓冲 Channel + 非阻塞发送

// SafeResultChan 封装了安全非阻塞写入和关闭机制
type SafeResultChan struct {
ch chan Result
closed atomic.Bool
}

func TrySend bool { if s.closed.Load { return false } select { case s.ch <- result: return true default: // Channel 已满或无接收者，直接丢弃结果避免阻塞。 return false } }

func Close { if s.closed.CompareAndSwap{ close } }

适用场景：结果可以丢弃。

说到方案三，WaitGroup + 集中关闭

func NewTaskPool *TaskPool{
ctx。cancel:=context.WithCancel)
return &TaskPool{
从tasks来看，make,results:make,ctx:ctx,cancel:cancel,}
}