绝大多数 Go 程序无需手动设置 runtime.GOMAXPROCS，因 Go 1.5+ 默认已设为 runtime.NumCPU() 并启动生效；盲目调高反致调度延迟上升、GC 效率下降、p99 毛刺加剧，无效主因是误判瓶颈——如锁竞争、I/O 阻塞、容器未适配 cgroup 限额或初始化后修改。
绝大多数 Go 程序根本不需要手动设置 runtime.GOMAXPROCS——Go 1.5+ 默认已设为 runtime.NumCPU() 并在启动时生效；盲目调高不仅不提速，反而会拉高调度延迟、恶化 GC 效率、放大 p99 毛刺。
为什么改了 runtime.GOMAXPROCS 却没效果
这不是配置失败，而是你误判了瓶颈所在。常见无效场景：
- 代码里大量用
time.Sleep()、sync.Mutex全局锁，或channel同步阻塞：P 多了也得排队等，不释放 CPU 时间 - 数据库连接池
max=1或 JSON 解析串行化：并发请求全卡在同一个临界区，GOMAXPROCS再大也无济于事 - 启动后才调用
runtime.GOMAXPROCS(n)：部分init函数和包级变量已在旧 P 下初始化，调整不回溯 - HTTP 服务本身不耗 CPU（纯转发/轻量响应）：多 P 反而增加调度竞争，
GOMAXPROCS(1)有时更稳 - 容器环境未适配 cgroup 限额：
runtime.NumCPU()返回的是宿主机逻辑核数，不是容器实际能用的 vCPU
容器中 GOMAXPROCS 应该设多少
别直接用 runtime.NumCPU()。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，比代码写死更易配置化
GOMAXPROCS 对不同 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 倍）
真正容易被忽略的点是：它影响的不只是并发度，还牵连 GC 行为和内存分配效率。GOMAXPROCS 越大，GC 的并行 mark worker 数也越多，但如果堆对象分布不均，反而造成 mark 阶段各 P 工作量失衡，延长 STW 时间。另外，容器里第三方 SDK（比如 tracing agent）可能在 init 阶段偷偷覆盖你设的值，务必用 runtime.GOMAXPROCS(0) 启动后立刻验证实际值。
