运行时并行

在排查 Go 服务的并发度时，最容易混淆的是 runtime.NumCPU() 和 runtime.GOMAXPROCS(0)。先记住一句话：NumCPU 负责告诉你当前进程看到多少个可用逻辑 CPU，GOMAXPROCS 负责限制同时执行 Go 代码的并行上限。 两个值可能相同，也可能因为 CPU 亲和性、容器配额或显式配置而不同。

因此，看到“机器有 16 核”时，不要直接推断 Go 一定会让 16 个 goroutine 同时执行。先分清资源观测值和调度策略，再决定是否需要调整。

先把两个名字放回不同层次

runtime.NumCPU() 返回当前进程可用的逻辑 CPU 数。它更像一个观测接口：程序启动时向操作系统查询，之后操作系统的 CPU 分配变化不一定反映到这个返回值里。它适合回答“这个进程启动时能看到多少逻辑 CPU”，不适合直接回答“现在有多少 goroutine 会同时跑”。

runtime.GOMAXPROCS(0) 查询当前并行上限。这里的参数 0 不改变设置，只读取当前值。这个上限描述的是同时执行 Go 代码的能力；它不是 goroutine 数量，也不是进程的 OS 线程总数。

把它们写成判断表会更直观：

用最小代码读取两个值

下面的代码只读取状态，并展示如何保存旧设置。它的重点不是制造更多 goroutine，而是避免把两个运行时接口当成同一件事：

package main

import (
    "fmt"
    "runtime"
)

func main() {
    // NumCPU 反映进程启动时看到的逻辑 CPU 数。
    logicalCPU := runtime.NumCPU()

    // 传入 0 表示只查询当前上限，不修改运行时设置。
    parallelLimit := runtime.GOMAXPROCS(0)

    fmt.Printf("logical_cpu=%d gomaxprocs=%d\n", logicalCPU, parallelLimit)

    // 如需临时调整，保存旧值并在作用域结束时恢复，避免污染同一进程的其他任务。
    oldLimit := runtime.GOMAXPROCS(1)
    defer runtime.GOMAXPROCS(oldLimit)
    fmt.Printf("temporary_gomaxprocs=%d\n", runtime.GOMAXPROCS(0))
}

示例中的第二次调用是“设置并返回旧值”，所以不要把它和查询调用混为一谈。生产代码如果确实要调整，应该把变更范围、恢复时机和并发影响写清楚；库代码尤其不应悄悄修改整个进程的全局运行时设置。

容器里为什么两个值更容易分开

在 Linux 容器中，宿主机的逻辑 CPU 数、进程的 CPU 亲和性和 cgroup CPU 配额可能不是一回事。当前 Go 文档描述的默认 GOMAXPROCS 会综合这些因素；Go 1.25 还增加了容器感知的默认行为，并能周期性根据 CPU 亲和性或配额变化更新默认值。

这意味着“NumCPU 是 32，所以 GOMAXPROCS 必须是 32”不是可靠规则。若程序通过 GOMAXPROCS 环境变量或 runtime.GOMAXPROCS(n) 显式设置，运行时会按自定义值工作，自动更新也会被关闭。只有在确认部署约束、版本和延迟目标后，才应设置固定值。

Go 1.25 的容器默认主要解决“进程看到的机器资源远大于容器 CPU limit”这一类错配；它不代表所有工作负载都应手动把 GOMAXPROCS 改成 CPU limit，也不代表 CPU request 会自动变成并行上限。

GOMAXPROCS 限制的是并行上限，不是线程总数

一个常见反例是：启动了 1000 个 goroutine，就以为需要把 GOMAXPROCS 设成 1000。实际上，goroutine 可以排队等待运行；GOMAXPROCS 影响的是同一时刻能执行 Go 代码的数量，而不是可以创建的 goroutine 数。

另一个反例是把 GOMAXPROCS 当成 OS 线程上限。Go 官方 FAQ 明确说明，阻塞系统调用可能让运行时使用多于 GOMAXPROCS 的线程。此时“线程数量变多”并不能证明“更多 Go 代码正在同时执行”。

所以，遇到性能问题时应先问“问题是 CPU 计算、阻塞等待，还是容器限流”，再决定是否调整并行上限。单凭 goroutine 数、线程数或 NumCPU 中的任意一个，都不足以得出调参结论。

最后用这份清单判断是否需要设置

• 先记录 NumCPU() 和 GOMAXPROCS(0)，确认你比较的是观测值还是并行上限。
• 在容器里同时确认 CPU limit、CPU affinity 和 Go 版本，不要只看宿主机核数。
• 检查是否已经设置 GOMAXPROCS 环境变量或调用运行时设置函数。
• 区分 CPU 密集任务与大量阻塞调用；GOMAXPROCS 不等于线程总数。
• 没有明确测量目标时，优先使用运行时默认值，避免在公共库中修改进程级全局设置。

相关问题：为什么 NumCPU() 和 GOMAXPROCS(0) 会不同？因为两者职责不同，后者还会受运行时默认策略和显式配置影响。把 GOMAXPROCS 设成 1 会怎样？它会消除真正的并行执行，但不会阻止 goroutine 创建，也不会保证进程只有一个 OS 线程。