运行时调度

Go 的 GOMAXPROCS 限制的是同时执行用户 Go 代码的并行度，不是进程中操作系统线程的固定数量。把它设成 2，并不要求系统监控只显示两个线程，也不会把所有 goroutine 变成只能创建两个。阻塞系统调用、运行时工作及线程复用都需要放在不同层面理解。

如果调整之后线程数仍然较高，先别继续降低数值。应先确认配置确实生效，再区分线程总数、goroutine 数和正在执行 Go 代码的并行度。

官方文档：https://pkg.go.dev/runtime

线程数没有下降，先确认观察的是什么

例如服务里有很多等待网络响应的 goroutine，它们不需要各占一个持续执行 Go 代码的线程。反过来，一些线程处于系统调用或其他状态，也不表示 GOMAXPROCS 没有生效。因此，把这三个数直接比较大小不能构成故障结论。

用 G、M、P 分清限制对象

运行时实现中，G 表示 goroutine，M 表示操作系统线程，P 表示执行用户 Go 代码所需的调度资源。P 的数量对应 GOMAXPROCS；M 与 P 并非固定一一绑定的线程池。

一个 M 因系统调用停止执行用户 Go 代码时，P 可以用于其他可运行工作。因而线程总数可能超过 P 数量。G 也可以在不同时刻由不同的 M 执行，不能把某个 goroutine 永久等同于某个线程。

实现概念说明：https://go.dev/src/runtime/HACKING。这些术语用于解释差异，业务代码不需要直接操作运行时内部对象。

读取实际配置再安排一次对照

先用只读采样确认当前二进制版本和生效数值，再谈调整。以下原创程序未在本文制作过程中执行，输出字段不是线上采样记录。

package main

import (
    "fmt"
    "runtime"
    "runtime/metrics"
)

func main() {
    // 传入零只查询当前设置，不改变进程的调度并行度。
    fmt.Printf("go=%s gomaxprocs=%d goroutines=%d\n",
        runtime.Version(), runtime.GOMAXPROCS(0), runtime.NumGoroutine())

    samples := []metrics.Sample{
        {Name: "/sched/gomaxprocs:threads"},
        {Name: "/sched/goroutines:goroutines"},
    }
    metrics.Read(samples)
    for _, sample := range samples {
        // 未提供或类型不符的指标不能直接按整数读取。
        if sample.Value.Kind() != metrics.KindUint64 {
            fmt.Printf("%s 当前不可按整数读取\n", sample.Name)
            continue
        }
        fmt.Printf("%s=%d\n", sample.Name, sample.Value.Uint64())
    }
}

/sched/gomaxprocs:threads 名称里虽有 threads，表示的仍是同时执行用户 Go 代码的线程能力，不是操作系统线程总数。/sched/goroutines:goroutines 则是存活 goroutine 的数量。指标定义见：https://pkg.go.dev/runtime/metrics。

如果需要做对照，将下面的片段放入独立实验程序中，沿用 runtime 导入。准备相同输入、相同运行时长和相同环境，比较一个变量即可。

// 仅用于独立实验进程，不要在业务请求处理器中反复修改全局设置。
previous := runtime.GOMAXPROCS(2)
defer runtime.GOMAXPROCS(previous) // 恢复的是进入实验时的数值。
// 在这里执行已有的固定负载，并记录延迟、吞吐与 CPU 使用情况。

这段代码不包含真实负载，也不证明设置为 2 更快。不要在多个并发测试或 HTTP 请求里各自“设置再恢复”，它修改的是进程全局状态，互相覆盖会让对照失去意义。

恢复旧数值与恢复默认策略不同

当前运行时文档说明，默认值可能结合 CPU 数量、亲和性和 Linux cgroup CPU 配额选择；手动设置环境变量或调用 GOMAXPROCS 会影响默认自动更新机制。旧 Go 版本、项目语言版本和 GODEBUG 配置会影响实际行为，不能把所有容器里的默认值都简单等同于机器核数。

前面 defer 恢复 previous，只恢复一个固定数值。如果需要回到运行时默认策略，在 Go 1.25 及以上可使用下面的接口；旧工具链不能直接编译这段代码。

// Go 1.25 及以上：回到运行时默认选择机制，而非固定旧数值。
// 自动更新是否开启还要结合 GODEBUG 和项目语言版本配置。
runtime.SetDefaultGOMAXPROCS()

发布时通过环境配置固定并行度的服务，也应在恢复部署配置后确认进程生效状态。不要只修改配置文件，却继续观察未重启的旧实例；也不要把“恢复旧值”和“重新启用默认策略”记录成同一动作。

把调整结果落到业务指标

调整期间至少观察吞吐、请求延迟分布、CPU 使用与调度等待。业务若主要被数据库、网络或互斥竞争限制，改变 Go 代码并行度未必带来收益。线程数没有按比例变化也不是失败标准。

若延迟明显恶化，按既定部署方式恢复原配置或恢复默认选择策略，再在同负载下复查。留下二进制 Go 版本、GOMAXPROCS 来源、容器资源约束和实验窗口，避免下次只拿一个线程数截图讨论调度。

如果真正需要限制并发任务数量，应使用业务工作池或信号量；如果需要约束整个进程 CPU 使用，则应按部署平台设置资源控制。它们与 GOMAXPROCS 解决的不是同一个问题。

常见问题

GOMAXPROCS=1 是否只剩一个 goroutine？

不会。goroutine 仍可创建和并发推进，只是用户 Go 代码的同时执行能力受限。

设置为 2 后看见更多线程，是设置失败吗？

不是这种判断方式。先读取实际 GOMAXPROCS，再核对线程状态与业务表现。

恢复 previous 能恢复自动选择吗？

仅能恢复数值。需要恢复默认选择机制时，应按工具链版本与 GODEBUG 配置选择相应方式。