runtime.GOMAXPROCS不是吞吐量放大器，设为8不会比4快一倍；它仅控制可并行执行用户代码的OS线程数（P的数量），不解决I/O阻塞、锁竞争或GC压力，盲目调高反而引发调度抖动和延迟升高。
runtime.GOMAXPROCS 不是吞吐量放大器
设成 8 就比设成 4 快一倍？基本不会。它只控制可并行执行用户代码的 OS 线程数（即 P 的数量），不解决 I/O 阻塞、锁竞争、GC 压力或 channel 同步开销。压测时 QPS 卡住，runtime.GOMAXPROCS 往往不是瓶颈，而是假象源头。
常见错误现象：
-
runtime.GOMAXPROCS(8)启动后top显示 CPU 利用率仅 25%，但 QPS 上不去 - pprof 显示大量 goroutine 处于
syscall、chan receive或net.Conn.Read状态 - 加到 16 后反而 p99 延迟跳升，
go tool trace中出现密集的runtime.mcall和runtime.gopark
此时真正该查的是：
- DNS 查询是否没设超时
- HTTP 客户端连接池是否太小（如
http.DefaultTransport.MaxIdleConnsPerHost == 2） - 数据库查询是否缺少 context 控制
- 日志写入是否同步阻塞在磁盘 I/O
什么时候调大 GOMAXPROCS 才真有用
只有当调度器本身成为瓶颈时，调整才有意义。信号很窄，必须靠可观测性工具确认，不是靠“我觉得该加”。
有效信号包括：
-
go tool trace的 Scheduler 视图中，P 长期处于runnable状态（非灰色阻塞），且有多个 P 轮空等待 M - pprof
goroutineprofile 显示大量 goroutine 卡在runnable（非waiting或syscall）超过 10ms - 同一台机器跑多个 Go 进程，默认都用满所有核，导致互相争抢：比如 16 核跑 4 个服务，每个应设
runtime.GOMAXPROCS(4) - CPU 密集型任务（如批量图像缩放、RSA 解密）实测单 P 吞吐已达瓶颈，且 pprof 显示 CPU 时间集中在计算路径上
注意：runtime.GOMAXPROCS(0) 会返回当前值，可用于安全恢复；设为负数直接 panic。
容器环境里 runtime.NumCPU() 是个坑
在 Docker 或 Kubernetes 中，runtime.NumCPU() 返回的是宿主机逻辑核数，不是容器实际分配的 vCPU。比如 --cpus=2 的容器里调用 runtime.NumCPU() 可能返回 32，导致线程争抢、cache false sharing 加剧。
正确做法：
- 启动前用环境变量设置：
GOMAXPROCS=2 ./myserver（最简单可靠） - Kubernetes Deployment 中显式声明：
env: [{name: "GOMAXPROCS", value: "2"}] - 若必须代码中设，优先读
os.Getenv("GOMAXPROCS")，解析失败再 fallback，别直接硬编码runtime.NumCPU() - 启动后立刻打印
runtime.GOMAXPROCS(0)，验证是否生效
测试中误用 GOMAXPROCS 的典型陷阱
go test 的并行性跟 runtime.GOMAXPROCS 没直接关系。它控制的是 goroutine 调度粒度，不是测试函数能否一起跑。
常见误解与后果：
- 以为加了
-p 4或设了GOMAXPROCS=8就能让TestA和TestB并行——其实它们默认串行，必须各自调t.Parallel() -
GOMAXPROCS=1下t.Parallel()仍有效，只是所有并行测试共享一个 P，表现为并发而非并行，容易掩盖竞态问题 - CI 环境中其他工具注入了
GOMAXPROCS=1，导致本该暴露的 data race 在本地复现不了 - 并行测试间共享
var db *sql.DB或临时文件路径，没做隔离，出现随机失败
真正影响测试吞吐的是资源隔离质量，不是核心数。设错 GOMAXPROCS 最多让调度更挤，但不会让测试变快——除非你正在压测调度器本身。
