完全CPU密集型工作负载中是否需要限制Goroutine数量？如何确定上限？

是否需要限制Goroutine数量 #

非常有必要。
纯CPU密集型负载下没有IO、系统调用等会让Goroutine陷入等待的操作，过多的Goroutine只会触发不必要的调度上下文切换：Go调度器中每个P（逻辑处理器）同一时间只能运行1个G（Goroutine），当G数量远大于P数量时，调度器需要频繁换入换出待执行的G，这个切换过程会消耗CPU资源，反而降低整体计算效率，同时多余的空闲Goroutine还会占用额外的内存资源。

如何确定最大Goroutine数量 #

优先以物理CPU核心数作为基准值：

• 如果任务是100%纯CPU计算，没有任何锁等待、内存拷贝等待操作，最大数量直接设置为物理核心数即可，超线程带来的逻辑核心对CPU密集型计算没有增益，不要用逻辑核心数作为基准。
• 如果任务存在少量短时锁等待、或者非IO类的短暂阻塞，可以将上限小幅上浮到物理核心数的1.1~1.2倍，上浮比例不要超过20%。

关于runtime.GOMAXPROCS的说明 #

首先纠正使用误区：runtime.GOMAXPROCS(0)的作用是查询当前设置的P的最大数量，不会修改配置，要手动设置P的数量需要传入大于0的参数，例如runtime.GOMAXPROCS(8)就是设置最多8个P同时工作。
你看到的废弃提示应该是部分社区文档的非官方建议，官方标准库目前没有将该接口标记为弃用的规划，至少在Go 1.22版本中仍然是稳定可用的，手动控制场景完全可以放心使用。如果是部署在容器环境，也可以结合automaxprocs自动适配容器分配的CPU配额，避免和宿主机CPU核数冲突。

手动限制Goroutine并发的实现方案 #

最常用的轻量实现是用带缓冲通道做信号量控制，示例代码如下：

package main

import (
    "runtime"
)

type ComputeTask func()

func main() {
    // 你的CPU密集型计算任务列表
    var tasks []ComputeTask
    // 初始化信号量，最大并发数设为物理核心数
    maxConcurrency := runtime.NumCPU()
    sem := make(chan struct{}, maxConcurrency)

    for _, task := range tasks {
        // 申请令牌，令牌耗尽时会阻塞，避免启动过多Goroutine
        sem <- struct{}{}
        go func(t ComputeTask) {
            // 任务执行完释放令牌
            defer func() { <-sem }()
            // 执行计算逻辑
            t()
        }(task)
    }

    // 等待所有任务执行完成
    for i := 0; i < maxConcurrency; i++ {
        sem <- struct{}{}
    }
    close(sem)
}

补充说明 #

你提到的Goroutine内存约束确实存在：每个新建Goroutine的初始栈大小为2KB，栈会根据运行情况动态伸缩，即使Goroutine处于休眠状态也会占用栈内存。如果无限制启动Goroutine，仅栈内存就会占用大量不必要的资源，限制并发数也能同时规避这个问题。

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