合理值取决于工作负载类型：计算密集型设为runtime.numcpu()，i/o密集型可设为1，混合型需压测调优；容器中应适配cgroup限制而非宿主机核数。
runtime.GOMAXPROCS 设置多少才合理
默认值是机器的逻辑 CPU 核心数，但不等于“设成这个数就一定最优”。它控制的是可同时执行用户级 Go 代码的操作系统线程（M）上限，不是并发任务数，也不是 goroutine 调度器的并行度开关。
实际调优要看 workload 类型：
- 纯计算密集型（如数值运算、图像处理）：设为
runtime.NumCPU()通常合适；设高了反而因线程切换增加开销 - I/O 密集型（如 HTTP 服务、数据库查询）：
runtime.GOMAXPROCS(1)有时反而更稳——goroutine 本身不阻塞调度器，I/O 等待由 netpoller 异步处理，多 P 反而加剧调度竞争 - 混合型服务（比如带 JSON 解析 + DB 查询的 API）：建议从
runtime.NumCPU()开始压测，观察go tool trace中的“Proc status”和“Scheduler latency”指标变化
为什么改了 GOMAXPROCS 没效果
常见错觉是“改完立刻提升吞吐”，但多数时候没变化，甚至变差。根本原因是：GOMAXPROCS 不影响 goroutine 创建、调度或阻塞行为，只限制“能并行跑用户代码”的 P 的数量。
典型无效场景：
立即学习“go语言免费学习笔记（深入）”；
- 代码里大量用
time.Sleep()或同步 channel 操作：这些不触发 OS 线程让出，P 被占着但没干活 - 存在全局锁（如滥用
sync.Mutex）或串行瓶颈（如单个数据库连接池 max=1）：P 多了也得排队 - 程序启动后才调用
runtime.GOMAXPROCS(n)：部分初始化逻辑（如init函数、包级变量构造）已在默认 P 下完成，后续调整不回溯
验证是否生效？运行时打印：fmt.Println(runtime.GOMAXPROCS(0)) —— 参数为 0 表示只读，返回当前值。
在容器环境里设 GOMAXPROCS 的坑
容器（尤其是 Kubernetes）常通过 cpu.shares 或 cpu.quota 限制 CPU 使用，但 runtime.NumCPU() 读的是宿主机的逻辑核数，不是容器 cgroup 的可用核数。
结果就是：容器只分到 0.5 核，Go 却开了 32 个 P，大量 goroutine 在 P 间争抢，schedlat（调度延迟）飙升，Goroutines/second 不升反降。
安全做法：
- 优先使用 Go 1.19+ 的自动适配：设置环境变量
GODEBUG=schedtrace=1000观察是否启用auto模式 - 手动适配：读取
/sys/fs/cgroup/cpu/cpu.cfs_quota_us和/sys/fs/cgroup/cpu/cpu.cfs_period_us计算可用核数，再调用runtime.GOMAXPROCS(n) - K8s 场景下，避免用
resources.limits.cpu直接除以 1000 当核数——cfs_quota 是软限，burst 行为会让NumCPU()结果失真
要不要在程序里动态调 GOMAXPROCS
不推荐。Go 运行时假设 GOMAXPROCS 在整个生命周期内稳定，动态调整会触发 P 的创建/销毁、mcache 重分配、以及潜在的 stop-the-world 小停顿。
真正需要动态响应的场景极少，比如：
- CLI 工具根据
--cpus参数启动不同并发度 - 嵌入式设备在低电量模式下主动降频并减少 P 数
即便如此，也应在程序启动早期（main 函数开头、任何 goroutine 启动前）一次性设置，而不是运行中反复调用 runtime.GOMAXPROCS()。多次调用不会报错，但调度器内部状态可能进入非预期路径，尤其在 GC 触发期间。
最易被忽略的一点：GOMAXPROCS 影响的是“P 的数量”，而每个 P 绑定一个本地运行队列（runq）。如果 goroutine 创建速率远高于消费速率，即使 P 数足够，runq 积压也会导致新 goroutine 延迟调度——这时该优化的是业务逻辑或 channel 使用方式，不是盲目加 P。
