在Go语言的学习中，最绕不开的一块就是调度器。很多人知道goroutine是轻量级线程，但问起GMP三个字母到底怎么协同工作，就说不清楚了。这篇文章是我自己从源码到运行机制梳理出来的学习笔记，我把整个过程的思考和关键知识点都写下来，希望对同样在啃调度器的朋友有用。你完全可以把它当成一份自底向上的复习笔记：先从线程模型讲起，再拆解GMP三个部分，然后顺着一次goroutine诞生的完整生命周期走下去，把调度循环、工作窃取、系统调用阻塞、监控线程都看一遍，最后我会整理一些实际项目中踩过的坑。
1. 为什么要啃调度器：从线程模型说起
1.1 传统并发模型的两难
只要写过几年后台服务，大概率都会碰到线程池、锁、阻塞队列这些东西。多线程能够真正利用多核处理器的并行能力，但一个线程对应一个内核线程，创建和切换的成本都不轻。线程一多，光上下文切换就能吃掉大量CPU时间。Java里常用的线程池，其实只是把线程资源池化，能够缓解反复创建销毁的压力，但线程栈空间、内核级调度、锁竞争这些成本并不会凭空消失。
Go语言选择了另一条路：把并发单元和操作系统线程彻底解耦。你写一个go func()，创建出来的是一个只有几KB栈空间的goroutine，一个线程上可以跑成千上万个这样的任务。但这里立刻出现了一个核心问题：谁来决定goroutine什么时候运行、什么时候暂停、暂停之后又跑在哪个线程上？答案就是调度器。调度器是Go并发性能的基石，不把它讲清楚，后面遇到的很多并发问题都会停留在“玄学”层面。
1.2 线程模型的小历史
在正式进入GMP之前，先说说常见的线程模型，因为调度器本质上是在回答“用户级任务与内核线程的关系怎么处理”的问题。
- 1:1模型：一个用户线程对应一个内核线程，Java早期标准线程模型大致如此。优点是简单，内核来调度；缺点是线程切换成本高、数量受限，高并发下对线程数量非常敏感。
- N:1模型：多个用户线程跑在一个内核线程上，由用户态库自己调度。优点是轻量、切换快；缺点是一个线程阻塞，整个进程就被卡住，而且没法利用多核。
- N:M模型：多个用户线程映射到多个内核线程上，由用户态调度器来分配。兼顾了轻量和并行要求，只是调度逻辑会变得很复杂。
GMP就是Go版本的N:M模型，但它比一般的线程库更激进：goroutine的栈可以动态伸缩，上下文切换的开销被优化到近乎一次函数调用。这也是Go敢在业务代码里大量开goroutine的底气。
1.3 GMP的宏观思路
GMP不是三个冰冷字母的缩写，它代表调度器里的三个关键角色。
- G（Goroutine）：一个待执行的任务，携带栈、寄存器现场、状态等信息。
- M（Machine）：真正干活的OS线程，是内核调度层面的worker。
- P（Processor）：调度的上下文，它持有本地可运行队列，并决定当前M能执行哪一组G。
很多资料把P和CPU核心直接画等号，这不太准确。P的数量默认等于GOMAXPROCS，而GOMAXPROCS一般取CPU核心数，但P本身不是CPU，它是一个“可并行执行单位的席位”。M必须拿到P之后才能运行G，拿不到P的M只能挂起或者去全局队列等待。这样设计的直接好处是：调度动作大部分发生在P的本地队列上，不需要频繁抢一把全局锁，把竞争粒度大幅度缩小。
先记住两个约定：M不拥有G，P才拥有运行资格；G真正执行时是挂在某个M上的，但M必须持有一个P。后面所有流程都围绕这套关系展开。
2. GMP三角色拆解
2.1 G的本质与状态机
goroutine本质上是一个由runtime管理的数据结构，核心字段包括stack、sched（保存寄存器现场）、atomicstatus（状态）、goid等。它最迷人的地方是栈：初始只有2KB到8KB，当栈空间接近上限时，runtime会调用morestack检测并扩容，把老栈内容拷贝到新栈。这个机制让上百万goroutine成为现实，代价是栈拷贝时有少量停顿，所以这个操作只能在安全点执行。
G的状态机是整个调度器最容易绕晕的地方，建议把它当一张图背下来：
- _Gidle：刚分配还没初始化。
- _Grunnable：在运行队列里，等待被调度。
- _Grunning：正在某个M上执行用户代码。
- _Gsyscall：正在执行系统调用，P已经和M脱钩。
- _Gwaiting：因为channel、锁、网络等待等阻塞而挂起。
- _Gpreempted：被抢占，等待重新放入运行队列。
- _Gdead：执行结束或初始化失败。
这几种状态不是随意跳转的。比如从_Grunning切到_Gwaiting，只能发生在channel操作、锁等待、netpoll挂起等明确的阻塞点；从_Grunning切到_Gpreempted，则是由异步抢占触发的。我们在排查线上问题时，通常先看goroutine dump里的状态：如果大量停留在_Gwaiting，说明业务在等锁或等IO；如果大量_Grunnable堆积，则要考虑是不是调度吞吐不足。
2.2 M与线程的关系
M对应一个OS线程。启动阶段runtime会创建第一个M，称为主线程M0，它负责完成初始化并执行main goroutine。每个M在创建时还配了一个G0，G0专门用来跑调度代码、垃圾回收等系统逻辑，用户goroutine不能使用它。为什么要单独分一个G0？因为调度器本身也要运行在某个可保存现场的执行体上，如果用普通G来执行调度，还要考虑用户栈切换和抢占恢复的问题，逻辑容易搞乱。
M有一个非常实用的特性：它可以在执行不同G时反复切换，但M的本地缓存（内存分配器mcache）只属于当前线程。所以M一旦进入系统调用并和P脱钩，回来时必须重新绑定P，否则只能把G放进全局队列。还有LockOSThread这种操作，可以把某个G和M绑定，让后续所有调度都发生在同一条线程上，适用于CGO与需要线程局部存储的场景。不过这个操作会让P无法再调配该M，高并发业务要慎用。
2.3 P的本地队列与运行上下文
P是调度器里最像“调度器”的角色，因为它持有两个关键数据：本地可运行队列runq，以及正在运行的G指针。runq是一个容量为256的有界环形队列，队头和队尾分别用runqhead、runqtail维护。为什么是256？主要是综合了“队列不会太长”和“CAS竞争可控”两个约束。当队列满了，新来的G会被丢进全局队列，并尝试唤醒一个自旋M来帮忙。
P还有一个无锁的小队列runnext，只保存一个“下一步优先”的G。它的用途是让刚刚让出CPU的G或者新创建的G拥有更高的优先级，避免频繁去全局队列找任务。这是优化吞吐的一个小细节：在代码里连续go func()，后面的G一般会先执行，就是因为runnext的插队机制。
P本身也会经历空闲和运行两种状态。当M需要运行时，它先去寻找空闲P；如果P被sysmon标记为“长时间阻塞”，P会和M解绑并挂到空闲列表，后续由其他M接管。P这样设计，本质上是用一个固定大小的“并发槽位”去控制并行度，保证系统里同时干活的核心数量不会超出预期。
3. 调度循环的完整执行流程
3.1 从go func()到真正运行的旅程
把一个go func()拆开看，大致经历这样几个阶段：
- 调用newproc创建G：分配g结构、初始化栈、把函数入口和参数拷贝到G的栈或寄存器参数区，然后调用runqput把G放入当前P的runnext或本地队列。
- G进入_Grunnable状态，等待被调度循环抓到。
- 调度循环调用schedule()：它先从runnext、本地队列、全局队列依次找可运行的G，找不到就执行工作窃取。
- 找到后调用execute()：把G状态改为_Grunning，执行gogo把CPU寄存器现场切换过去，正式进入用户代码。
- 用户代码运行到某个阻塞点（channel、锁、sleep、IO），主动调用gopark，把自己挂到等待队列，状态转为_Gwaiting，然后调度器重新执行schedule。
- 当一个G结束（goexit）时，会回收栈资源，状态转_Gdead，M继续找下一个G。
这里我想强调第5步：Go里大部分“阻塞”都是协作式的。goroutine不会在“某个瞬间”被操作系统强行赶下CPU，而是自己在函数调用、加锁、等channel这些可预见的位置让出执行权。只有从Go 1.14开始，对于运行超过10ms的协程，sysmon才会用信号强制抢占，避免一个死循环的G把整个核心活活堵死。
3.2 调度循环中的关键函数
调度循环是整个调度器的发动机，我梳理几个最核心的函数，命名基本引自Go源码：
- schedule()：调度器主入口，负责从多级队列中找到下一个要执行的G，然后调用execute。
- execute(gp)：把当前M的curg切换成gp，并调用gogo完成现场切换。
- gogo：汇编实现，恢复寄存器现场，跳转到目标G的PC。
- gopark / goready：分别用来挂起G和唤醒G。gopark会把G状态改为_Gwaiting，并释放M去调度其他G。
- goexit：G执行完用户函数后收尾，做栈、异常、race检测等清理，然后重新进入schedule。
- runqput / runqget：本地队列的入队和出队，配合参数处理runnext和溢出到全局队列。
- findrunnable：最高频被调用的函数之一。它会依次尝试本地队列、全局队列、netpoll、工作窃取，最后睡眠。找不到可运行G时，M会把自己设为休眠状态。
理解这些函数之后，再去看pprof的goroutine profile、调度器trace，就会明白每个字段对应的是哪一段流程，排查效率会高很多。
3.3 抢占：从协作式到信号式
在Go 1.14之前，调度器的抢占基本是协作式的，依赖编译器在函数入口插入栈检查指令。如果一段代码里没有函数调用、没有栈扩容点，那它就无法被抢占。一个密集型for循环可能直接把某个P占住几十秒，其他goroutine只能排队。这也是早期Go在跑复杂计算任务时并发提升不明显的原因之一。
Go 1.14引入的异步抢占解决了这个问题。runtime的sysmon定期发送SIGURG信号给处于_Grunning状态的G所在的线程，G收到信号后会在某个安全点保存现场，标记为可抢占并让出CPU。注意“安全点”这个概念，因为栈拷贝、指针扫描等操作不能在半路随意发生，信号处理也需要找到合适的时机。所以现在的Go哪怕写一个死循环，它也不可能永远独占一个P，最多被抢占延迟几个毫秒。
不过异步抢占不是免费的。它的实现涉及信号处理、栈扫描、寄存器重写，增加了一点系统调用开销。实际项目中如果真遇到密集计算，我更建议把GOMAXPROCS调成核心数，并且善用runtime.Gosched()在业务关键循环里主动让出，减少被打断的成本。
4. 关键机制深度解析
4.1 负载调度与工作窃取的实现细节
把调度器看作“负载调度器”可能更准确：它负责把goroutine这个负载，均匀、高效地分配到每个P的队列上，再交给M去执行。工作窃取就是实现这种负载均衡的核心机制。
一个P的本地队列空了之后，它会先看一眼全局队列，然后按随机顺序去其他P的本地队列“偷”一半任务到自己的队列。这样做比所有M都抢同一个全局队列激烈程度低得多，因为大部分调度决策都发生在本地，只有本地实在找不到活时，才会去触达全局路径。
窃取是有限度的。不是每次都要偷空对方，而是只偷约一半，并且用stealRunNextG来控制是否把runnext一并偷走。源码里通过随机序号和CAS循环保证并发安全。我自己爱把它类比成食堂窗口排队：每个人优先排自己窗口，排空之后才会去别的窗口匀菜，不会硬挤，也不会一次把别人的菜全搬走。
还有一个关键点：如果系统中有空闲P（正在寻找工作但没找到，处于自旋状态），新创建G时有可能唤醒这些自旋P，让它们帮忙执行窃取，而不是任由新G长时间蹲在队列里。这保证了全局吞吐，但也让调度器稍微复杂了一点。如果你观察系统线程数和CPU核心数不匹配，不要惊讶，那很可能是自旋线程在找活干。
4.2 系统调用与网络阻塞的处理
这是GMP最巧妙的地方，也是它的“脱钩机制”。当goroutine发起一个阻塞系统调用时，比如读写文件、睡眠、获取系统锁，当前M会与P解绑，G进入_Gsyscall状态，P被让出来交给其他M使用，这样系统调用等待期间，CPU槽位不会空转。系统调用结束后，M有两种选择：如果有空闲P，就重新绑定然后继续执行原来的G；如果没有，就把G放入全局队列，自己进入休眠等待后续调度。
网络IO则走了另一条路。Go socket在非阻塞模式下，当读不到数据或写缓存满时，并不会让线程阻塞，而是把G挂到netpoll的等待队列，状态转为_Gwaiting，由epoll/kqueue来监听事件。事件就绪后，netpoll会唤醒对应的G并放入运行队列。这带来一个非常实用的结论：很多网络服务可以做到几十万连接只靠少量线程，因为大部分goroutine都挂在epoll上等待，根本不需要线程。
我曾经在压测时为了验证这一点，特意把服务里所有IO都换成同步阻塞读写，结果系统线程数直接飙到上万，吞吐反而下降明显。这可不是GMP不工作，而是我主动破坏了它的调度优势。记住：网络IO用标准库socket就别慌，它自带netpoll。
4.3 sysmon监控线程
sysmon是调度器里一个安静的“监督员”，它不依赖普通调度循环，独立运行在后台。它的工作包括：检查持续运行超过10ms的G并触发抢占；检查空闲超过一定时间的P并尝试执行netpoll；检查长时间阻塞的系统调用并释放P；处理STW（Stop-the-world）期间的调度暂停。
sysmon自身的调度间隔是动态的：初始比较密集，稳定后会维持在10ms左右。它不是必须存在才能调度，但它是保证调度器不会被单个任务卡死的关键。在源码里，sysmon逻辑有一个retake函数专门用于抢占和回收P。调试调度器问题的时候，日志里如果出现preempt相关记录，多半就是sysmon在干预。
5. 调优参数与真实踩坑记录
5.1 GOMAXPROCS与关键调试变量
GOMAXPROCS控制P的数量，默认值为CPU核心数。绝大多数情况下，默认值就是最优值。但有一个非常隐蔽的坑：在容器环境里，Go进程看到的CPU数量可能是宿主机总核心数，而不是容器cgroup限制的配额。比如容器只分配4个核，但宿主机有64核，程序默认会创建64个P，并发度远超预期，调度器反而会因为P太多而多做很多无效的队列steal操作，整体吞吐甚至下降。
社区里常用github.com/automaxprocs/automaxprocs这个库来解决容器识别问题，它会在init阶段读取cgroup配额并自动调整GOMAXPROCS。使用方式很简单，空导入即可。线上容器服务强烈建议加上，这可能是最省力的调度器调优手段。
调试调度器还可以借助GODEBUG环境变量。设置GODEBUG=schedtrace=1000，runtime会每1000毫秒打印一行调度器状态，包括每个P的运行队列长度、线程数、自旋线程数、GC阶段等。加scheddetail=1000会输出更详细的信息。团队排查调度问题的时候，这个输出比猜来猜去有用得多。
5.2 让调度器更高效的实战建议
结合我给客户做性能优化和参与开源项目的经验，几条真正有用的建议：
- 别盲目调大GOMAXPROCS。并行度超过CPU核心数并不能增加计算能力，只会增加调度开销。
- 全局锁是调度器的天敌。大量goroutine争抢同一个Mutex，会让所有等待者从_Grunning变成_Gwaiting，然后逐一唤醒，这中间有大量上下文切换。优先改用分段锁、原子操作、或者channel。
- Channel缓冲不要乱加。无缓冲channel会让收发双方严格配对，产生频繁的唤醒；有缓冲channel则能降低同步频率。但缓冲太大也可能导致内存占用和任务积压，要结合实际流量挑一个“刚好不频繁阻塞”的值。
- runtime.Gosched()要慎用。它只是把当前G让出并重新排队，不是“让出CPU给别的程序”。在密集循环里频繁调用，反而会增加调度器负担。我见过有人用它模拟yield之后，整个服务的tail latency反而变差。
- 长时间CPU密集的计算任务，建议在循环里做主动抢占点，比如定期调用runtime.Gosched()或专门设置一下死循环检查。虽然1.14后有信号抢占兜底，但主动让出能降低信号处理的额外开销。
5.3 常见问题速查表
| 现象 | 可能原因 | 建议排查方向 |
|---|---|---|
| 大量goroutine阻塞在锁上 | 全局共享锁竞争 | pprof看mutex profile，分段锁改造 |
| 容器中吞吐不稳定 | GOMAXPROCS读到宿主机全部核心 | 引入automaxprocs或手动设置 |
| 线程数异常暴涨 | 存在阻塞所有M的系统调用 | 检查文件IO、插件native代码路径 |
| goroutine泄漏但CPU不高 | 误用channel、等锁未释放 | goroutine dump看_Gwaiting数量与堆栈 |
| 单P长时间卡死 | 计算密集循环/hot spin | 确认Go版本，分析是否触发异步抢占 |
这张表我贴在了办公桌旁边。出现调度相关的告警时，先按现象定位到原因，比直接从代码里搜concurrent快很多。
6. 关于调度器，我最后想说的实际经验
我通读调度器源码的方式是“按问题驱动”，而不是按文件顺序一行行看。先给自己出几个问题：一个G为什么卡了10ms？线程数暴涨意味着什么？压测时为什么吞吐上不去？然后去runtime目录下的proc.go里找答案。这样比死磕每一行快得多，也记得牢。
有一次排查线上现象，服务在高峰期出现周期性cpu升高和延迟抖动。pprof看到大量goroutine在chan receive上等待，但channel生产者逻辑明明很快。后来发现是某段收尾逻辑每秒钟创建上万个临时channel，并且用defer close去释放。channel的创建和唤醒都要走调度器，循环次数一多，调度器自身就成了瓶颈。把代码改成复用缓冲池之后，抖动立刻消失。
如果真想深入了解GMP，我建议你下载Go源码，在proc.go里搜索runqget、schedule、findrunnable这三个函数，把它们的逻辑读通，再配合GODEBUG=schedtrace=1000实测一个高并发demo。读源码的时候不要贪快，看到不懂的字段就顺手查结构体定义。我见过很多人一上来就翻汇编，那对理解调度模型帮助不大，反而容易劝退。先跑起来，再带着现象回来看代码，才是更顺的路。
