gomaxprocs不是提速开关，设错值反增调度开销；多数服务用默认值即可，仅少数场景需调优，且必须经trace和pprof验证瓶颈后谨慎调整。
GOMAXPROCS 不是“开更多线程就能更快”的开关，设错值反而会让调度器忙于搬任务、不干活；多数服务用默认值就足够，真正需要调的场景其实很少，且必须靠 trace 和 pprof 验证瓶颈后再动。
为什么 runtime.GOMAXPROCS(4) 没让程序变快
它只控制可并行执行 Go 用户代码的逻辑处理器（P）数量，不影响 goroutine 创建、I/O 等待、锁竞争或 channel 阻塞。常见无效调参现象包括：
- 大量
time.Sleep()、sync.Mutex全局锁、无缓冲channel阻塞：P 多了也得排队等，CPU 时间根本没释放 - 数据库连接池
maxOpen=1或 JSON 解析串行化：所有请求卡在同一临界区，GOMAXPROCS再大也无用 - HTTP 服务本身只是轻量转发：多 P 反而抬高调度开销，
GOMAXPROCS(1)有时p99延迟更低 - 启动后才调
runtime.GOMAXPROCS(n)：init 阶段的 goroutine 已绑定旧 P，无法迁移
容器环境必须显式设置，否则默认值会错读宿主机核数
在 Docker 或 Kubernetes 中，runtime.NumCPU() 返回的是宿主机逻辑核数（比如 32），但你的 resources.limits.cpu 可能只有 500m（即 0.5 核）。此时默认开 32 个 P，结果就是 32 个 P 抢 0.5 核，schedlat 拉高，QPS 下跌。
- 安全做法：启动时读取
/sys/fs/cgroup/cpu/cpu.cfs_quota_us和/sys/fs/cgroup/cpu/cpu.cfs_period_us，算出真实 vCPU 数，再调runtime.GOMAXPROCS(n) - 最简方案：用环境变量启动，如
GOMAXPROCS=2 ./myserver，比代码硬编码更易灰度 - Go 1.19+ 可加
GODEBUG=schedtrace=1000观察日志是否出现auto-adjusting GOMAXPROCS
不同 workload 类型该设多少
GOMAXPROCS 不是“核数越多越好”，它控制的是并行执行用户代码的 P 数，选值必须匹配负载特征：
- CPU 密集型（图像转码、数值聚合）：从容器 vCPU 数起步，压测时看
go tool trace中 “Proc status” idle 占比，低于 10% 可尝试微增 - I/O 密集型（HTTP API、DB 中间层）：默认值通常最优；若延迟毛刺多，试
GOMAXPROCS(1)，减少 steal 和上下文切换 - 混合型（JSON 解析 + 外部 HTTP 调用）：先用默认值压测，再用
pprof看 CPU 热点——如果encoding/json占比高，才考虑上调
怎么确认改了真生效、没副作用
别只信代码里写了 runtime.GOMAXPROCS(4)，得确认它真起作用，且没拖垮其他环节：
- 启动后立刻打日志：
fmt.Println("GOMAXPROCS =", runtime.GOMAXPROCS(0)) - 用
go tool trace打开 Scheduler 视图，检查 P 数量是否匹配，且 “idle” 时间不过长 - 压测对比：QPS 不变但
p99延迟明显升高 → 很可能是GOMAXPROCS过大导致runtime.mcall暴增 - 修改必须在
main()开头完成，http.ListenAndServe或任何 goroutine 启动前——晚了部分 goroutine 已按旧配置绑定 P，无法回溯
真正难的不是设哪个数，而是判断“到底要不要设”。绝大多数性能问题根子不在 P 数，而在阻塞点、锁粒度、内存分配或外部依赖延迟；盲目调 GOMAXPROCS 就像给堵车路口多修几条车道，却不管红绿灯配时和事故车清障。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
