绝大多数 Go 程序无需手动设置 runtime.GOMAXPROCS——Go 1.5+ 默认已设为 runtime.NumCPU() 并启动生效；盲目调高会加剧调度竞争、升高延迟、降低 GC 效率；无效场景包括全局锁、串行瓶颈、启动后修改、容器中未适配 cgroup 限额，以及 I/O 密集型服务误设过高值。
绝大多数 Go 程序不需要手动调用 runtime.GOMAXPROCS——Go 1.5+ 默认已设为 runtime.NumCPU()，且该值在启动时自动生效。盲目修改反而引发调度延迟上升、runtime.mcall 暴涨、GC 效率下降。
为什么改了 runtime.GOMAXPROCS 却没效果
这不是配置失败，而是你误判了瓶颈所在。常见无效场景：
- 代码里大量用
time.Sleep()、sync.Mutex全局锁，或 channel 同步阻塞：P 多了也得排队等，不释放 CPU 时间 - 数据库连接池
max=1或 JSON 解析串行化：并发请求全卡在同一个临界区，GOMAXPROCS再大也无济于事 - 启动后才调用
runtime.GOMAXPROCS(n)：部分init函数和包级变量已在旧 P 下初始化，调整不回溯 - HTTP 服务本身不耗 CPU（纯转发/轻量响应）：多 P 反而增加调度竞争，
GOMAXPROCS(1)有时更稳
容器环境必须手动适配 GOMAXPROCS
runtime.NumCPU() 返回的是宿主机逻辑核数，不是容器实际能用的 vCPU。Kubernetes 中 resources.limits.cpu: "2" 是软限，但 Go 默认仍开 64 个 P，导致 goroutine 在少数 OS 线程上争抢，schedlat 持续 >100µs。
- 验证真实可用核数：
cat /sys/fs/cgroup/cpu/cpu.cfs_quota_us /sys/fs/cgroup/cpu/cpu.cfs_period_us，再算quota / period - Go 1.19+ 可启用自动适配：
GODEBUG=schedtrace=1000启动，观察日志是否含auto-adjusting GOMAXPROCS - 手动适配优先读 cgroup 文件，而非硬编码或依赖
resources.limits.cpu值（burst 行为会让除法结果失真） - 环境变量方式最安全：
GOMAXPROCS=2 ./myserver，比代码写死更易配置化
不同 workload 类型的推荐设置
GOMAXPROCS 控制的是“能同时执行用户代码的逻辑处理器(P)数量”，不是并发任务数，也不影响 netpoller 或 channel 行为。选值取决于真实负载特征：
立即学习“go语言免费学习笔记（深入）”；
- CPU 密集型（数值计算、图像批处理）：从
runtime.NumCPU()起步，压测时观察go tool trace中 “Scheduler latency” 和 “Proc status” 是否出现 P 饥饿 - I/O 密集型（HTTP API、DB 查询为主）：默认值通常最优；极端情况可试
GOMAXPROCS(1)，减少调度竞争，反而降低 p99 延迟 - 混合型（JSON 解析 + DB 调用）：先用默认值压测，再结合
pprof分析 CPU 热点，判断是否需下调（如设为核数的 0.7 倍）
真正容易被忽略的点是：它只在程序启动时决定 P 的初始数量，后续动态调整虽可行，但无法重放已初始化的 goroutine；而且它牵连 GC 行为——GOMAXPROCS 越大，GC 的并行 mark worker 数越多，若堆对象分布不均，反而延长 STW 时间。
