runtime.gomaxprocs(n)实际修改的是可同时执行go代码的p（逻辑处理器）数量，而非os线程数或cpu核心绑定关系；它触发stw重分配p数组，影响调度能力与队列负载均衡。
runtime.GOMAXPROCS(n) 实际改的是什么
它只改变「当前可被 M 绑定并执行 Go 代码的 P 的数量」，不是线程数，也不是 CPU 核心映射关系。每个 P 持有一个长度上限为 256 的本地运行队列（runq），超出部分会进全局队列——而全局队列访问需加锁，延迟更高。
调用 runtime.GOMAXPROCS(n) 会触发一次短暂 STW（stop-the-world）小窗口，重分配 P 数组：若 n 减小，多余 P 进入空闲链表；若增大，则从空闲链表或新建 P 补足。已绑定的 M 不会立即重调度，只影响后续新创建的 M。
- 容器环境常见坑：
runtime.NumCPU()返回宿主机核数，而非容器实际可用核数，容易导致 P 过多 - 云函数等短生命周期场景设高毫无意义，冷启动开销可能盖过调度收益
- 绝不要在 goroutine 里调用——它是全局生效、非并发安全的操作
GOMAXPROCS 设太高反而拖慢性能的典型表现
当 P 数远超物理核心数（比如 64 核机器设为 128），会出现大量 P 竞争有限的 M（OS 线程），M 频繁切换上下文，cache line false sharing 加剧，runtime.findrunnable 和 runtime.schedule 在 pprof 中占比异常升高。
go tool trace 里常看到：多个 P 处于 idle 状态，但大量 G 堆在 channel receive 或系统调用上；或 sysmon 抢占延迟拉长，计算密集型 goroutine “饿死”其他任务达数百毫秒。
- I/O 密集型服务盲目设高（如 64），可能掩盖不了 syscall 延迟，反而因 work-stealing 频繁引入额外开销
- CPU 密集型任务设过高，不会提升吞吐，只会增加抢占和调度抖动
- P > 256 无效：Go 运行时硬上限为 256，再大也截断
不同负载类型下 GOMAXPROCS 的合理取值参考
默认值（runtime.NumCPU()）对通用服务够用，但真实瓶颈常不在 CPU 而在 I/O、锁或 GC。调整前务必用 go tool pprof 和 go tool trace 定位：
- CPU 密集型：P 接近物理核心数（非超线程数），例如 8 核物理 CPU，设
GOMAXPROCS=8 - I/O 密集型：可适度提高（如 ×1.5），但超过 16–32 后边际收益极低；重度依赖 DB/HTTP 的服务，反而设
2–4更稳 - 嵌入式或内存受限场景：设
1可降低 runtime 内存占用（每个 P 约占几 KB） - 含大量阻塞式 cgo 或 syscall 的场景：适当提高有助于解耦阻塞 M 与 P，让其他 M 快速接管空闲 P
真正容易被忽略的细节
P 的本地队列满 256 就溢出到全局队列，而全局队列的获取要竞争锁，且不参与 work-stealing——这意味着一旦局部队列压满，后续 goroutine 调度延迟会突增。很多看似“CPU 利用率低但响应卡顿”的问题，根源是 P 队列结构失衡，而非 GOMAXPROCS 设得不够高。
另外，runtime.LockOSThread() 不影响 P 数量，只绑定 M；sysmon 抢占靠 SIGURG，但前提是 goroutine 有安全点（函数调用、栈增长、goroutine 切换等），纯循环无调用则无法及时让出。
