用户甲直接开聊。写这篇东西的起因，是前阵子在帮团队排查一个莫名其妙的线上问题——服务本身负载不高，Goroutine数量却飙到几百万，CPU忽高忽低，接口P99时不时跳一下。用pprof抓了半天，最后定位到是调度器在高并发下出现了线程饥饿和局部队列堆积。当时就意识到，不少人天天写Go，却没真正搞明白Goroutine调度器是怎么工作的，出了问题只能靠猜。这篇我打算把GMP模型、调度循环、抢占式调度、网络轮询这些核心机制一层层拆开，结合我实际排查过的案例，把调度器的底裤扒干净。适合所有想把Go写稳、想搞懂高并发底层逻辑的开发者。
1. 调度器要解决的核心问题：为什么Goroutine能开这么多
1.1 从线程到Goroutine：开销账要算清楚
咱们先算一笔账。操作系统线程的创建成本，光栈空间默认就是1MB到2MB，每次创建还得走内核态，上下文切换更是出了名的贵。想象一下你开个连接就要一个线程，开100万个连接就得100万个线程，那机器基本就废了。
Goroutine之所以敢号称可以开几百万个，靠的就是三个字：用户态。Goroutine的初始栈只有2KB到4KB，而且栈可以动态伸缩，创建和销毁都在用户态完成，不碰内核。上下文切换只需要保存几个寄存器和栈指针，一条指令链就能切过去，开销比线程切换低好几个数量级。
但这里有个关键问题：Goroutine终究要跑在CPU上，而CPU只有那么多核。几百个Goroutine怎么分配到底层的几个线程上？谁来决定哪个Goroutine先跑、哪个等着？这就是调度器的活。
1.2 为什么Go不用纯内核线程调度
有人可能问：直接用系统线程调度不行吗？不行，因为内核线程调度器的设计目标是通用性，它要照顾所有进程的所有线程，用的是时间片轮转，抢占成本高，而且对Go这种大量短生命周期任务的场景完全不友好。
Go需要的是一个协作式的、面向高并发小任务的、能感知自身业务特性的调度器。这个调度器必须做到三件事：
- 能把海量Goroutine复用到少量线程上
- 能在Goroutine阻塞时快速腾出线程干别的
- 能让各个CPU核心的工作量尽量均衡
这三个目标，就是整个GMP模型设计的出发点。理解了这个出发点，后面所有机制都能顺下来。
提示：调度器是Go的“操作系统”，这个类比不夸张。你写的每个go关键字最终都会流经调度器，它的效率直接影响程序的延迟和吞吐。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. GMP模型拆解：G、M、P三个角色到底各管什么
2.1 G、M、P的定义和职责边界
GMP是Go调度器的三个核心抽象，先分别把账记清楚：
- G（Goroutine）：一个Goroutine实例。它包含栈、程序计数器、调度上下文等。它不关心自己在哪个线程上跑，它只关心自己能不能被调度。
- M（Machine）：一个操作系统线程。它负责真正执行G的代码。M拿到一个可运行的G，把它从G状态切到运行状态，跑完再送回去。
- P（Processor）：调度上下文。P持有的是一批可运行的G队列，以及一些调度相关的本地资源。P是连接G和M的“调度工厂”，它决定了哪个G能被放到哪个M上执行。
打个比方：G是你要完成的任务，M是干活的工人，P是工头的任务分配器。工头（P）手里有一沓任务清单（本地运行队列），工人（M）干活前先去工头那儿领任务。
2.2 为什么要引入P这一层
这是Go调度器和传统两级线程模型最大的区别。如果没有P，只有G和M，那G队列就是全局共享的，所有M去同一个队列里抢任务，必然需要一把全局大锁。这把锁在高并发下会成为巨大的瓶颈——所有线程都在抢同一把锁，缓存行来回颠簸，性能直接崩盘。
P的引入解决了两个问题：
- 任务本地化：每个P维护自己的本地运行队列，M只在本地队列为空时才去别的队列“偷”，极大减少了锁竞争。
- M和G的解耦：M阻塞时P可以带着队列去绑定别的M，M苏醒后再去领一个P。P的数量决定了同时有多少个G能处于运行状态，它天然成为并发度的上限。
所以你会看到，P的数量默认等于CPU核数，这是Go官方专门做的设定。P多了，并发度就高，但调度开销和内存占用也会上去。P少了，CPU喂不饱。
2.3 本地队列和全局队列的设计智慧
每个P都有一个本地运行队列，容量是256个G。如果本地队列满了，多余的G会被放到全局队列。调度循环优先跑本地队列，找不到才去看全局队列。
这里有个细节很多人不知道：全局队列的G并不是每次只取一个，而是每从全局取一批（带批量技巧），比如每次最多取32个，一半自己留着消化，一半扔进本地队列。这个设计的目的一方面减少全局锁的访问频率，另一方面能保证其他P也能分到活，防止一个P吃成胖子。
这个“优先本地 + 全局兜底”的设计，本质上是把局部性和公平性做了权衡。优