runtime.GOMAXPROCS不是教学工具，而是调度器实际控制开关，调优需基于真实CPU利用率与延迟；盲目调整会掩盖锁、IO、连接池等真正瓶颈，应结合workload类型、cgroup限额及trace/pprof数据动态决策。
runtime.GOMAXPROCS 不是用来“学多核语言”的配置项，它是 Go 运行时调度器的一个实际控制开关，调优与否取决于你是否真正在意程序在真实环境中的 CPU 利用率和延迟表现。
它不是教学工具，也不是并发模型的入门概念；盲目设高或设低，反而会掩盖你代码里真正的瓶颈——比如串行锁、阻塞 I/O、单点数据库连接池。
为什么改了 runtime.GOMAXPROCS 却没提速
这不是设置失败，而是你误判了瓶颈位置：
- 代码里有
time.Sleep(100 * time.Millisecond)或大量sync.Mutex全局锁：P 多了也得排队等，不释放 CPU 时间 - HTTP handler 里调用了
database/sql查询但MaxOpenConns=1：所有 goroutine 卡在连接获取上，GOMAXPROCS 再大也无用 - 启动后才调用
runtime.GOMAXPROCS(n)：部分init函数已在旧 P 下完成初始化，调整不回溯 - 容器中未读 cgroup 限额：
runtime.NumCPU()返回的是宿主机核数（比如 64），而容器只被分配了 2 个 vCPU，结果 64 个 P 在 2 个 OS 线程上争抢，schedlat持续 >100µs
容器环境下必须手动适配 GOMAXPROCS
Kubernetes 的 resources.limits.cpu: "2" 是软限，Go 默认仍开 64 个 P。正确做法是：
立即学习“go语言免费学习笔记（深入）”；
- 优先读取 cgroup 文件：
/sys/fs/cgroup/cpu/cpu.cfs_quota_us和/sys/fs/cgroup/cpu/cpu.cfs_period_us，算出真实可用核数（quota / period） - 不要硬编码或直接用
resources.limits.cpu值——burst 行为会让除法结果失真 - Go 1.19+ 可启用自动适配：
GODEBUG=schedtrace=1000启动，观察日志是否含auto-adjusting GOMAXPROCS - 最稳妥方式仍是环境变量：
GOMAXPROCS=2 ./myserver，比代码写死更易配置化、更早生效
GOMAXPROCS 值该设多少：看 workload 类型，不是看核数
GOMAXPROCS 控制的是“能同时执行用户代码的逻辑处理器（P）数量”，不是并发任务数，也不影响 netpoller 或 channel 行为：
- CPU 密集型（数值计算、图像批处理）：从
runtime.NumCPU()起步，压测时重点看go tool trace中 “Scheduler latency” 和 “Proc status” 是否出现 P 饥饿 - I/O 密集型（HTTP API、DB 查询为主）：默认值通常最优；极端情况可试
GOMAXPROCS(1)，减少调度竞争，反而降低 p99 延迟 - 混合型（JSON 解析 + DB 调用）：先用默认值压测，再结合
pprof分析 CPU 热点；若发现解析占 CPU 大头且线性可分，可下调为核数的 0.7 倍
真正容易被忽略的一点：GOMAXPROCS 调整本身不解决锁竞争、GC 压力或内存带宽瓶颈——它只是把已有负载摊到更多 P 上。如果负载本身不能并行，调再高也没用。
