runtime.GOMAXPROCS不是并发加速器，仅控制同时执行用户代码的OS线程数（P数量），设高反增调度开销；I/O密集型服务通常无需调大，真正需调整仅限可观测到P饥饿或M阻塞等明确调度瓶颈时。
runtime.GOMAXPROCS 不是并发加速器，它只控制同时执行 Go 用户代码的 OS 线程数（即 P 的数量），设高了反而容易拖慢程序。
runtime.GOMAXPROCS 设高后 CPU 利用率没涨、QPS 却卡住
- 常见错误现象：
runtime.GOMAXPROCS(4)启动后top显示 CPU 使用率仅 20%～30%，压测 QPS 上不去，pprof却显示大量 goroutine 处于syscall或chan receive状态 - 根本原因不是调度器没干活，而是这些 goroutine 正在等：文件读写、DNS 查询、数据库响应、channel 阻塞、未设
timeout的 HTTP 调用 - 此时 P 被占着但没执行用户代码，再多线程也无济于事
- 优先检查阻塞源头：
- 用
go tool trace查 “Sched” 视图里灰色（阻塞）时间段是否密集 - 用
curl '<a href="https://www.php.cn/link/286313479c3c890d2aebb38af6375722">https://www.php.cn/link/286313479c3c890d2aebb38af6375722</a>'看堆栈是否集中在read、net.Conn.Read或select上
- 用
容器环境下 runtime.GOMAXPROCS 必须与 vCPU 配额对齐
-
runtime.NumCPU()在容器内返回的是宿主机逻辑核数，不是 cgroups 限制值 - 典型错误：Docker 启动时加了
--cpus=2，但 Go 程序仍调用runtime.GOMAXPROCS(runtime.NumCPU())，结果返回 32，导致线程争抢、cache false sharing 加剧 - 正确做法：
- 启动时优先用环境变量：
GOMAXPROCS=2 ./myserver - Kubernetes 中，在 Deployment 的
env里显式设置GOMAXPROCS=2 - 若必须代码中设，改用
os.Getenv("GOMAXPROCS")解析后转为 int 再调用runtime.GOMAXPROCS(n)，避免 fallback 到NumCPU()
- 启动时优先用环境变量：
- 验证是否生效：启动后立刻打印
runtime.GOMAXPROCS(0)，并用go tool trace确认 Scheduler 视图中 P 的数量匹配
runtime.GOMAXPROCS 什么时候真该调，而不是默认就行
- 绝大多数 I/O 密集型服务（如 API 网关、日志转发）不需要调大，
runtime.GOMAXPROCS(2)甚至默认值就够用 - 真正值得调整的场景很窄，且必须可观测：
-
pprof的goroutineprofile显示大量 goroutine 长时间处于runnable状态 -
go tool trace的 Scheduler 视图中出现持续的 M 阻塞或 P 饥饿 - 单机部署多个 Go 进程，每个都默认用满所有核 → 应按进程数均分，比如 8 核跑 4 个服务，每个设
runtime.GOMAXPROCS(2) - 混合部署 Java/Go 服务，Java 用了
-XX:ParallelGCThreads锁定线程数，Go 进程需主动让出资源
-
runtime.GOMAXPROCS 的副作用常被忽略：它不只影响调度，还牵连 GC 行为（并行 mark worker 数随 P 数增加）、内存分配效率，甚至影响 cache 局部性。一旦设错，问题往往不会立刻暴露在 CPU 或 QPS 上，而是在 p99 延迟、GC STW 时间或内存抖动中缓慢浮现。
