全局队列是共享FIFO中转站，仅被动接收新创建、本地队列溢出、系统调用返回及GC发现的Goroutine；负载均衡靠P空闲时主动拉取+工作窃取实现，而非全局队列调度。
Go 的全局队列（global run queue）本身不主动参与负载平衡，它只是个“中转站”和“兜底池”，真正起负载平衡作用的是工作窃取（Work Stealing）机制——而这个机制主要发生在 P 的本地队列之间，不是靠全局队列调度出来的。
全局队列在调度中实际扮演什么角色
全局队列是所有 P 共享的 FIFO 队列，由调度器（runtime.scheduler）维护。它的核心用途不是分发任务，而是：
- 新创建的 goroutine（比如
go f()）默认先入全局队列，再由空闲 P “顺手”捞走 - 当某个 P 的本地队列满（长度达 256），新来的 goroutine 会被塞进全局队列
- 系统调用返回后未立即绑定到 P 的 goroutine，也会暂存到全局队列
- GC 扫描或 sysmon 发现的可运行 goroutine，也常投递至此
注意：global run queue 没有锁竞争优化（用的是 lock + atomic 协作），吞吐低、延迟高，所以调度器会尽量避免频繁访问它。
为什么不能靠全局队列做负载均衡
全局队列不具备感知各 P 负载的能力，也不做任何“智能分发”。它只是被动接收和顺序出队。真正的负载均衡发生在以下两个环节：
- 当一个 P 的本地队列为空时，它会先尝试从
global run queue取一个 goroutine（一次只取 1 个） - 如果仍为空，才启动 Work Stealing：随机选一个其他 P，从其本地队列尾部“偷”一半（
len/2向下取整）goroutine
也就是说，负载再不均，全局队列也不会“推”任务过去；只有 P 主动来“拉”，且拉不到时，才去偷。这种“拉式+窃取”的组合，才是 Go 实现低开销负载均衡的关键设计。
全局队列对性能的实际影响
过度依赖全局队列会显著拖慢调度效率，常见于以下场景：
- 大量 goroutine 在同一时刻集中创建（如 burst 流量），全部涌入
global run queue，造成争抢和排队延迟 - P 数量远小于 goroutine 数量（如
GOMAXPROCS=1），本地队列很快溢出，被迫频繁走全局队列路径 - 大量 goroutine 频繁进出系统调用（如短连接 HTTP Server），反复挂起/唤醒，大量经由全局队列中转
此时你会观察到 runtime.sched.nmspinning 偏低、runtime.sched.npidle 偏高，以及 Goroutines 状态中 runnable 数长期堆积 —— 这些都是全局队列成为瓶颈的信号。
真正需要关注的，从来不是怎么“优化全局队列”，而是让 goroutine 尽可能留在本地队列里被快速消费；Work Stealing 是自动触发的，但前提是你的 workload 分布和 P 数设置得当 —— 比如避免在 GOMAXPROCS=1 下跑高并发服务，就是最常被忽略的一点。
