Go 语言中 runtime 全局运行队列的平衡与负载均衡
一款功能相当强大的录音及音频编辑软件，不仅可以编辑音频，而且还可以录音，功能丰富，操作简单，使用方便，实用性强，并且占用电脑内存小，运行速度快，不卡顿电脑，使电脑系统保持良好的运行状态。支持许多格式的音频文件，包括WAV、OGG、VOC、IFF、AIFF、
先说几个核心判断：全局队列在Go调度器里的角色，更像是冷启动下的备胎，而不是负载均衡的主力。真正让各个P之间保持任务均衡的，是工作窃取机制——当某个P的本地队列空了，它会按照伪随机的顺序，从其他P那里“偷”大约一半的goroutine，最多尝试四轮。这套逻辑才是系统能跑得平稳的关键。 全局运行队列（
先说几个核心判断：全局队列在Go调度器里的角色，更像是冷启动下的备胎，而不是负载均衡的主力。真正让各个P之间保持任务均衡的，是工作窃取机制——当某个P的本地队列空了，它会按照伪随机的顺序，从其他P那里“偷”大约一半的goroutine，最多尝试四轮。这套逻辑才是系统能跑得平稳的关键。
全局运行队列（global run queue）不是负载均衡的主力
你一定会以为，全局队列是负责把任务均匀分到各个P的容器吧？其实不是。Go调度器压根儿就没指望靠global run queue来干这件事——它只负责两件事：冷启动和兜底。新创建的goroutine确实默认进了全局队列，但调度器真的是“优先”从本地队列拿任务；只有当本地队列空了、而且从一个P那里也偷不到任务时，才会绕回来看看全局队列。
这意味着什么呢？全局队列积压≠系统负载高。更可能的情况是：本地队列调度不均衡，或者偷取机制没跑通。你如果观察到runtime.globrunqget被频繁调用，同时runtime.runqsteal失败率上升，本地队列长度方差很大——有的满、有的空，那就说明工作窃取没走通，而不是全局队列分配有问题。
- 全局队列是单生产者多消费者（SPMC）无锁队列，CAS+double-check这套标准操作都用上了，但插入/弹出还是得走原子操作，高并发下竞争开销跑不掉
- 全局队列没有优先级概念，严格FIFO。一旦一个长耗时的goroutine入队，它后面所有任务都得堵着等它跑完
- 全局队列长度不可靠：
len(globalRunq)不是导出字段，你没法直接看；通过debug.ReadGCStats或pprof看gcount时，它不告诉你哪个是全局队列来的
work-stealing 才是实际生效的负载均衡机制
真正让各P负载趋向均衡的，是工作窃取。每个P本地队列空了的时候，它会按伪随机顺序尝试从其他P的队列尾部“偷”大约一半（但不超过256个）goroutine，最多做四轮。整个过程完全在用户态完成，不涉及系统调用，也不依赖全局锁。
容易踩的坑是：runtime.runqsteal返回0，不一定意味着“没任务”，更有可能是目标P队列太短，或者刚好被别的P刚偷过。任务在runqput时有CAS更新，所以atomic.LoadUint64(&pp.runqtail)可能存在短暂的不准确，导致偷取失败。
- 偷取是尾部操作（LIFO），这点很妙——刚偷来的goroutine非常有可能复用前一个goroutine的CPU缓存行，cache locality的优势就来了
- 没有“主动推送”逻辑：P不会把本地队列溢出的任务主动推给全局队列或别的P，必须等对方来偷——所以队列设计要留足余量，否则可能饿死
为什么不能靠调大 GOMAXPROCS 来“自动均衡”
这里有个常见的认知误区：runtime.GOMAXPROCS只控制最大OS线程（M）数量，跟goroutine（G）怎么分配到P上是两码事。它既不改变全局队列分发策略，也不影响work-stealing行为。你把GOMAXPROCS设成100还是设成4，只要P数不变（默认=GOMAXPROCS），本地队列+偷取逻辑就完全一样。
典型的反面案例就是容器环境：硬编码GOMAXPROCS(64)，但实际只给了2核CPU。结果大量M被OS调度器频繁切换，延迟抖动反而更严重。
- P的数量决定了本地队列的数量，这才是负载粒度的关键。P太少→单队列积压严重；P太多→偷取开销占比上升，空闲P白白占着内存
- 真正的瓶颈往往不在调度器，而在goroutine本身。CPU密集型任务堵住整个P的本地队列，I/O型goroutine只能在旁边干等——这跟调度算法没关系，是任务类型混杂导致的
- sync.Pool与负载均衡完全无关——它只缓存对象，不参与任务分发或排队
想干预负载分布？得绕过 runtime 自己管队列
Go运行时不暴露本地队列或偷取接口，runtime.runqget、runtime.runqput这些函数都是unexported的。假如你确实需要细粒度控制（比如按请求耗时加权分发、隔离I/O与CPU任务），就别想着靠运行时环境了。唯一的出路是：不用go f()直接启动任务，而是自己实现worker pool+任务channel+权重更新逻辑。
关键难点不在算法，而在如何避免锁争用和虚假唤醒。举个例子：
- 别用共享无界的
chan interface{}：写入竞争激烈，len(chan)不反映真实积压情况，而且GC还会扫描所有pending元素 - 推荐用
sync.Pool+[]*task模拟双端队列。偷取时用atomic.LoadUint64检查长度，再用sync.Mutex移动尾部1–2个任务 - 权重更新必须基于运行时反馈：比如最近10秒的平均延迟，而不是只看静态的CPU核数；更新频率建议500ms，太快容易抖动，太慢跟不上突发
最容易被忽略的一点：work-stealing是尽力而为的机制，不是强保障。它不保证“绝对公平”，只是降低长尾出现的概率。如果你需要确定性调度，那就得放弃goroutine抽象，直接管理线程和任务的绑定关系。