GOMAXPROCS设过高会因OS线程（M）数量激增导致频繁上下文切换，显著增加调度开销；应保持默认或设为runtime.NumCPU()，并通过go tool trace观察M切换热点与Goroutine泄漏。
为什么 runtime.GOMAXPROCS 设太高反而增加线程切换开销
Go 调度器（M:N 模型）将 Goroutine（G）调度到 OS 线程（M）上运行，而 M 的数量受 GOMAXPROCS 限制（默认等于 CPU 核心数）。当设得远高于物理核心数（比如 GOMAXPROCS=100），会导致大量 M 频繁争抢内核调度器资源，OS 层面线程上下文切换激增——这不是 Go 自身的 G 切换，而是真实线程（pthread）切换，代价高且不可控。
实操建议：
- 除非明确需要绑定大量阻塞型系统调用（如旧版 CGO 场景），否则不要手动调高
GOMAXPROCS；生产环境优先保持默认或显式设为runtime.NumCPU() - 用
perf record -e sched:sched_switch或go tool trace观察实际 M 切换频率，若sched.trace中 “Proc status” 显示大量 M 处于idle或频繁runnable → running，说明 M 过载 - 注意：Go 1.14+ 对阻塞系统调用的 M 复用已优化，多数场景下无需靠堆 M 数量来“掩盖”阻塞
哪些 Goroutine 行为会触发非自愿的 M 切换
Go 调度器在特定条件下会将当前 M 与 G 解绑，并分配新 M 继续执行该 G，这类“M handoff”虽不等同于 OS 线程切换，但涉及锁、栈拷贝和调度队列操作，仍带来可观开销。典型诱因包括：
- 调用阻塞式系统调用（如
read/write在未设置O_NONBLOCK的 fd 上）——Go 会把 M 推入等待队列，唤醒时可能分配新 M - CGO 调用中发生长时间阻塞（尤其未用
runtime.LockOSThread()且未及时释放 M） - 大量使用
time.Sleep（尤其是微秒级短眠）会触发timerproc频繁唤醒，间接增加调度器压力 - Goroutine 执行中发生栈增长（
morestack），若发生在关键路径且栈分裂频繁，也会打断执行流
规避方式：对 I/O 使用 net.Conn（默认非阻塞 + epoll/kqueue）、避免在 hot path 上做小粒度 time.Sleep、用 sync.Pool 复用大对象减少栈分配压力。
立即学习“go语言免费学习笔记（深入）”；
如何用 go tool trace 定位真实线程切换热点
go tool trace 生成的交互式视图里，“Threads” 行显示 OS 线程生命周期，“Proc” 行显示 P（逻辑处理器）状态，二者错位即暗示 M 切换。重点看：
- “Threads” 行中出现密集的灰色小方块（表示 M 被 OS 调度器挂起），尤其伴随 “Proc” 行长时间空闲，说明 M 在等系统资源（如锁、磁盘 I/O）
- 搜索事件类型为
GoBlockSyscall或GoUnblock的跨度，若单次阻塞超 100μs，且频次高，就是 M 切换主因 - 导出
trace.out后用go tool trace -http=localhost:8080 trace.out，打开 “View trace” → 点击某段灰色 M 区域，看右侧 Event Log 是否含STW、GC pause或syscall相关条目
注意：runtime/trace 本身有约 5% 性能开销，仅用于诊断，勿长期开启。
避免 Goroutine 泄漏导致 M 积压的硬性检查点
Goroutine 不退出但持续等待（如 channel 未关闭、timer 未 stop、waitgroup 未 Done），会让其绑定的 M 无法回收，最终触发 runtime 创建新 M 应对新任务，形成 M 数量膨胀 → OS 调度器过载 → 线程切换飙升。
上线前必须验证：
- 所有
select语句是否含default或超时控制，防止无限阻塞 - 启动的后台 Goroutine 是否通过
context.Context可取消，且主流程中调用了ctx.Cancel() - 用
pprof.GoroutineProfile或debug.ReadGCStats定期采样，若 Goroutine 数持续 > 1000 且无业务峰值对应，大概率存在泄漏 - CGO 场景下，确保每个
C.xxx调用后都执行runtime.UnlockOSThread()（如果之前锁过）
真正难排查的不是“切太多”，而是“该停的没停”——M 和 G 的生命周期管理松耦合，一旦 Goroutine 卡住，M 就成了沉默的负担。
