Go runtime.GOMAXPROCS 改小后延迟为何变高

把 runtime.GOMAXPROCS 从 8 调到 2 后，CPU 使用率可能更平稳，但接口 p95、p99 反而上升。最常见的原因不是 goroutine 变少，而是可同时执行 Go 代码的处理器槽位变少，繁忙时更多 goroutine 只能留在 runnable 队列里等待。反过来，在容器中把它设得远高于有效 CPU 配额，也可能触发 cgroup throttling，让尾延迟更差。

判断 GOMAXPROCS 是否应该调小，先看它与有效 CPU limit 的关系，再看 runnable 排队、CPU throttling 和 GC 工作；不能只凭 CPU 百分比或单次压测结论改值。

先确认 GOMAXPROCS 到底受什么约束

不要先拿 runtime.NumCPU() 当答案。在没有手动覆盖时，运行时会综合逻辑 CPU 数、进程 CPU 亲和性，以及 Linux 上的 cgroup CPU 吞吐限制决定默认 GOMAXPROCS。容器里的 CPU limit 是吞吐额度，不等于宿主机可见的核心总数。

Go 1.25 起，默认值会在这些输入变化时周期更新，频率最多约每秒一次；CPU 配额是小数时会向上取整，而且运行时不会把默认值降到 2 以下，除非逻辑 CPU 数或亲和性本身少于 2。下面这段只查询当前值，不修改调度参数：

package main

import (
	"fmt"
	"runtime"
)

func printCPUInputs() {
	// 传入 0 只查询当前 GOMAXPROCS，不改变运行时设置。
	current := runtime.GOMAXPROCS(0)
	// NumCPU 是可见逻辑 CPU 参考值，不一定等于容器的有效 CPU limit。
	visible := runtime.NumCPU()
	fmt.Printf("GOMAXPROCS=%d NumCPU=%d\n", current, visible)
}

参数过小和过大，延迟变高的原因不同

GOMAXPROCS 是并行度上限。假设服务有 20 个 runnable goroutine，但 GOMAXPROCS 只有 2，调度器仍会在两个处理器槽位上轮换它们；当每个任务都需要较多 CPU 时间时，队列等待会直接进入请求耗时。网络 I/O 较多的服务未必受影响，纯计算、压缩、加密和高分配路径更容易放大这个差异。

把值调大也不是免费的。若 GOMAXPROCS 明显高于容器 CPU limit，短时并发可能先冲高线程 CPU 消耗，随后被 cgroup 按周期限流。限流会暂停一段执行时间，所以平均 CPU 看起来不高，p99 却可能抬升；GC 的标记、清扫和辅助工作也会参与这类 CPU 峰值。

用同一负载区分排队和 CPU 限流

排查时一次只改一个变量，至少保留三组对照：运行时默认值、明显偏小的值、贴合有效 CPU limit 的值。固定请求速率、请求体、缓存命中率和实例规格，分别记录 p50、p95、p99、CPU 使用时间、runnable goroutine 和 throttling。没有这些对照，单看“调小后变慢”无法证明是调度槽位不足。

可以把 /sched/gomaxprocs:threads 作为当前并行度指标，并结合 CPU 类指标观察 Go 代码、GC 和空闲时间。指标用于解释趋势，不等于完整的性能归因；真正的结论仍要回到同一业务负载下的延迟分位数。

调整策略：先恢复默认，再做小步灰度

如果没有明确的 CPU 配额模型，不建议在初始化代码里永久写死一个“经验值”。Go 1.25 及以上的容器服务可以先让运行时使用默认判断；确实需要手动设置时，把它视为和 CPU limit 绑定的部署参数，而不是全局常量。改动前记录旧值和回滚方式，改动后用一小部分实例比较尾延迟、限流和 GC。

还要注意手动设置的副作用：设置 GOMAXPROCS 环境变量或调用 runtime.GOMAXPROCS 会关闭默认值的自动更新。CPU limit 会动态调整的容器尤其容易因此失去适配能力。若只是想在运行中恢复默认行为，Go 1.25 提供了 runtime.SetDefaultGOMAXPROCS，但仍应把调用时机和回滚策略写进部署方案。

相关问题

GOMAXPROCS 调小会限制 goroutine 数量吗？

不会。goroutine 仍可以创建和阻塞等待；参数限制的是同一时刻执行用户 Go 代码的处理器数量，阻塞在系统调用里的线程不计入这个上限。

为什么 CPU 使用率下降，延迟却升高？

如果参数变小，部分 goroutine 会在 runnable 队列等待，CPU 槽位没有被充分利用的同时，请求排队时间增加；CPU 百分比下降并不能排除并行度不足。

容器里应该把 GOMAXPROCS 设成 CPU request 吗？

不能直接这样推断。Go 1.25 默认主要参考 CPU limit，而不是 CPU request；最终仍应依据实际限额、负载形态和尾延迟对照决定。