Go语言runtime调度器中，全局队列与本地队列有何具体差异？

本文共计1054个文字，预计阅读时间需要5分钟。

本地队列为每个进程独立的、无锁的FIFO队列，操作不涉及任何同步开销。只要本地队列非空，从队列中pop一个元素执行，整个流程在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 负载分布是否均匀。