GOMAXPROCS不是并发加速器，仅控制同时运行Go代码的OS线程数（P的数量），不增加goroutine总数，也不解决I/O阻塞或锁竞争；设过高反而引发调度抖动、cache false sharing和GC失衡。
GOMAXPROCS 不是并发加速器，设高了反而拖慢程序——它只控制同时运行 Go 代码的 OS 线程数（即 P 的数量），不增加 goroutine 总数，也不解决 I/O 阻塞或锁竞争。
为什么 runtime.GOMAXPROCS(4) 后 CPU 利用率没涨、QPS 却卡住
常见错误现象：runtime.GOMAXPROCS(4) 启动后 top 显示 CPU 使用率仅 20%～30%，压测 QPS 上不去，pprof 却显示大量 goroutine 处于 syscall 或 chan receive 状态。
根本原因不是调度器没干活，而是这些 goroutine 正在等：文件读写、DNS 查询、数据库响应、channel 阻塞、未设 timeout 的 HTTP 调用。此时 P 被占着但没执行用户代码，再多 M 也无济于事。
- 优先检查阻塞源头：用
go tool trace查 “Sched” 视图里灰色（阻塞）时间段是否密集；用curl 'http://localhost:6060/debug/pprof/goroutine?debug=2'看堆栈是否集中在read、net.Conn.Read或select上 - I/O 密集型服务（如 API 网关、日志转发）通常不需要调大
GOMAXPROCS，默认值（runtime.NumCPU()）甚至2就够用 - 若业务逻辑本身含长耗时计算（如图像缩放、加密解密），才值得尝试调高；但别超过物理核心数，64 核机器设成 64 很可能不如设成 16
容器环境里 GOMAXPROCS=8 却跑满宿主机 32 核怎么办
典型错误：Docker 启动时加了 --cpus=2，但 Go 程序里仍调用 runtime.GOMAXPROCS(runtime.NumCPU())，结果返回 32，导致线程争抢、cache false sharing 加剧。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
容器内 runtime.NumCPU() 返回的是宿主机逻辑核数，不是 cgroups 限制值。必须对齐 vCPU 配额。
- 启动时优先用环境变量：
GOMAXPROCS=2 ./myserver，比代码里硬编码更安全、更易配置化 - Kubernetes 中通过
resources.limits.cpu: "2"限制后，在 Deployment 的env里显式设置GOMAXPROCS=2 - 若必须代码中设，改用
os.Getenv("GOMAXPROCS")解析后转为 int 再调用runtime.GOMAXPROCS(n)，避免 fallback 到NumCPU() - 验证是否生效：启动后立刻打印
runtime.GOMAXPROCS(0)，并用go tool trace确认 Scheduler 视图中 P 的数量匹配
什么时候该动 GOMAXPROCS，而不是埋头加 goroutine
盲目开 1000 个 goroutine + runtime.GOMAXPROCS(100) 是最常见误区。真正需要调整 GOMAXPROCS 的信号很窄，且必须可观测。
- pprof 的
goroutineprofile显示大量 goroutine 长时间处于runnable状态（非waiting或syscall） -
go tool trace的 “Scheduler” 视图中出现持续的P idle或M blocked，且findrunnable占比异常高 - 单机部署多个 Go 进程（如 8 核跑 4 个服务），每个都默认用满所有核 → 应均分，例如设为
2 - 混合部署 Java/Go，Java 用了
-XX:ParallelGCThreads=4，Go 进程需主动让出资源，避免争抢 CPU 和内存带宽
动态修改 runtime.GOMAXPROCS 的副作用你未必知道
很多人以为“设一次就行”，但实际修改会牵连 GC 行为和内存分配效率，尤其在高负载下容易被忽略。
-
GOMAXPROCS增大会同步提升 GC mark 阶段的并行 worker 数，但如果堆对象分布不均（比如大量小对象集中在某几个 span），会导致各 P 工作量失衡，反而延长 STW 时间 - Go 1.19+ 引入更激进的 M 复用策略，
GOMAXPROCS过高时更容易触发线程争抢和 cache line false sharing，表现为延迟毛刺而非吞吐下降 - 测试环境用
GOMAXPROCS=1复现数据竞争（配合-race）可行，但上线必须关掉——它会掩盖真实调度行为，让压测结果失真 - 不要在 handler 或 goroutine 内反复调用
runtime.GOMAXPROCS(n)，仅在main()开头设一次；后续修改虽有效，但会引发调度抖动
最常被忽略的一点：GOMAXPROCS 影响的从来不只是“能不能并行”，而是整个调度器与 GC 的协同节奏。没配 pprof、没看 trace、没确认阻塞类型就调参数，等于蒙眼调油门。
