全局队列与本地队列区别详解

Go调度器通过本地队列（每个P独有、无锁、缓存友好）与全局队列（共享、带锁、保障公平性）的协同设计，实现了高性能与负载均衡的统一：本地队列优先被使用以消除同步开销、降低延迟，仅在队列满（触发半迁移）、本地空且窃取失败、系统调用返回或GC恢复等关键路径下才动用全局队列；误解其角色（如绕过本地队列直投全局）反而引发锁竞争和缓存颠簸，严重损害吞吐——理解这一精巧分层机制，是写出高效Go并发程序的关键前提。

本地队列（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 负载分布是否均匀。

今天关于《全局队列与本地队列区别详解》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！