Go 设置 GOMAXPROCS 后吞吐未提升怎么办

把 GOMAXPROCS 调大后吞吐没有变化，通常不是参数“没有生效”，而是它只提高了 Go 同时执行用户态代码的上限，并不会增加容器配额，也不会让串行代码、锁竞争或网络等待自动并行。先确认实际值，再把任务分成 CPU 计算、I/O 等待和同步竞争三类，最后用固定负载做对照测试，结论才可靠。

先确认真正生效的并行度

runtime.GOMAXPROCS(0) 只查询当前值，不会修改配置。下面的小程序适合放进启动诊断或临时基准中，输出的是进程看到的逻辑 CPU、当前并行度和运行时版本；它不是吞吐测试。

package main

import (
	"fmt"
	"runtime"
)

func main() {
	// 传入 0 只读取当前值，不改变运行时配置。
	current := runtime.GOMAXPROCS(0)
	// NumCPU 是进程可见的逻辑 CPU 数，不等于容器 CPU 配额。
	fmt.Printf("GOMAXPROCS=%d logical_cpu=%d go=%s\n", current, runtime.NumCPU(), runtime.Version())
}

如果通过 GOMAXPROCS=4 或 runtime.GOMAXPROCS(4) 手动指定，调度器会按这个值限制同时执行用户态 Go 代码的线程数；阻塞在系统调用或 cgo 中的线程不受这个上限直接限制。也就是说，看到大量 goroutine 并不能证明需要更大的 GOMAXPROCS。

先判断瓶颈属于哪一种

参数调优前，至少记录一组相同请求量下的吞吐、CPU 使用率、阻塞时间和尾延迟。下面的判断比“goroutine 越多越快”更有用：

尤其在容器里，主机可能有 32 个逻辑 CPU，但进程的 cgroup CPU quota 只有 2.5 个核。此时把值从 2 调到 16，可能只会让更多线程争抢有限配额，触发 Linux throttling，吞吐不升反而让 P99 变差。

用同一负载做 GOMAXPROCS 对照

不要边压测边修改请求量、实例数和数据集。固定输入后，分别测试 1、2、4、8 等值，并同时记录应用吞吐、CPU 配额使用和 P95/P99。命令只改变并行度，便于把“参数收益”和“负载波动”分开：

# 对同一基准分别测试多个并行度；不要同时改变请求数据和实例规格。
for p in 1 2 4 8; do
  echo "GOMAXPROCS=$p"
  GOMAXPROCS=$p go test -run='^$' -bench='BenchmarkWorkload' -benchmem -count=5
done

如果 CPU 使用率随值增加而上升、吞吐在某点后平台化，平台点附近通常就是更合理的候选；如果 CPU 不高且吞吐不变，优先查下游等待或锁。若吞吐看似提高但 P99 和 throttled time 同时上升，应把这个结果视为回归，而不是优化。

Go 1.25 容器默认值的边界

Go 1.25 起，未被手动覆盖时，运行时默认值会综合逻辑 CPU、进程 CPU affinity，以及 Linux cgroup 的平均 CPU throughput limit，并周期性更新。CPU limit 为小数时会向上取整。这里的 CPU request 不是同一件事，不能拿 request 直接推导 GOMAXPROCS。

如果程序历史上调用过 runtime.GOMAXPROCS，或者部署环境设置了 GOMAXPROCS，自动更新会被关闭。Go 1.25 还提供了恢复默认行为的接口：

package main

import "runtime"

func restoreRuntimeDefault() {
	// Go 1.25+：重新采用运行时默认值，并允许后续自动更新。
	runtime.SetDefaultGOMAXPROCS()
}

这个接口不是“让吞吐必然变高”的按钮。它只适合已经确认固定值过时、且希望重新交给运行时判断的场景。生产环境应把版本、CPU limit、实例负载和基准结果一起记录，避免一次参数变更掩盖真正的下游瓶颈。

常见问题

GOMAXPROCS 越大，goroutine 就越多吗？

不是。goroutine 数量由程序创建和阻塞情况决定，GOMAXPROCS 只限制同时执行用户态 Go 代码的并行度。

CPU 使用率不高，为什么吞吐还是上不去？

常见原因是等待网络、数据库、磁盘或锁；平均 CPU 低并不代表没有关键路径阻塞，应结合阻塞剖析和下游耗时判断。

容器中应该固定设置 GOMAXPROCS 吗？

不应默认固定。Go 1.25 及以上先保留容器感知默认值，只有压测证明固定值更符合稳定延迟或特定工作负载时再设置。

实际排查时，先保留一个基线值，再逐档对照吞吐、CPU 配额、等待时间和尾延迟。只要瓶颈不在 CPU 并行段，继续调大 GOMAXPROCS 就不会带来真实收益。