抹茶柚子冰在Go社区里聊调度器，几乎所有人都能说出“GMP模型”这么几个词，但真正吃透工作窃取调度器的人其实不多。我之所以花了很大精力去研究这块，是因为前阵子接手了一个计算密集型的图像处理项目——每帧图像都要做大量像素级运算，理论上8核机器应该跑得飞快，结果用pprof一抓，CPU利用率始终在四五个核之间徘徊，Goroutine倒是开了几百个，但真正在执行计算的没几个。排查到最后，问题不是出在业务代码上，而是出在我对调度器工作机制的理解上，尤其是一堆纯计算任务在多个P之间到底怎么均衡、什么时候触发偷取、偷多偷少有什么讲究，这些细节直接决定了程序能不能把机器跑到“满血”。
这篇文章就从一个真实的计算密集型场景出发，深入拆解Go语言工作窃取调度器的负载均衡策略。内容会覆盖调度器的设计思路、工作窃取的具体触发机制、可复现的实验方法，以及我在实际踩坑中总结出来的排查技巧。适合刚接触Go并发的开发者，也适合写了几年Go但一直没把调度机制弄明白的同行。如果你准备在学习路线里深入并发行列，这篇内容可以作为很好的落脚点。
1. 计算密集型任务为什么对调度器要求更高
1.1 计算密集与IO密集的根本差异
计算密集型任务，简单说就是那种“一刻不停地在算”的任务。它大多数时间消耗在CPU的算术逻辑单元上，几乎没有系统调用、没有磁盘读写、没有网络等待，更不会莫名其妙地阻塞住等某个事件发生。这种任务的特性决定了它的并行度极限就是物理核心数，再往上增加任务数量并不会带来线性收益，反而会因为切换开销和缓存竞争产生损耗。
IO密集型任务就不一样了。网络请求、文件读写这类操作耗时大头在等待内核处理，CPU大部分时间处于空闲状态，这时候调度器哪怕频繁切换Goroutine也没关系，切换成本相对于IO等待时间来说微乎其微，甚至可以说“切得越快，吞吐越高”。
这两类任务对调度器的诉求完全不同。IO密集型任务要求调度器能快速响应阻塞、快速在阻塞和非阻塞状态之间切换G，这个Go做得已经很成熟了。而计算密集型任务考验的是调度器在多个逻辑处理器之间进行工作分派的“精细度”——谁清闲了，能不能立刻拿到新任务；谁忙碌了，新任务要不要硬塞给它。这句描述看简单，落地到代码和运行机制里，就是工作窃取调度器存在的核心理由。
1.2 为什么简单的轮询分发不足以支撑高并行计算
很多刚接触并发的同学会想：任务分发还不简单吗？把N个任务平均分给N个核，每个核干自己那份，跑完等齐不就行了。这个想法在“每个任务耗时完全一致，且运行期间不产生任何其他调度行为”的理想条件下成立，但真实场景几乎不会这么完美。
最容易打破均衡的就是任务拆分粒度不均。比如把一个大数组分给8个Goroutine去统计素数个数，你的分法如果是简单的start = idx * chunk式的连续切分，数字大的区间明显要算更久，因为素数判断的循环次数和数值大小直接相关。于是低编号的Goroutine早早跑完，高编号的还在埋头苦干，最终整体耗时取决于最慢的那个任务。
这时候如果没有工作窃取机制，会出现什么情况？某个P上的Goroutine都执行完了，本地队列空了，但这个P不知道去哪里找活干，只能眼睁睁看着别的P屁股后面排着长队。整个系统的资源利用率就这么被白白浪费掉一部分。典型的“旱的旱死，涝的涝死”。
1.3 工作窃取：忙者无事找事，闲者主动出力
工作窃取调度器解决这个问题的思路非常直观，与其把活硬塞给“看起来很忙”的线程，不如让“闲得发慌”的线程主动去别人那边抢活干。每个工作线程（在Go里对应P）维护自己的本地任务队列，当本地队列为空时，就随机或者按某种策略去别的P的队列里“偷”一批任务过来执行。
这跟传统的工作共享（Work Sharing）正好相反。工作共享是当某个队列负载过高时，主动把任务分发出去；工作窃取则是任务负载不高的一方主动出击。这种模式的好处在于，队列操作大部分时间只发生在线程本地，避免了高并发锁竞争，只有在线程真正“饿”了才产生跨线程操作，而这恰恰是最该发生跨线程操作的时候。
Go语言就是这套机制非常优秀的实现案例。接下来要深入看的就是它在GMP模型中的具体呈现方式。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 工作窃取调度器的核心设计：GMP模型中的负载均衡机制
2.1 G、M、P三者关系与P的数量设定
要理解工作窃取，先要把GMP模型理清楚。G是一个Goroutine，代表一个用