导读：goroutine 初始栈只有 2KB，这是 Go 引以为傲的轻量级并发基础。但这恰恰是最大的误解。当你有 50-80 万个 goroutine 时，轻量就不再是优势，而是陷阱。

上周帮一个朋友排查线上问题。他们的 Go 服务运行了三个月一直稳定，突然某天凌晨开始 OOM——重启，好了；过两小时又 OOM。监控面板上 goroutine 数量在 OOM 前飙到了 80 万。

“我们每个请求就开了几个 goroutine，也不多啊。“他说。

我看了代码，每个请求确实只开 3 个 goroutine。但问题是，QPS 高峰期每秒进来 5000 个请求，每秒就是 15000 个 goroutine 被创建。十分钟就是 900 万个。

“goroutine 不是很轻量吗？“他追问。

这个问题，正是这篇文章要回答的。

一、你以为 goroutine 很轻量？

“goroutine 初始栈只有 2KB”——这是每个 Go 开发者都知道的事实。Go 官方文档也骄傲地宣称 goroutine 是"轻量级线程”，一个 goroutine 的创建成本远低于 OS 线程。

这没错。但轻量乘以 10 万，就不再轻了。当然，有经验的 Go 开发者都知道 goroutine 不是免费的——但你可能没算过到底要花多少钱。

1.1 先看数字

我跑了一组实测：用 Go 逐步创建 10 万个 goroutine，每个 goroutine 只分配 4KB 堆内存（模拟最轻量的业务场景），每批 1000 个记录一次内存状态。

结果如下：

[已创建 10000] goroutines=10001 | heapAlloc=6.6MB  | heapSys=11.8MB
[已创建 50000] goroutines=50001 | heapAlloc=30.4MB | heapSys=37.6MB
[已创建 100000] goroutines=100001 | heapAlloc=61.9MB | heapSys=71.9MB

10 万个 goroutine，即使每个只做最轻量的事，堆内存就已经逼近 62MB，系统内存占用超过 70MB。加上每个 goroutine 的栈空间（初始 2KB，动态增长，轻量场景实测均值约 4KB），10 万个就是约 400MB 栈空间。

这只是 10 万。线上服务在流量高峰时，goroutine 数量飙到 50-80 万是家常便饭。

1.2 算一笔账

假设你的服务器有 4GB 内存，一个 goroutine 的综合开销（栈 + 堆分配 + 运行时元数据）大约是 4-6KB（基于上节的实测推算：62MB heapAlloc ÷ 100K ≈ 620B/goroutine 堆开销 + ~4KB 栈 ≈ ~4.6KB/goroutine）。那 50 万个 goroutine 就吃掉 2-3GB，还没算业务逻辑本身的分配。

现实更残酷：真实业务中，每个 goroutine 不只是"分配 4KB 就睡”。它要解析请求、查询数据库、序列化响应。假设每个 goroutine 还处理业务逻辑，开销可能达到 50KB 以上。这意味着10 万个 goroutine 就可能吃掉 5GB 以上的内存。

OOM 的临界点根本不在"几百万”——对于大多数线上服务，50 万 goroutine 就已经是生死线了。

这就是为什么我说：goroutine 的轻量是 Go 最容易被误解的特性。2KB 相对于 2MB 的 OS 线程确实轻，但乘以 10 万就不轻了。

二、协程池的本质：调度上下文保护

理解了"goroutine 太多会 OOM”，这只是第一步。更难的问题是：为什么 goroutine 太多不只是 OOM 的问题？

2.1 GMP 调度模型速览

Go 的调度器是基于 GMP 模型的：

• G（Goroutine）：代表一个 goroutine，包含栈、指令指针、状态等
• P（Processor）：代表一个调度上下文，数量固定为 GOMAXPROCS（默认 = CPU 核数）
• M（Machine）：代表一个 OS 线程，由调度器绑定到 P 上执行 G

一个 goroutine 从创建到执行，要经过：创建 G → 放入 P 的本地队列 → 调度器从队列取 G → 绑定 M → 执行 → G 生命周期结束，资源归还空闲列表

2.2 G 膨胀后发生了什么？

假设你在一台 4 核的机器上，同时有 10 万个 goroutine 在运行。P 只有 4 个（GOMAXPROCS=4），同时只能执行 4 个 goroutine。那剩下的 99996 个呢？

它们在排队。

【正常】P（4个）→ 本地队列（几十个 G）→ 全局队列
【G 膨胀】P（4个）→ 本地队列（几千个 G）→ 全局队列（几万个 G）

排队的直接后果：

1. 调度循环变长：调度器每次从队列取 G 的时间是 O(1)，但全局队列的锁竞争加剧——所有 P 竞争同一个全局队列锁。同时 work stealing（从其他 P 的本地队列窃取 G）的命中率下降，因为每个 P 自己的队列已经很长。

2. 上下文切换失控：即使只有 4 个 P 在执行，调度器仍然需要在所有 runnable 的 G 之间做切换。当 G 数量是 P 数量的 10000 倍时，调度器本身就成了瓶颈——它花在"决定谁该执行"上的时间，超过了实际执行的时间。

3. GC 压力倍增：Go 的 GC 是三色标记清除算法。标记阶段需要扫描所有 goroutine 的栈。goroutine 越多，扫描的栈越多。10 万个 goroutine 的栈扫描，即使每个只有 4KB，也需要扫描 400MB 的数据。

2.3 协程池的本质

协程池不是"让 goroutine 创建更快"，也不是"复用 goroutine 省资源"，这些只是表象。

协程池的本质，是在 GMP 调度之外加了一层"调度上下文保护"。

怎么保护的？

• 限制 G 数量：池的 worker 数量限制了同时存在的 goroutine 数量。10 万个任务进来，池只有 100 个 worker → 同时只有 100 个 G 在运行，其余的任务在 channel 里排队（不创建 G）。
• 保护 P 的调度队列：P 的本地队列只维护 100 个 G，而不是 10 万个。调度循环保持 O(1) 级别。
• 减少 GC 扫描范围：GC 标记阶段只需要扫描 100 个 goroutine 的栈，而不是 10 万个。

协程池的本质包含两个层次：限流层和调度器保护层。

限流层是第一道防线：10 万个任务进来，池只放行 100 个 goroutine，其余的在 channel 里排队。突发流量时你看到的"慢"——那 1000ms 的排队时间——正是限流在起作用。

调度器保护层是第二道防线：P 的本地队列只维护 100 个 G 而不是 10 万个，调度循环保持 O(1)；GC 标记阶段只需要扫描 100 个栈而不是 10 万个。这些收益在短期看是微秒级的，但在长期运行场景——当 goroutine 数量持续积累时——它是防止 OOM 的关键。

两者缺一不可。没有限流，调度器保护层的"保护"无从谈起——因为 goroutine 数量根本不会受控。没有调度器保护，限流只能防止 OOM，但无法消除 G 膨胀对调度性能的侵蚀。

2.4 一个常见误区

把协程池等同于"复用 goroutine 以减少创建开销"——这话没错，但只说到表象。

从 benchmark 数据来看，goroutine 的创建开销确实存在。10 万个 goroutine 的创建时间大约在 4-6ms。但相对于一个 HTTP 请求的 50-500ms 处理时间，创建开销基本可以忽略。

协程池真正解决的问题，是太多 goroutine 同时存在——而不是创建 goroutine 的速度。

如果你认为协程池是"优化创建性能"，那在低并发场景下确实不需要。但如果你理解协程池是"资源管控机制"，那在任意有并发上限的场景下都需要。

2.5 事故复盘：一个 goroutine 泄露的排查

以下场景基于常见工程场景构造。

“线上 OOM 了。“值班群的消息。

监控面板上，goroutine 数量曲线快速蹿升：从平时 2000 飙到 60 万，然后 OOM，容器重启。重启后回到 2000，然后再次飙升。

第一反应：看看谁在创建 goroutine。

curl http://localhost:6060/debug/pprof/goroutine?debug=2 -o goroutine.pprof
go tool pprof -top goroutine.pprof

pprof 很快定位到问题：一段代码在每次请求时都启动了 goroutine 去写日志，但日志队列满了之后，goroutine 就阻塞在 channel 发送上，不退出、不释放。QPS 一涨，goroutine 数量就线性增长。

临时止血方案：把 channel 改成有缓冲的，加一个超时控制。

长期方案：引入协程池管理所有后台 goroutine，限制最大并发数，池满时直接丢弃或降级。

修复后，goroutine 数量稳定在 100-200，再也没出现 OOM。这不是代码 bug，是没有资源管控意识。

但知道了"需要协程池"是一回事，怎么写出一个生产能用的协程池是另一回事。第三章就来说说这个问题。

三、生产级协程池实现

网上有很多协程池实现教程，但大多只展示"能用”，没解决"生产能用"的问题。

3.1 标准架构

一个协程池的核心组件只有三个：

任务定义（Task）→ 任务队列（Task Queue）→ Worker 池（Pool of Workers）

每个组件都有明确职责：

3.2 一个基础的实现

先写一个能用但不够完善的版本，再说怎么优化。

// Pool 是一个泛型协程池，T 是任务类型
type Pool[T any] struct {
    taskCh chan T
    wg     sync.WaitGroup
}

func NewPool[T any](workers int, queueSize int, handler func(T)) *Pool[T] {
    p := &Pool[T]{
        taskCh: make(chan T, queueSize),
    }

    for i := 0; i < workers; i++ {
        p.wg.Add(1)
        go func() {
            defer p.wg.Done()
            for task := range p.taskCh {
                handler(task)
            }
        }()
    }
    return p
}

func (p *Pool[T]) Submit(task T) {
    p.taskCh <- task
}

func (p *Pool[T]) Shutdown() {
    close(p.taskCh)
    p.wg.Wait()
}

这段代码已经能跑了，但距离生产环境还需要补充几个能力。

3.3 线上环境的避坑点

问题 1：Submit 阻塞

如果队列满了，p.taskCh <- task 会阻塞提交者。在高并发场景下，这可能导致提交者（比如 HTTP handler）自己也卡住。

解法：用 select + default 做非阻塞提交或超时提交。

// 非阻塞提交，队列满直接返回错误
func (p *Pool[T]) TrySubmit(task T) error {
    select {
    case p.taskCh <- task:
        return nil
    default:
        return ErrPoolFull
    }
}

// 带超时的提交（注意：time.After 在成功提交场景下不会立即释放 timer，
// 高频调用建议使用 time.NewTimer + timer.Stop 替代）
func (p *Pool[T]) SubmitWithTimeout(task T, timeout time.Duration) error {
    select {
    case p.taskCh <- task:
        return nil
    case <-time.After(timeout):
        return ErrSubmitTimeout
    }
}

问题 2：优雅关闭

当收到退出信号时，你是"等所有任务完成再退出”，还是"立即丢弃未完成任务"？

这取决于业务场景。对于日志写入、异步通知这类非关键任务，可以丢。但对于订单处理、支付确认这类关键任务，必须等。

func (p *Pool[T]) ShutdownGraceful() {
    close(p.taskCh)
    p.wg.Wait() // 等待所有 worker 完成当前任务（注意：不会取消正在执行的任务，
    // 如果 worker 需要响应关闭信号，建议配合 context 使用）
}

func (p *Pool[T]) ShutdownImmediate() {
    // drain：消费掉 channel 中剩余的任务（不执行），然后关闭
    // 注意：这里的 busy loop drain 方案在高并发场景下可能漏掉正在写入的任务，
    // 生产环境建议使用单独的关闭标记 + atomic 变量或 context 来实现。
    // 详见：https://go.dev/ref/spec#Close_and_drain
    for {
        select {
        case <-p.taskCh:
        default:
            close(p.taskCh)
            p.wg.Wait()
            return
        }
    }
}

问题 3：Panic 传播

worker 里的 panic 如果不捕获，整个 goroutine 就挂了，pool 里的 worker 会逐渐减少。

// worker 是 worker goroutine 的执行循环
func (p *Pool[T]) worker(handler func(T)) {
    defer p.wg.Done()
    defer func() {
        if r := recover(); r != nil {
            log.Printf("worker panic recovered: %v", r)
            // 重启一个 worker 替代当前
            p.wg.Add(1)
            go p.worker(handler)
        }
    }()
    for task := range p.taskCh {
        handler(task)
    }
}

// NewPool 创建协程池
func NewPool[T any](workers int, queueSize int, handler func(T)) *Pool[T] {
    p := &Pool[T]{
        taskCh: make(chan T, queueSize),
    }
    for i := 0; i < workers; i++ {
        p.wg.Add(1)
        go p.worker(handler)
    }
    return p
}

3.4 Worker 数量怎么选

我跑了一组实测，在 14 核的机器上，1000 个 CPU 密集任务，不同 worker 数量的表现：

从 1→4→8 提升明显（2.67ms → 793µs → 650µs），这是因为从单 worker 到多 worker 充分利用了多核并行。14 核的机器上 4 个 worker 就已经可以覆盖大部分核心空闲时间。从 8 到 16 到 32 边际收益递减，因为 CPU 密集场景的瓶颈是计算本身，不是并发度。> 注：benchmark 结果可能受编译器优化（内联、死代码消除）影响，建议在生产环境复测。

通用建议：worker 数量设为 GOMAXPROCS（或略高），然后根据任务类型微调。 CPU 密集 ≈ GOMAXPROCS，I/O 密集可设 2-4 倍。

但有一条铁律：worker 数量 < 预期的峰值并发任务数——否则协程池就失去了"限流"的意义。

不过，“worker 数量选 N 个"只是一个起点。真正重要的是——协程池和直接 go func() 的性能差距到底有多大？不同场景下差距是否一致？第四章用数据来回答这些问题。

四、数据说话：池 vs 裸开

我用 Go benchmark 框架跑了一组对比测试：同一 CPU 密集任务（1 万次循环求和），在 10/100/1000/10000 四个任务量级下，对比直接 go func() 和使用协程池的差异。

测试环境：Go 1.26.4, Apple M4 Pro (14 核), darwin/arm64。

4.1 CPU 密集任务

// 每个 goroutine 执行 1 万次整数运算
func cpuIntensiveTask() {
    var sum int
    for i := 0; i < 10000; i++ {
        sum += i * i
    }
    _ = sum
}

注意这里的关键指标不是耗时。10000 个任务时直接开只比池快了 1.2ms，对大多数业务来说毫秒级差异可以忽略。真正重要的是内存分配——952 倍的 allocs 差距意味着 GC 被触发的频率高了近千倍。短期看不到，但跑几个小时就会体现。

10000 个任务时，直接 go func() 分配了 1.4MB 内存、12382 次分配；协程池只分配了 82KB、13 次分配。952 倍的 allocs 差距。

952 倍 allocs 意味着什么？GC 压力。Go 的 GC 标记阶段是并发的，但分配次数越多，GC 触发越频繁，STW 阶段（标记终止+清扫）累积时间越长。952 倍的 allocs 差距意味着 GC 被触发的频率高了近千倍。

4.2 重计算任务

// 每个 goroutine 执行 50 万次整数运算（比 4.1 的 1 万次重 50 倍）
func cpuHeavyTask() {
    var sum int
    for i := 0; i < 500000; i++ {
        sum += i
    }
    _ = sum
}

重计算场景下趋势与 CPU 密集场景类似，allocs 差距同样达到 1000 倍级别。不同的是耗时差距更大（池比直接开多了 30%），因为 worker 数（8）限制了并行度。

4.3 突发流量模拟

我还模拟了一个更贴近实际的场景：5000 个请求在短时间内同时涌入，每个请求处理约 10ms（模拟中等复杂度数据库查询）。

结果很有意思：

• 无限制：30ms 全部完成，但峰值内存 2.9MB
• 协程池：1095ms 完成，峰值内存 2.3MB

池慢了 36 倍。

但这是否说明协程池"不好”？恰恰相反。这个实验正好说明了协程池的核心 trade-off——用速度换可预测性。

50 个 worker 处理 5000 个 10ms 任务，理论排队时间就是 5000/50×10ms = 1000ms，数据完全吻合。池的"慢"本质上是限流在起作用——它主动限制了并发度。

关键问题不是"池快不快"，而是无限制创建 5000 个 goroutine 时系统还活着，但如果 QPS 持续 30 分钟呢？

30 分钟后，无限制版本会累积 900 万个 goroutine（按实验中的创建速度），内存直奔几十 GB——OOM。而协程池版本，永远只有 50 个 goroutine，稳定运行。

协程池不是在优化性能，是在牺牲部分速度换取系统的可预测性。

五、什么时候该用，什么时候不该用

你可能会觉得"那所有场景都应该用协程池"。不是的。

5.1 该用的场景

5.2 不该用的场景

还有一个反直觉的场景值得一提：大量 goroutine 生命周期极短（微秒级）时，协程池可能比直接 go func() 更慢。因为池的排队开销（channel 发送+接收+上下文切换）超过了 goroutine 创建的开销。这也是为什么 benchmark 数据显示 10 个任务时两者基本持平——小规模下池没有优势。

5.3 决策框架

三个问题帮你判断是否需要协程池：

1. goroutine 数量是否可预测？

   • 可预测且远小于系统承受上限（如 < 1000）→ 可以不考虑池
   • 不可预测或可能大于 1000 → 需要池
   • 注意：100 是"明显不需要"的下界，50 万是"绝对需要"的上界。中间区间（几百到几万）需要结合问题 2 和 3 综合判断。

2. goroutine 生命周期多长？

   • 远小于 1ms → 不需要池（但需要排查为什么这么短）
   • 1-100ms → 需要池，主要是限流
   • 大于 100ms → 强烈需要池，防止 goroutine 堆积

3. 系统能否承受 goroutine 数量失控？

   • 能（资源充足或有熔断机制）→ 可以不考虑池
   • 不能 → 必须加池

这三个问题，任何一个指向"需要池"，就应该用。

写在最后

回到开头那个朋友的问题：“goroutine 不是很轻量吗？”

goroutine 确实轻量。但"轻量"是相对于 OS 线程说的，不是相对于"不限量"说的。

协程池不是在质疑 Go 调度器的能力——恰恰相反，它是基于对 GMP 调度器工作原理的深刻理解，在调度器外面加的一层保护。它让 P 的调度队列保持健康，让 GC 不扫描 10 万个栈，让系统在流量高峰时依然可预测。

协程池用速度换可预测性——它让你的服务在流量涨 10 倍时只是变慢，而不是挂了。

下次你再遇到"要不要用协程池"的讨论时，问一个问题：如果流量突然涨 10 倍，我的服务是变慢，还是挂了？

如果是挂了——你需要协程池。

原文发布于 止语Lab