GOMAXPROCS过大会增加上下文切换开销并导致调度器负担加重，因P数远超物理核心使大量M处于就绪但无核可运行状态，引发高频runtime.gopark；应根据CPU密集型任务实际瓶颈调整，I/O密集型设2～4即可，且不可超过物理核心数。
GOMAXPROCS 过大会显著增加上下文切换开销，不是“核越多越快”，而是调度器负担加重
为什么 GOMAXPROCS=100 时 pprof 显示大量 runtime.gopark？
这不是 goroutine 在等待 I/O，而是调度器在频繁尝试唤醒、挂起 M（OS 线程）——因为 P 数远超可用 CPU 核心，大量 M 处于“就绪但无核可跑”状态。runtime.gopark 表示 M 主动让出执行权，本质是调度器在做无效轮询。
-
runtime.gopark高频出现，往往伴随runtime.mcall和scheduler trace中 P 的“饥饿”（P.runqsize 长期为 0 但有 runnable G） - 容器环境里
runtime.NumCPU()返回的是宿主机核数，不是 cgroups 限制的 vCPU，必须用GOMAXPROCS环境变量对齐容器--cpus=2，否则会创建 64 个 P 却只被分配 2 个物理时间片 - 实测：在 4 核机器上设
GOMAXPROCS=32，QPS 不升反降 15%，perf stat -e context-switches显示上下文切换次数翻 3 倍
什么时候该调大 GOMAXPROCS？只看 CPU 密集型任务的实际瓶颈
HTTP server、数据库 client、日志写入等 I/O 密集型逻辑，GOMAXPROCS 设成 2～4 就够用；真正需要调大的，是那种纯计算、无阻塞、能填满 CPU 的场景，比如批量图像缩放、矩阵乘法、密码学哈希。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 调大前先确认：pprof CPU profile 显示
runtime.mstart或runtime.schedule占比 >10%，且runtime.findrunnable耗时明显 - 不要超过物理核心数（非逻辑核），超线程（Hyper-Threading）带来的额外逻辑核对 Go 调度收益极低，甚至因缓存争抢拖慢
- 多进程部署时，要均分：8 核跑 3 个 Go 服务，每个设
GOMAXPROCS=2或GOMAXPROCS=3，避免某进程独占全部资源
如何验证 GOMAXPROCS 是否生效且合理？
别信代码里写的值，以运行时实际读取为准。启动后立刻打日志：fmt.Println("GOMAXPROCS =", runtime.GOMAXPROCS(0))，再结合 trace 工具看 P 数是否匹配。
立即学习“go语言免费学习笔记（深入）”；
- 用
go tool trace打开 trace 文件，在 Scheduler 标签页观察 P 的数量和活跃曲线，P 数应稳定等于你设置的值，且无长期空闲或持续抢占 - 压测时对比指标：若
p99延迟升高但 CPU 使用率没涨，大概率是调度开销导致；若NumGoroutine持续 >10k 且runtime.schedt调用陡增，说明 P 不够用或 GC 干扰 - GC 行为也会被牵连：
GOMAXPROCS越大，GC mark worker 数越多，但若堆对象分布不均，反而造成各 P mark 时间差异拉大，延长 STW
最容易被忽略的点：GOMAXPROCS 不只是并发开关，它直接决定调度器维护的 P 结构体数量、GC 并行 worker 数、甚至 netpoller 的轮询频率。改它之前，先确认瓶颈真在调度器，而不是 channel 阻塞、锁竞争或内存分配过热。
