GOMAXPROCS 无效或变慢的根本原因是它仅限制同时运行的 OS 线程数，而非协程数；盲目增大在 I/O 密集型场景会加剧线程切换开销，且需在 main 开头设置才生效，误设位置或动态调整反致调度异常。
为什么改了 GOMAXPROCS 没效果，甚至更慢？
多数人调 GOMAXPROCS 是为了“提升并发性能”，但实际常看到 CPU 利用率没涨、延迟反而升高。根本原因在于：它不控制协程数量，只限制**同时运行的 OS 线程数**；若程序本身是 I/O 密集型或大量阻塞系统调用，盲目增大只会增加线程切换开销。
-
GOMAXPROCS默认值是机器逻辑 CPU 数（Go 1.5+），不是“越大越好”——比如在 64 核机器上设为 64，但业务只有 4 个长期活跃 goroutine，其余全是休眠态，那 60 个空转线程纯属浪费 - 当 goroutine 频繁执行
syscall（如文件读写、net.Conn.Read）、调用 cgo 或陷入runtime.entersyscall，M（OS 线程）会被挂起，此时需要更多 M 来维持 G 的调度，这时才可能受益于略高于 CPU 数的GOMAXPROCS - Go 1.19+ 引入
runtime.LockOSThread和更激进的 M 复用策略，使得过高的GOMAXPROCS在非必要场景下更容易触发线程争抢和 cache line false sharing
GOMAXPROCS 该在哪儿设？什么时候必须设？
它不是启动参数，也不是全局配置项，而是一个运行时可变的调度上限。设错位置会导致完全无效。
- 必须在
main函数开头、任何 goroutine 启动前调用：runtime.GOMAXPROCS(n)；若在init()里设，但包被其他包提前 import，就可能被覆盖 - 动态调整可行但危险：多次调用会立即生效，但若当前有大量 goroutine 正在迁移，可能短暂卡顿；生产环境不建议在运行中反复修改
- 真正需要手动设的场景极少：比如容器化部署时，cgroup 限制了可用 CPU（如
cpus=1.5），而 Go 默认按/proc/cpuinfo读到的是宿主机核数，这时应设为floor(cpus * 100) / 100对应的整数（如 1.5 → 1） - 交叉编译或嵌入式目标（如 ARM64 小内存设备）建议显式设为 1 或 2，避免默认值误判
怎么验证 GOMAXPROCS 是否生效、是否合理？
不能只看 top 或 htop 的 CPU%，得盯住调度器指标。
- 用
runtime.NumGoroutine()+runtime.NumCgoCall()观察协程活跃度，再对比runtime.GOMAXPROCS(0)返回的实际值——如果前者远大于后者且runtime.ReadMemStats显示MCacheInuse持续飙升，说明 M 不够用 - 开启
GODEBUG=schedtrace=1000（每秒输出调度器快照），重点看SCHED行里的mprocs（即当前GOMAXPROCS值）和idle/runnableM 数比例；若长期idle > 0且runnable == 0，说明线程过剩 - pprof 的
goroutineprofile 能暴露阻塞点：若大量 goroutine 停在select、chan receive或netpoll，说明瓶颈不在 CPU 调度，调GOMAXPROCS无意义
和 GMP 调度器的关系到底是什么？
GOMAXPROCS 只是 GMP 中最表层的 knob，它不决定 G 如何排队、M 如何绑定 P、P 如何窃取任务——那些由调度器自动完成，且无法手动干预。
立即学习“go语言免费学习笔记（深入）”；
- P（Processor）的数量 =
GOMAXPROCS当前值；每个 P 维护自己的本地运行队列（runq），长度默认 256；超过则扔进全局队列（runqsize会增长） - 当一个 P 的本地队列空了，它会尝试从其他 P 的本地队列“偷”一半任务（work-stealing），这个过程不依赖
GOMAXPROCS，但 P 数太少会导致偷不到、全局队列积压 - 真正影响调度延迟的是 P 的数量与真实并发负载的匹配度：比如 8 个 P，但每秒有 1000 个短生命周期 goroutine 创建/退出，P 的上下文切换成本会显著高于 32 个 P —— 但 32 个 P 又可能让每个 P 的本地队列太短，频繁触发全局队列访问
所以没有“最优值”，只有针对具体 workload 的测量边界。别信网上流传的“设成 CPU 数×2”，那只是某些特定批处理场景下的经验值，不是通解。
