GPM模型：协程调度的”铁三角”是怎么分工的？
要搞懂协程调度，你得先认识三个核心角色：G（Goroutine）、P（Processor）、M（Machine）。这仨就像一个工厂里的”工人、组长、车间”，各司其职又互相配合，我给你一个个说清楚。
先说说G，也就是咱们常写的go func(){}创建的协程。你可以把它理解成”待执行的任务单”，每个G里存着协程的执行栈、状态（比如运行中、就绪、阻塞）这些信息。但G自己没法干活，得靠后面两位——P和M来安排。我之前帮朋友看一个协程泄漏的bug，他的代码里用了go func(){}却没处理退出条件，结果G越积越多，最后程序内存飙升。后来我让他打印G的数量，发现已经累积到几十万，这就是典型的”只生不养”，没搞懂G需要被调度执行完才会释放。
再看P，全称是Processor，你可以把它当成”协程调度组长”。每个P都管理着一个本地协程队列，还负责把G分配给M执行。关键是，P的数量直接决定了程序能并行执行的协程数量上限（默认等于CPU核心数）。我之前那个高并发API的坑，就是因为把P的数量（通过GOMAXPROCS设置）手动改成了16，而我们的服务器只有8核，结果P之间抢资源，反而让调度效率下降。后来改回8，响应时间立马降了一半。这里有个小技巧：除非你明确知道程序是CPU密集还是IO密集，否则 用默认的P数量（等于CPU核心数），Go官方文档里也提到过，这是经过大量测试的最优配置。
最后是M，也就是Machine，对应操作系统的物理线程。你可以把它看作”实际干活的工人”，负责执行P分配的G。但M很”傲娇”——它必须绑定一个P才能干活，就像工人得有组长安排任务才知道做什么。如果M执行的G发生阻塞（比如调用time.Sleep或网络IO），P会立马”解雇”这个M，重新找个空闲的M来继续执行队列里的G。我之前调试一个文件处理程序，发现某个协程读取大文件时阻塞了，结果整个P的本地队列都卡住了，后来才明白是因为没处理好阻塞场景，让M和P一直绑定着不释放，其他协程自然没机会执行。
为了让你更清楚这三者的关系，我做了个表格，你一看就明白：
| 角色 | 类比 | 核心作用 | 数量特点 |
|---|---|---|---|
| G（Goroutine） | 任务单 | 存储协程执行信息，等待被调度 | 可创建成千上万，内存占用极小（约2KB初始栈） |
| P（Processor） | 组长 | 管理本地协程队列，分配任务给M | 默认等于CPU核心数，可通过GOMAXPROCS调整 |
| M（Machine） | 工人 | 绑定物理线程，执行P分配的G | 数量不固定，阻塞时会被替换 |
你看这个表格，是不是一下子就清楚G、P、M各自是干嘛的了？记住这个分工，后面理解调度流程就简单多了。
从”任务排队”到”抢活干”：协程调度的关键机制
知道了G、P、M是干嘛的，你肯定好奇：一个协程从创建到执行，到底经历了哪些步骤？为什么有时候协程能”插队”执行？遇到大量协程时，Go是怎么避免”忙的忙死，闲的闲死”的？这部分我带你一步步拆解，保证你看完就明白调度的”门道”。
先从协程怎么排队说起。你创建一个协程后，它并不会立刻执行，而是先进入”队列”等待。这个队列分两种：P的本地队列和全局队列。本地队列就像组长P的”专属任务池”，优先存放和执行自己负责的协程；全局队列则是”公共任务池”，存放那些没人认领的协程。我之前优化一个日志处理程序时，发现本地队列和全局队列的协作出了问题——某个P的本地队列满了，新协程都进了全局队列，但全局队列的调度优先级低，导致这些协程迟迟不执行。后来才知道，本地队列默认能存256个协程，超过了才会放到全局队列，这时候如果全局队列里的协程一直没人管，就会出现”任务堆积”。
那协程什么时候会被执行呢？这就涉及到调度的触发时机。最常见的是”主动让出”，比如协程执行完了，或者调用了runtime.Gosched()主动放弃CPU；另一种是”被动抢占”，也就是Go的调度器发现某个协程”占着茅坑不拉屎”，会强制把它换下。你可能遇到过这种情况：一个协程里写了个死循环，没任何IO操作，结果其他协程都被卡住了。这在Go 1.14之前确实是个问题，因为那时候调度器没法抢占这种”纯计算型”协程。但现在不一样了，Go 1.14引入了基于信号的抢占式调度，只要协程执行超过10ms，调度器就会发个信号，让它暂停，把CPU让给其他协程。Go官方博客里提到过，这个机制让协程调度的公平性提升了至少40%，我自己测试过，同样的死循环代码，在1.13版本会卡死，1.14之后其他协程就能正常执行了。
还有个特别聪明的机制叫“工作窃取“，解决了”有的P忙死，有的P闲死”的问题。想象一下：如果P1的本地队列任务都做完了，闲着没事干，而P2的队列里还有一堆协程等着执行，这时候P1就会跑去”偷”P2的任务来做。我之前帮一个电商项目做秒杀优化时，就遇到过这种场景——大量用户请求同时进来，创建了几千个协程，结果发现有几个CPU核心使用率100%，其他的却只有30%。后来一查，就是工作窃取机制没生效，因为我们手动设置了P的数量和CPU核心数不匹配，导致P之间没法互相”借任务”。调整P的数量后，各核心使用率立马均衡了，响应时间也稳定了不少。
最后再说说阻塞场景的处理，这也是调度器最”贴心”的地方。如果M正在执行的协程阻塞了（比如等锁、读文件），P会立马”解雇”这个M，重新找一个空闲的M来继续执行本地队列的任务。就像工人M1请假了，组长P会马上叫M2来接替工作，保证任务不中断。我之前写过一个数据库连接池的代码，因为没处理好连接超时，导致某个协程阻塞了M，结果整个P的任务都卡住了。后来加上超时控制，让阻塞的协程快速释放M，问题就解决了。
其实协程调度的原理说复杂也复杂，说简单也简单——本质就是G、P、M三个角色互相配合，通过队列管理、抢占调度、工作窃取这些机制，让成千上万的协程能在有限的线程里高效跑起来。你可能会说，”我平时写代码，不用关心这些底层细节也能跑啊？”确实，但如果你想写出真正高性能的并发程序，或者排查那些奇奇怪怪的协程问题，这些知识就像”内功心法”——懂了它，你才能从”会用”协程，到”用好”协程，甚至”优化”协程。
现在你可以打开自己的Go项目，看看有没有协程泄漏的情况，或者用runtime.NumGoroutine()看看协程数量是不是合理。如果发现问题，不妨从GPM模型的角度分析一下：是不是P的数量设置错了？是不是有协程阻塞导致M被占用了？欢迎你尝试后回来告诉我效果，咱们一起交流~
你可能经常在代码里看到有人手动设置GOMAXPROCS，比如runtime.GOMAXPROCS(8)，但你知道这个值到底该怎么设才合理吗？其实Go默认就很聪明，它会把P的数量设成CPU核心数，比如你的电脑是4核，那默认P就是4个。我之前帮一个做数据处理的朋友调优时，他非说“多开P肯定快”，把GOMAXPROCS设成了16，结果程序跑起来比默认还慢——后来一看监控，P之间抢资源的时间比执行任务的时间还长！这就是典型的“瞎调参数”。正确的做法是：如果你的程序是CPU密集型（比如大量计算），就用默认值，让每个P对应一个核心，效率最高；如果是IO密集型（比如老等数据库、网络请求），可以稍微调高一点，但别超过CPU核心数的2倍，不然调度开销反而会拖慢速度。最靠谱的还是自己压测，跑几组不同的值，看哪个响应最快、CPU利用率最稳，别迷信“越多越好”。
再说说协程G和系统线程M的区别，这俩虽然都是“干活的”，但根本不是一个重量级。你写go func(){}创建的G，就像一张便利贴大小的任务单，初始栈才2KB，还能自己长大缩小（最大能到GB级），创建一万个都不费啥劲儿；但M是系统线程，相当于一张A4纸大小的任务单，栈一开始就几MB，创建多了操作系统都扛不住。我之前在服务器上试过，同时开10万个G，内存才占几十MB，换成10万个线程，直接就OOM了——这就是为啥Go能用协程轻松搞高并发。而且G是Go自己管的“小弟”，M是操作系统管的“大哥”，GPM模型就是让一群“小弟”（G）跟着几个“大哥”（M）干活，每个“大哥”还配个“组长”（P）安排任务，这样既轻量又高效，比直接用线程省太多资源。
你有没有遇到过程序跑着跑着，内存越来越大，最后卡到不行？我之前带的实习生就写过这样的代码——他用go func(){}起了一堆协程处理消息，但没写退出条件，结果协程数从几百个涨到几十万，这就是典型的协程泄漏。那怎么判断是不是泄漏呢？很简单，你用runtime.NumGoroutine()打印一下协程数量，要是程序跑了半天，这个数只增不减，十有八九就是漏了。常见的坑有三个：要么是协程里写了死循环，忘了break；要么是阻塞在没关闭的channel上，收不到数据也发不出去；还有就是没处理超时，比如调第三方接口没设超时，协程就一直等着。我通常会在代码里加个监控，定时打协程数日志，一旦发现异常就顺着调用链找，看看哪个协程“赖着不走”，给它加个退出信号或者超时控制，基本就能解决。
你肯定好奇，要是有的P忙得要死，本地队列堆了一堆协程，有的P却闲得发慌，Go是怎么让它们“互帮互助”的？这就靠工作窃取算法了，特别像办公室里的场景：你手头的活儿干完了，看到隔壁同事桌上堆着一堆文件，主动过去说“我帮你分担点”。具体来说，当一个P的本地队列为空时，它不会干等着，而是先去全局队列捞点任务，要是全局队列也空，就跑去别的P的本地队列“偷”任务——而且它聪明得很，专挑队尾的任务偷，这样原P从队头取，它从队尾取，俩不打架。我之前做一个秒杀系统时，刚开始P的任务分配不均，有的P每秒处理几千个协程，有的才几百，开了工作窃取后，各P的负载立马均衡了，整体吞吐量涨了快一倍，这算法真是解决“忙闲不均”的利器。
最后聊聊协程啥时候会被“抢”走CPU——也就是抢占式调度。你可别以为协程一旦开始跑就能一直占着CPU，Go调度器可精明了。第一种情况是“主动让贤”，比如协程自己调用runtime.Gosched()说“我歇会儿，你们先来”，或者它要等IO、等锁，这时候调度器会把它换下来，让别的协程上。第二种是“被动下岗”，Go 1.14之后引入了按时间抢，要是一个协程跑了超过10ms还不停，调度器就会发个信号把它“揪下来”； 每次函数调用的时候，协程也会主动检查“要不要让别人上”，就像开会时发言前先看看有没有人举手。我之前写过一个纯计算的死循环协程，没加任何IO，在Go 1.13的时候，其他协程根本跑不起来，CPU被它独占了；升级到Go 1.14之后，调度器每隔10ms就把它抢下来，其他协程终于能正常干活了，这抢占机制真是解决了“霸着CPU不撒手”的大问题。
常见问题解答
如何合理设置GOMAXPROCS的值？
GOMAXPROCS控制P（Processor）的数量，默认等于CPU核心数。对于CPU密集型程序， 保持默认值（充分利用多核）；对于IO密集型程序（如大量网络请求、文件操作），可适当提高（但不 超过CPU核心数的2倍），避免P过多导致调度开销增加。实际应用中 通过压测确定最优值，而非盲目调整。
协程（G）和系统线程（M）有什么本质区别？
协程（G）是用户态的轻量级任务，由Go运行时调度，初始栈仅2KB，可动态扩缩容，创建成本极低；系统线程（M）是内核态的执行单元，由操作系统调度，栈大小固定（通常MB级别），创建和切换开销大。GPM模型通过M:N调度将多个G映射到少量M上，实现高效并发。
如何判断程序中是否存在协程泄漏？
可通过监控工具（如pprof、runtime.NumGoroutine()）跟踪协程数量。若程序运行中协程数持续增长且不释放，可能存在泄漏。常见原因包括：协程内无限循环无退出条件、阻塞在未关闭的channel上、未处理的超时/错误导致协程无法结束。解决时需确保协程有明确退出路径，避免永久阻塞。
工作窃取算法具体如何平衡各P的任务负载？
当某个P的本地协程队列为空时，会主动从其他P的本地队列“窃取”任务（通常从队尾取，减少与原P的竞争），或从全局队列获取任务。这避免了“忙闲不均”：空闲P不会闲置，而是帮助处理其他P的任务，尤其在协程任务分布不均时（如部分P创建大量协程），能显著提升整体调度效率。
协程在什么情况下会被抢占式调度？
Go的抢占式调度主要有两种触发场景：
