多少个Goroutines才算过多？Lambda上树形BSP工作负载的性能问询

场景与代码 #

我的工作负载为树形分支结构：需要处理n个A项，每个A项的处理需处理m个B项，以此类推还会再延伸1-2层（如每个B项对应若干C项）。

我编写的Go语言处理代码如下：

func handler() {
    var aList []A

    var wg sync.WaitGroup
    for _, a := range aList {
        wg.Add(1)
        go func () {
            defer wg.Done()
            processA(a)
        }() // 注：原代码遗漏启动协程的()，此处补上
    }
    wg.Wait()
}

func processA(a A) error {
    var wg sync.WaitGroup
    for _, b := range a.BList {
        wg.Add(1)
        go func () {
            defer wg.Done()
            processB(b)
        }()
    }
    wg.Wait()
} 

func processB(b B) error {
    var wg sync.WaitGroup
    for _, c := range b.CList {
        wg.Add(1)
        go func () {
            defer wg.Done()
            processC(c)
        }()
    }
    wg.Wait()
} 

这些任务属于BSP（批量同步进程），任务间无需通信；若拥有无限多核资源，所有协程均无需等待。但实际运行环境为仅提供2/3/4核的Lambda函数，且工作负载不会触及内存限制。

疑问 #

• 以提升速度为目标，是否需要修改代码限制Goroutines数量？
• 当前代码是否会因过多上下文切换而性能下降？
• 是否存在「Goroutines过多」的情况？

回答 #

1. 是否需要限制Goroutines数量？ #

不需要刻意限制。Go的调度器会自动将Goroutine映射到操作系统线程，且默认GOMAXPROCS会适配Lambda的核心数（2-4核）。对于无通信的CPU密集型BSP任务，调度器会合理分配协程到空闲核心，不限制数量反而能让调度器更灵活地利用资源——当某个分支任务提前完成时，其他等待的协程可以立即占用空闲核心，不会浪费算力。

2. 是否会因过多上下文切换性能下降？ #

几乎不会。Goroutine是用户态轻量级线程，上下文切换成本仅为操作系统线程的几十分之一，且Go调度器会尽量让协程在同一个线程上持续运行，减少不必要的切换。只有当Goroutine数量达到十万甚至百万级时，才可能出现可感知的调度开销，但一般业务场景下的树形负载（比如n、m均为几百级别）远达不到这个量级，完全不用担心。

3. 是否存在「Goroutines过多」的情况？ #

不存在。你已经明确工作负载不会触及内存限制，而每个Goroutine的初始栈仅2KB，CPU密集型任务的栈也不会大幅扩容，就算创建上万Goroutine，内存占用也极低。只有当Goroutine数量多到耗尽内存时，才会出现“过多”的问题，显然你的场景不满足这个条件。

额外注意：代码中的闭包捕获bug #

你的代码存在一个严重的逻辑bug：循环中创建的协程闭包会共享循环变量（如handler中的a、processA中的b），导致多个协程可能处理同一个元素，或处理的是循环最后一个元素。正确写法需要将循环变量作为参数传入闭包：

// handler中的协程修正示例
go func(a A) {
    defer wg.Done()
    processA(a)
}(a)

同样的修正需要应用到processA和processB中的协程闭包，这个bug会直接导致任务处理错误，优先级比协程数量优化更高。

内容的提问来源于stack exchange，提问作者Varun Gawande