Go GOMAXPROCS 变化对并发吞吐的影响

Go 的 GOMAXPROCS 决定同一时刻最多有多少个操作系统线程执行用户态 Go 代码。它变大不等于吞吐必然变高：CPU 密集任务可能在接近物理配额后饱和，阻塞型任务则可能因为等待 I/O 而受益。排查“并发数提高但吞吐下降”时，应固定工作量，只改变 GOMAXPROCS，再结合运行环境和 runnable goroutine 判断。

实用结论：先保留运行时默认值作为基线，再用同一 CPU 配额测试 1、2、4 等候选值。只有当吞吐、延迟和资源消耗同时改善，才把自定义值带入生产。

本文要点：① 区分逻辑 CPU、亲和性和容器 CPU limit；② 用固定任务量做可重复实验；③ 不把 GOMAXPROCS 当作 goroutine 数量或 CPU 配额替代品。

先确认 GOMAXPROCS 受什么影响

默认值不是简单等于宿主机核心数。当前 Go 运行时会综合逻辑 CPU 数、进程 CPU affinity，以及 Linux cgroup 的平均 CPU 吞吐限额；自动值还可能随这些条件变化。通过环境变量 GOMAXPROCS 或调用 runtime.GOMAXPROCS(n) 写入自定义值后，自动更新会被关闭。Go 1.25 起可用 runtime.SetDefaultGOMAXPROCS() 恢复运行时默认策略。

package main

import (
    "fmt"
    "runtime"
)

func main() {
    // GOMAXPROCS(0) 只读取当前值，不改变运行时配置。
    fmt.Printf("NumCPU=%d GOMAXPROCS=%d\n", runtime.NumCPU(), runtime.GOMAXPROCS(0))
}

用固定工作量比较不同并行度

不要用“启动更多 goroutine”作为实验变量。下面的思路是让每个任务做相同次数的整数运算，并用一个等待组收敛结果；测试时分别设置 GOMAXPROCS=1、2、4，每组预热后重复多轮。这样得到的是“同一工作量在不同调度并行度下的耗时与吞吐”对比。

func run(workers, jobs int) time.Duration {
    start := time.Now()
    var wg sync.WaitGroup
    wg.Add(jobs)
    for i := 0; i 

实际程序可在启动时读取一个实验参数并调用 runtime.GOMAXPROCS(value)，但要记录它返回的旧值。吞吐可按 jobs / elapsed 计算；同时记录 p95 延迟和进程 CPU 使用率。单次结果不可靠，至少使用相同机器、相同编译参数和多轮中位数。

为什么变大后吞吐反而下降

CPU 密集场景中，超过可用 CPU 配额后，更多 P 会增加抢占、缓存失配和调度竞争，吞吐趋于平台甚至下降。容器配置尤其容易误判：CPU request 不是 Go 运行时用来计算默认并行度的带宽上限，CPU limit 才更接近 cgroup quota。若宿主机有 16 个逻辑 CPU，而容器只能稳定获得约 2 个 CPU，直接写成 16 不能创造额外算力。

混合场景要分开看。goroutine 阻塞在网络、磁盘或系统调用时，不占用执行用户 Go 代码的 P；适当提高 GOMAXPROCS 可能让其他就绪任务继续运行。但如果瓶颈在数据库连接池、远端服务或锁竞争，调大它只会制造更多排队，应该先检查依赖并发上限。

上线前的设置与复核清单

容器化服务优先把默认值作为基线，确认 Go 版本、cgroup 行为和 CPU limit 后再做灰度。若必须固定值，把原因、配额和压测结果写进部署配置；不要同时设置环境变量和代码参数，避免排查时不知道谁覆盖了谁。使用自动默认策略时，注意手动调用 GOMAXPROCS 会关闭自动更新；需要恢复时，在支持的 Go 版本中调用 runtime.SetDefaultGOMAXPROCS()。

检查结果至少包括：固定任务量下的吞吐与 p95、进程 CPU 使用率、runnable goroutine、GC 暂停，以及外部依赖的排队长度。若只看到 CPU 使用率下降而吞吐不变，瓶颈大概率不在 GOMAXPROCS；若吞吐随参数上升后平台化，则应选择平台开始前的较小值，为突发流量留下余量。

相关问题

GOMAXPROCS 是 goroutine 数量上限吗？不是。它限制同时执行用户态 Go 代码的并行度，goroutine 可以远多于这个数，并在等待资源时挂起。

改成逻辑 CPU 数一定最快吗？不一定。容器 CPU limit、CPU 密集程度、锁和外部 I/O 都会改变最佳点，必须用固定工作量测量。

什么时候不该手动设置？当部署环境的 CPU 配额会变化、服务负载混合且没有稳定压测结论时，保留默认自动策略通常更容易维护。