runtime.schedule占比超25%是调度器过载的直接信号：活跃goroutine超numcpu×100导致跨p窃取频繁、cache失效、findrunnable成热点，此时应查/debug/pprof/goroutine中chan receive/semacquire堆积及worker池设计。
pprof 里 runtime.schedule 占比高就是上下文切换损耗的直接信号
不是所有 CPU 高都该优化业务逻辑——如果 runtime.schedule 或 runtime.findrunnable 在 pprof CPU profile 中占比超过 25%，而你的 handler、service 等函数占比很低，基本可以断定是调度器在“打工”，不是你在干活。
典型现象包括：
- 压测时 QPS 上不去，P99 延迟却陡升
-
/debug/pprof/goroutine?debug=2返回大量chan receive、semacquire、netpoll状态 -
runtime.NumGoroutine()持续 >runtime.NumCPU() * 100
用 vmstat 和 go tool trace 定位是否真由 goroutine 泛滥触发
vmstat 1 看 cs（context switch）列：若每秒数万次且与 goroutine 增长曲线同步，说明 OS 层已受波及；但这只是辅助证据。真正关键的是 Go 自身调度行为。
go tool trace 能暴露更底层的调度毛刺：
- 启动 trace：
trace.Start(f)+defer trace.Stop() - 打开
go tool trace trace.out→ 点 “Goroutines” → 查看是否存在大量 G 处于 “Runnable” 但长期未被 M 执行 - 点 “Scheduler” 标签，观察 P 的空转（idle）和跨 P steal 频次：steal 太多意味着本地队列常为空，P 间 cache line 失效严重
别只看 goroutine 数量，重点查 channel 使用方式
goroutine 泛滥往往不是写错了 go f()，而是 channel 设计不当把调度压力全甩给了 runtime：
- 无缓冲
chan Task是隐式同步点，每次 send/receive 都可能触发调度抢占 - 缓冲区设太小（如
make(chan Task, 1)）等同于无缓冲，流量毛刺一来就堵死 - 缓冲区设太大（如
10000+）不缓解下游慢的问题，只把积压从调度队列转移到内存，还吃 GC 压力 - worker 内部没用
select { case t := 做非阻塞批量取数，导致单次处理卡住就拖垮整个 worker
GOMAXPROCS 不对齐容器 CPU 限制是静默杀手
宿主机有 16 核，Docker 只给了 --cpus=2，但 Go 默认 GOMAXPROCS=16，结果是 16 个 P 争抢 2 个 M —— 这不是并发高，是调度瘫痪。
必须做两件事：
- 容器启动时显式设置环境变量：
GOMAXPROCS=2 - 或代码中尽早调用：
runtime.GOMAXPROCS(runtime.NumCPU())（注意：该值需读取cgroups的cpu.cfs_quota_us/cpu.cfs_period_us才准，不能硬写死）
这个错配不会报错，但 pprof 里 runtime.schedule 占比会稳定在 30%+，且无论怎么优化 handler 都无效——它根本不是你的代码问题。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
