为什么 GOMAXPROCS 对 IO 密集型任务几乎没影响
因为 Go 的 goroutine 调度器在遇到系统调用（比如文件读写、网络请求）时会自动让出 OS 线程，把 M（machine）交给其他 goroutine 使用，整个过程不依赖 GOMAXPROCS 设置的 P（processor）数量。IO 操作本身不消耗 CPU，调度器也不需要更多 P 来“并行执行”这些阻塞动作。
常见错误现象：GOMAXPROCS(1) 下跑大量 HTTP 请求，响应时间跟 GOMAXPROCS(8) 差不多——这不是 bug，是设计如此。
- IO 密集型任务真正瓶颈通常在网络延迟、磁盘 IOPS 或连接池大小，不是 P 数量
-
GOMAXPROCS控制的是“可并行执行的 Go 代码逻辑”的最大 P 数，不是“并发 IO 操作数” - 即使设成 1，上万个 goroutine 发 HTTP 请求也能高效运行（前提是
http.Transport配置合理）
什么时候调小 GOMAXPROCS 反而更稳
在容器环境或低配机器上，过大的 GOMAXPROCS 会导致线程创建过多、上下文切换变重，尤其当大量 goroutine 频繁进出系统调用时，OS 线程（M）可能远超 P 数，引发调度抖动。
使用场景：Kubernetes 中限制了 cpu: 100m 的 Pod，却默认继承宿主机的 GOMAXPROCS（比如 32），这时实际可用 CPU 核心远小于 P 数。
立即学习“go语言免费学习笔记（深入）”；
- 推荐做法：启动时显式设置
GOMAXPROCS为容器可分配的 CPU 核心数（如runtime.GOMAXPROCS(2)） - 可通过
os.Getenv("GOMAXPROCS")读取环境变量，但注意它只在程序启动时生效一次 - Go 1.21+ 默认会读取
cgroups限制自动设值，但老版本或非 cgroupv2 环境仍需手动干预
runtime.LockOSThread() 和 GOMAXPROCS 的冲突点
当你在 goroutine 中调用 runtime.LockOSThread()（比如调用某些 C 库要求线程绑定），而此时 P 数远小于 M 数，就可能出现多个被锁定的 goroutine 挤在同一个 OS 线程上，造成隐性串行。
错误现象：本应并发执行的数据库连接初始化（含 C.lock）变慢，pprof 显示某 OS 线程 CPU 占用 100%，其他线程空闲。
- 根本原因：被锁住的 goroutine 必须在固定 M 上运行，而该 M 只能绑定一个 P；若 P 数少，多个 locked goroutine 就会排队等同一个 P
- 临时缓解：增大
GOMAXPROCS，但治标不治本；更稳妥的是减少LockOSThread使用，或确保这类操作本身轻量且不频繁 - 检查方式：用
go tool trace查看 “Proc” 视图中 P 的利用率和 M 的阻塞状态
验证当前设置是否合理的两个命令
别靠猜，用真实指标说话。IO 密集型服务的关键观察点不是 CPU 利用率，而是 goroutine 数量变化趋势和系统调用等待时间。
- 查实时 goroutine 数：
curl http://localhost:6060/debug/pprof/goroutine?debug=1 | wc -l - 看调度延迟：
go tool trace打开后点击 “View trace” → “Goroutines” → 观察是否有大量 goroutine 长时间处于 “runnable” 状态（说明 P 不够用），但 IO 场景中更常见的是 “syscall” 状态，这属于正常 - 对比不同
GOMAXPROCS下的runtime.ReadMemStats中NumGC和PauseTotalNs，确认 GC 压力是否异常升高（P 过多有时会加剧辅助 GC 负担）
真正容易被忽略的是：IO 密集型服务的性能拐点往往出现在连接池耗尽、DNS 解析阻塞或 TLS 握手复用率低，而不是 GOMAXPROCS 设少了。先盯紧 http.Transport 和 net.Dialer 的配置，再动调度参数。
