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