runtime.gomaxprocs 设置 go 程序可使用的 os 线程数（m），非提速开关；默认为 cpu 核数，盲目调高反增调度开销，仅在明确调度瓶颈时按需调整，并需与容器 cpu 限制对齐。
runtime.GOMAXPROCS 是什么，改它真能提速？
它只是设置 Go 程序能同时使用多少个 OS 线程（M）来运行 goroutine，不是“CPU 核心数越多越快”的开关。默认值是 runtime.NumCPU()，但设成 100 并不会让程序变快——反而可能因调度开销上升而变慢。
常见错误现象：runtime.GOMAXPROCS(1) 后 CPU 使用率卡在 100%，但吞吐没涨，甚至下降；或者压测时把值设得远超物理核数，pprof 显示大量 runtime.mcall 和 runtime.gopark 调用。
- IO 密集型服务（如 HTTP API）通常不需要调大，甚至
runtime.GOMAXPROCS(2)都够用 - CPU 密集型任务（如图像批量处理、数值计算）才值得尝试调高，但也别盲目 > 物理核数
- 容器环境里注意：Docker/K8s 的
--cpus或resources.limits.cpu限制的是 vCPU，runtime.GOMAXPROCS应与之对齐，否则会争抢或闲置
什么时候该手动调，而不是用默认值？
只在明确观察到调度瓶颈时才动它。比如 pprof 的 goroutine profile 显示大量 goroutine 长时间处于 runnable 状态，且 scheduler trace 里有持续的 M 阻塞或 P 饥饿。
典型场景：
立即学习“go语言免费学习笔记（深入）”；
- 单机部署多个 Go 进程，每个都默认用满所有核 → 实际应按进程数均分，比如 8 核跑 4 个服务，每个设
runtime.GOMAXPROCS(2) - 混合部署 Java/Go 服务，Java 用了
-XX:ParallelGCThreads锁定线程数，Go 进程需主动让出资源，避免争抢 - 测试环境用
GOMAXPROCS=1复现数据竞争（配合-race），但上线必须关掉
怎么安全地设置和验证效果？
不要在 init 或 main 开头硬编码 runtime.GOMAXPROCS(n)，优先用环境变量 GOMAXPROCS 启动时控制，便于不同环境差异化配置。
验证是否生效：
- 启动后立刻打印
runtime.GOMAXPROCS(0)返回值（它只读不设，返回当前值） - 用
go tool trace查看Scheduler视图中 P 的数量是否匹配 - 对比压测指标：QPS 变化不大但 p99 延迟明显升高 → 很可能是 GOMAXPROCS 过大导致上下文切换激增
示例（启动时控制）：
GOMAXPROCS=4 ./myserver
代码中动态调整（慎用）：
runtime.GOMAXPROCS(4) // 仅在确认必要时调用一次，别反复设
容易被忽略的副作用
它影响的不只是并发度，还牵连 GC 行为和内存分配效率。GOMAXPROCS 越大，GC 的并行 mark worker 数也越多，但若堆对象分布不均，反而造成 mark 阶段各 P 工作量失衡，延长 STW 时间。
另一个坑是：某些依赖全局状态的库（比如老版本 github.com/golang/freetype）内部用 sync.Once + 全局变量初始化，在 GOMAXPROCS > 1 且首次调用跨 goroutine 时可能触发竞态，而 -race 不一定捕获到。
最常被漏掉的一点：K8s 中 resources.requests.cpu 小于 limits 时，CFS quota 会周期性 throttled，此时即使 GOMAXPROCS 设得再合理，P 也会被系统强制休眠，表现就是 CPU 使用率上不去、延迟毛刺多——得先看 cat /sys/fs/cgroup/cpu,cpuacct/kubepods/.../cpu.stat 里的 nr_throttled。
