Go GOMAXPROCS 和 CPU 核数不一致时如何判断正常

不一致本身不一定是问题。runtime.NumCPU() 表示程序可见的逻辑 CPU 数，runtime.GOMAXPROCS(0) 表示当前允许同时执行 Go 代码的最大 CPU 数；两者回答的不是同一个问题。真正需要判断的是：这个较小的并行度来自容器 CPU 限额、CPU 亲和性、显式配置，还是误配。

Go 1.25 之后，Linux 上的默认 GOMAXPROCS 还会参考 cgroup CPU 带宽限制，并可能随可用 CPU 或限额变化而更新。因此，在宿主机有 16 个逻辑 CPU、容器只分到 2.5 个 CPU 时，看到 NumCPU=16 而 GOMAXPROCS=3，可能正是合理的默认结果。

先把两个数字放在同一张表里

排查时先不要改参数，记录运行时实际看到的值。下面的程序只读取状态，不改变调度器设置；示例输出中的数字是说明格式，不代表某台机器的实测结果。

package main

import (
    "fmt"
    "os"
    "runtime"
)

func main() {
    // 读取逻辑 CPU 数与当前并行度；传入 0 不会修改 GOMAXPROCS。
    fmt.Printf("NumCPU=%d GOMAXPROCS=%d\\n", runtime.NumCPU(), runtime.GOMAXPROCS(0))
    // 记录是否存在显式环境覆盖，便于区分默认值和人工设置。
    fmt.Printf("GOMAXPROCS_ENV=%q\\n", os.Getenv("GOMAXPROCS"))
}

NumCPU=16 GOMAXPROCS=3
GOMAXPROCS_ENV=""

这里的 3 不是“只能创建 3 个 goroutine”，而是调度器同时执行 Go 代码的并行度上限。goroutine 数量仍可以远大于这个值；它们会在可用的执行资源上复用。

为什么 CPU 核数和 GOMAXPROCS 会分开

可以按“谁提供了这个值”来判断。第一种是显式覆盖：启动环境设置了正整数 GOMAXPROCS，或程序调用了 runtime.GOMAXPROCS(n)。第二种是进程的 CPU 亲和性让它只能使用部分逻辑 CPU。第三种是 Linux 容器的 cgroup CPU 带宽限制小于宿主机可见的逻辑 CPU 数。

Go 1.25 的默认策略会把逻辑 CPU、CPU 亲和性和 Linux cgroup 的平均 CPU 吞吐限额一起纳入考虑；CPU 限额是吞吐上限，可能带小数，而 GOMAXPROCS 必须是正整数，所以运行时需要取一个整数值。CPU request 不是同一种硬限额，不能简单拿它解释当前 GOMAXPROCS。

因此，“宿主机核数更大”只能说明观察到的资源视图更宽，不能单独推出应用应该把并行度调大。尤其是小 CPU limit 配在大机器上的容器，较高的 GOMAXPROCS 可能让进程更容易触发 CPU throttling，尾延迟反而变差。

什么时候可以判断为正常

下面几种情况通常可以先视为合理差异：

• 容器设置了较小的 CPU limit，且没有人为设置 GOMAXPROCS。
• 进程绑定了较少的 CPU，GOMAXPROCS 与该可用范围一致。
• 应用主动选择较小并行度，压测和线上指标都符合目标。

反过来，如果部署配置写了过期的 GOMAXPROCS，应用迁移到不同 CPU 配额后仍固定为旧值，或者团队以为使用了容器默认值但实际上设置了环境变量，就值得继续排查。建议把启动参数、容器 CPU limit、CPU 亲和性和运行时两个读数放在同一份诊断记录里。

只在有证据时调整

不要因为 runtime.NumCPU() 更大，就机械执行 runtime.GOMAXPROCS(runtime.NumCPU())。这会把运行时已经识别到的容器或亲和性边界覆盖掉。更稳妥的顺序是先删除不再需要的旧环境变量，再观察吞吐、CPU throttling、GC 和尾延迟是否改善。

# 仅查看显式覆盖；空输出通常表示没有在当前 shell 设置。
printenv GOMAXPROCS
# 查看容器编排配置中的 CPU limit；下面的键名需按实际部署文件替换。
grep -n "cpu" deployment.yaml

如果确实需要固定并行度，应把原因、数值和适用环境一起写进部署配置，并保留回退方案。Go 1.25 还提供 containermaxprocs=0 和 updatemaxprocs=0 这类 GODEBUG 开关，但它们改变的是默认策略边界，不是通用的性能加速开关；只有在明确知道要恢复旧行为或停止自动更新时才使用。

常见疑问

GOMAXPROCS 小于 CPU 核数就一定性能差吗？不一定。它可能正好匹配容器限额，也可能是应用有意控制并行度；要结合工作负载和延迟指标判断。

应该用 NumCPU 还是 GOMAXPROCS 作为监控标签？两个都保留。前者描述进程可见的逻辑 CPU，后者描述当前调度并行度，混成一个指标会掩盖容器和配置差异。

一句话总结：先解释差异来源，再判断实际资源边界，最后才决定是否调整 GOMAXPROCS。