全局队列（sched.runq）不参与work-stealing负载均衡，仅作为防饿死的被动兜底通道；它加锁、单次取1个G、每61次调度tick才检查一次，设计上排除在窃取路径外。
全局队列（sched.runq）不是用来“平衡负载”的，它压根不参与主动负载均衡；所谓“平衡”，只是防止新 goroutine 饿死的被动兜底机制。
为什么全局队列从不主动参与 work-stealing？
work-stealing 只发生在 P 之间，偷的是其他 P 的 pp.runq（本地队列），不是 sched.runq。全局队列加锁、缓存不友好，设计上就排除在 stealing 路径外。
- 所有 P 共享同一把
runqlock，高并发 push/pop 会引发严重锁争用 - 本地队列迁移是批量操作（一次搬 128 个 G），而全局队列 pop 是单次取一个，效率差一个数量级
- 调度器明确区分语义：本地队列 = 快速执行路径，全局队列 = 初始化/兜底/唤醒后暂存路径
pp.schedtick % 61 == 0 这个检查到底有多稀疏？
每 61 次调度 tick 才查一次全局队列，实际频率取决于当前 P 的调度节奏——在 CPU 密集型场景下可能几毫秒一次，在 I/O 等待多的场景下可能几十毫秒才触发一次。
- 这个魔数是实测权衡结果：设为 30 会导致锁竞争明显上升；设为 127 则新 goroutine 在单核下可能卡住超 100ms
- 注意：该检查只发生在
findRunnable()中且本地队列为空时，不是定时器轮询 - 它不保证“公平”，只保证“不死”——哪怕只剩一个 P，只要 tick 计数撞上 61 的倍数，就会捞一个 G 出来
什么时候你会看到 sched.runq.len 持续上涨？
不是因为“调度器没干活”，而是因为 P 数量严重不足或存在阻塞瓶颈。典型信号包括：
-
GODEBUG=schedtrace=1000输出中gqueue字段长期 >100 且不回落 -
runtime.GC()后大量 goroutine 启动延迟明显变长（GC 期间所有新 G 全进sched.runq，恢复后靠 1/61 慢慢捞） - 单核或
GOMAXPROCS=1场景下，高频创建 goroutine（如循环go f()）后响应卡顿
真正需要警惕的不是全局队列有数据，而是它成了“唯一出口”——说明本地队列始终无法被消费，或者根本没有足够 P 来分摊。
