GOMAXPROCS(n) 仅限制可运行 goroutine 的 P 数量，不提升并发上限或解决 I/O 阻塞；需配合超时控制、非阻塞接口、pprof/trace 分析及 sync.Pool 优化调度性能。
为什么 runtime.GOMAXPROCS(n) 设置后没效果
很多开发者调用 runtime.GOMAXPROCS(8) 后发现 goroutine 并发数没明显提升，甚至卡在 I/O 或锁竞争上。这不是调度器失效，而是 GOMAXPROCS 只控制 **OS 线程（M）可绑定的 P 数量**，不等于并发 goroutine 上限，也不解决阻塞问题。
- 若程序大量使用
time.Sleep、net.Conn.Read或未用context.WithTimeout的 HTTP 调用，goroutine 会持续挂起，P 被占着但不干活 - 设置大于 CPU 核心数的值（如
runtime.GOMAXPROCS(100)）在无 I/O 密集场景下反而增加调度开销 - Go 1.5+ 默认已设为
NumCPU()，手动覆盖前先用pprof确认是否真受 P 数限制：go tool pprof http://localhost:6060/debug/pprof/goroutine?debug=2
阻塞系统调用导致 M 被抢占怎么办
当 goroutine 执行 read/write、accept 等阻塞系统调用时，运行它的 M 会脱离 P 进入系统调用状态。若该 M 长时间阻塞（如慢 DNS 查询），P 就空转，其他 goroutine 挨饿。
- 优先用 Go 标准库封装的非阻塞接口：如
net/http.Client自动使用epoll/kqueue，但需配Timeout和KeepAlive - 避免直接调用
syscall.Read等裸系统调用；必须用时，加runtime.LockOSThread()前先评估是否真需独占线程 - 对无法避免的阻塞操作（如某些 Cgo 调用），用
runtime.UnlockOSThread()让出线程，并确保 goroutine 不长期持有锁或全局资源
如何识别 goroutine 泄漏和调度瓶颈
goroutine 数持续增长、runtime.ReadMemStats 显示 MCacheInuse 异常高、或 pprof 中 goroutine profile 出现大量相同栈帧，都是泄漏信号。调度瓶颈则常表现为 scheduler profile 里 findrunnable 占比过高。
- 启动时启用调试端点：
import _ "net/http/pprof" go func() { log.Println(http.ListenAndServe("localhost:6060", nil)) }() - 检查 goroutine 堆栈：
curl 'http://localhost:6060/debug/pprof/goroutine?debug=2' | grep -A 5 'YourHandlerName'
- 用
go tool trace分析真实调度延迟：go run -trace=trace.out main.go go tool trace trace.out
关注 “Goroutines” 视图中灰色（阻塞）和红色（GC STW）时间段
sync.Pool 和 channel 缓冲区对调度的影响被低估了
频繁创建临时对象（如 []byte、strings.Builder）会推高 GC 压力，间接拖慢调度器——因为 GC STW 期间所有 P 停摆。而 channel 无缓冲或缓冲过小，会导致 goroutine 频繁休眠/唤醒，放大调度切换成本。
立即学习“go语言免费学习笔记（深入）”；
-
sync.Pool对象复用要配合理解生命周期：池中对象不能含跨 goroutine 引用，且需在Get后重置字段（如b = b[:0]） - channel 缓冲区不是越大越好：写端突发流量大时，
ch := make(chan int, 1000)可减少阻塞，但若读端处理慢，内存堆积反而触发 GC；建议按平均处理延迟 × 吞吐预估，再加 20% 余量 - 替代方案更轻量：I/O 流水线中，用
for range+selectdefault 分支做非阻塞尝试，比满缓冲 channel 更可控
time.Sleep 死等——这些地方根本不会出现在调度器统计里，但会让 goroutine 在等待中虚耗 P。 
