本地队列优先被使用，因其是每个P独有、无锁的FIFO队列，存取零同步开销且缓存友好；满256时触发半队列迁移至全局队列以实现负载均衡；全局队列仅在本地空、窃取失败、系统调用返回或GC后等特定路径下才被访问。
本地队列（P.runq）为什么优先被使用？
因为本地队列是每个 P 独有的、无锁的 FIFO 队列，存取操作不涉及任何同步开销。只要 P 本地队列非空，M 就直接从中 pop 一个 G 执行，整个过程在 CPU cache 内完成，延迟极低。
常见错误现象：有人误以为“全局队列更权威”，于是手动绕过本地调度逻辑，结果反而引入锁竞争和 cache line bouncing，吞吐反而下降。
-
P.runq容量上限为 256 个G，超出后会触发“半队列迁移”——把其中一半移到全局队列 - 新建
G（如go f()）默认先入当前P的本地队列，不是全局队列 - 本地队列中
G的栈内存、调度上下文大概率驻留在该P绑定的 CPU core 的 L1/L2 cache 中，减少内存访问延迟
全局队列（globalRunq）加锁但不可替代
全局队列是所有 P 共享的、带互斥锁的队列，它不是“备用通道”，而是调度器实现公平性与初始化语义的关键枢纽。
典型使用场景包括：
- 新
G创建时，若当前P不存在（比如在系统调用返回路径中创建），只能进全局队列 -
G从阻塞态（如网络 I/O、定时器、channel recv）唤醒后，若原P已被其他M占用或处于休眠，该G会被放入全局队列等待重新绑定 - 当某个
P本地队列为空，且无法成功窃取（work stealing）其他P的任务时，才退而求其次从全局队列批量取（通常一次取 32 个）
注意：globalRunq 上的锁（runqlock）是自旋锁 + 普通 mutex 的混合实现，争抢激烈时会短暂阻塞，但设计上已尽量压缩临界区长度。
本地队列满时会发生什么？
这不是异常，而是常态下的主动负载均衡机制。一旦 P.runq 达到 256，下一次新 G 进来时，runtime 会先将本地队列前 128 个 G 批量迁移到 globalRunq，再把新 G 塞进本地队列尾部。
这个行为容易被误解为“性能劣化信号”，其实恰恰相反：
- 避免单个
P队列无限膨胀，导致其他P饥饿 - 让全局队列始终保有新鲜任务，提升 work stealing 的成功率
- 迁移是批量原子操作，比逐个 push 到全局队列更高效
你可以用 go tool trace 观察 Proc/RunQueue 和 Global/RunQueue 的长度波动，正常服务中二者应呈弱相关震荡，而非单边持续增长。
什么时候会从全局队列取任务？
只有三种明确路径会触达 globalRunq 的 pop 操作：
-
findrunnable()函数中，当前P本地队列为空，且所有其他P的本地队列都窃取失败后，才尝试从globalRunq取一批（globrunqget） - 系统调用返回时，若
M找不到空闲P，则把刚唤醒的G放入globalRunq，由其他M后续消费 - GC stw 阶段结束后，部分被暂停的
G会统一注入globalRunq，避免集中唤醒压垮单个P
别指望靠增大 GOMAXPROCS 来“减少全局队列使用”——它只控制 P 数量，不影响队列选择逻辑。真正影响全局队列压力的是 goroutine 创建节奏、阻塞比例与 P 负载分布是否均匀。
