要上进的柯同学写Go一段时间的朋友，大概率都遇到过这一类怪问题：明明协程数量不多，CPU却被某个核吃满；或者某个goroutine迟迟得不到调度，仿佛被“饿”在了队列里；再或者一个不带任何函数调用的for循环，能把整个进程拖到近乎卡死。这些现象的根源，最后都会指向一个绕不开的话题——Go调度器的时间片和公平性是怎么实现的。
网上讲GMP模型的文章很多，但大多停在“G是协程、M是线程、P是处理器”的层面。至于时间片怎么分、抢占靠什么触发、为什么一个P会去偷另一个P的活、Go为什么不用操作系统那种固定时间片，这些细节反而很少被讲透。这篇就顺着调度器源码和实际运行现象，把时间片与公平性这两件事拆开聊一聊，给正在研究调度原理或者排查并发问题的同学做参考。
1. 调度器的基本盘：从GMP说起
1.1 G、M、P到底是干什么的
先花点篇幅把模型捋一下。G就是goroutine，编译之后的协程对象，里面保存栈、PC、状态、等待原因这些信息。M是操作系统线程，真正在CPU上执行代码的实体。P不是“处理器”物理核心，而是调度器为M准备的运行环境，可以理解成一个“工位”，每个工位上挂着一个本地可运行队列，同时也控制着同时并行执行任务的上限。
类比来说：M是工人，P是工位，G是待处理的活。工人必须坐在工位上才能干活，一个工位同一时刻只能坐一个工人。GOMAXPROCS设置的就是工位数，默认等于CPU核心数，也就是最多同时有多少个M在真正并行执行任务。至于剩下的M，要么在阻塞等待，要么在休眠。
P和M的关系不是绑死的。G发生系统调用阻塞时，M会带着G一起卡住，但P不会跟着浪费，它会和当前M解绑，然后唤醒或者创建一个空闲M继续从这个P的队列里取别的G运行。这种“解绑-接管”机制保证了系统调用不会把执行资源一起带进坑里，代价是M的创建和唤醒有额外开销。
1.2 一个协程从创建到运行的完整流转
当代码里写一句go func()，背后其实是调用了newproc。新创建的G不会直接“跑到”某个闲置的CPU核心上，而是先进入一个可运行队列，等待某个P把它取出来。
Go的调度队列分为两层：每个P上有一个本地可运行队列（runq），所有P共享一个全局可运行队列（schedt.runq）。新G的入队优先级是这样：优先放进当前P的runnext字段，这个字段是特设的“下一个执行”位置；如果runnext已经有东西了，原来那个G会被挤到本地队列队头；本地队列也满（默认长度256）了，才会把一半G挪到全局队列去。为什么要设runnext？核心目的是让新创建的子G尽快获得执行，同时减少从队列头部取G的开销。这玩意儿对公平性的影响后面会细说。
调度循环的入口是schedule()。它要回答一个问题：下一个跑谁？顺序大致是：
- 如果当前G被抢占且允许，先做抢占处理；
- 优先从本地队列的
runnext取一个G，再从本地队列头部取； - 本地队列空的，就去全局队列拿一批（后面会讲那套61次调度一次的权重逻辑）；
- 全局队列也空，就进入
findrunnable()，尝试从其他P偷一半任务、查网络轮询器、查定时器、最后实在没活就休眠。
这个顺序本身就是公平性的骨架。本地优先是为了缓存友好和减少锁竞争，全局队列兜底是为了防止某些协程长期靠边站，偷取机制则是为了在核数多的时候保持所有P都有事干。
1.3 队列设计为什么直接影响公平性
表面上看，调度器就是“取一个G、跑一下、再取一个”，但公平性恰恰藏在队列细节里。
本地队列是一个环形数组，通过runqhead和runqtail维护头尾，正常情况下先进先出（FIFO）。这意味着，同一P上等待的协程，谁先来谁先跑，不会出现后来者插队的情况——唯一能插队的只有runnext。
全局队列则是一个双向链表，入队加锁，出队也需要锁。它的价值在于：当一个P的本地队列清了，或者某个G主动让出时，能去全局队列捞到别的P产生的任务。没有全局队列，一个P从创建到被偷走只能留在原P的本地队列，一旦这个P长时间繁忙，其他P闲得冒烟也帮不上忙。
真正复杂的平衡逻辑在findrunnable()里：P发现本地没活时，不能立刻去偷，不然所有P都会互相偷，反而造成锁开销。于是Go引入了“spinning线程”的概念——只有处于spinning状态的M才有资格去随机偷其他P的任务，且数量会控制在P总数的一定比例内。偷的时候也不是把目标P的任务全部搬走，而是取走大约一半，让两边都有活干，避免过度迁移。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 时间片：没有固定大小，但谁也不能无限霸占
2.1 为什么Go不搞操作系统那种固定时间片
操作系统上的线程调度，典型做法是给每个线程分配一个固定时间片，比如Linux CFS会根据优先级算出虚拟运行时间，时间片一到，时钟中断触发，通过上下文切换把CPU让给别人。但Go的G并不是内核线程，G的调度发生在用户态，靠的是运行时的调度器主动找机会切换。
如果Go也做固定时间片，就必须让每个P都跑一个高频定时器，在固定间隔强制切走当前G。这个开销在“协程数量多、单个协程执行时间短”的场景下非常不划算——G本来就可能因为channel、锁、系统调用频繁让出，多数根本跑不到时间片边界就自己切换了。Go的实际策略是“够用就好”：不设固定时间片，而是用“协作式让出 + 定时抢占兜底”的组合，既照顾了低延迟，又防止了长任务饿死其他G。
2.2 协作式让出：大多数G都能自觉交回CPU
所谓协作式，就是调度器并不会强杀一个正在运行的G，而是G在特定调度点主动让出。这些调度点包括：
- channel的发送和接收可能阻塞时；
- 获取
sync.Mutex锁失败需要休眠时； - 调用
time.Sleep或time.After等待时； - 进入系统调用（如文件IO、网络IO）时；
- 调用
runtime.Gosched()显式让出时。
上面这些操作，本质上都意味着“当前G没法继续往前跑了”，调度器会把它放到合适的地方（本地队列、全局队列或等待队列），然后mcall切到调度循环，换下一个G上来。
问题在于，如果代码里没有任何调度点怎么办？比如一个赤裸裸的for {}空转循环，既不调函数也不碰channel。Go 1.14之前，这种情况能直接把整个进程卡死：单核环境直接系统假死，多核环境里其他P上的G还能跑，但那个P上排队的G全被饿死。这就是协作式调度的漏洞——它管不住一个“自觉性为零”的G。
2.3 信号抢占：10ms之后，由sysmon强制打断
Go 1.14引入了基于信号的异步抢占，终于治住了无限循环的“钉子户”。负责干这件事的是运行时后台的监控线程sysmon。
sysmon每隔一小段时间（毫秒级）醒来扫一遍，其中一项检查是：遍历当前所有P，如果某个P上运行的G已经连续运行超过forcePreemptNS，也就是10ms，就认为该抢占。此时sysmon会向那个P所在M发送SIGURG信号。M收到信号后，会执行运行时预先注册的信号处理函数。这个函数不会立刻杀掉当前G，而是利用信号处理时机把当前G标记为可抢占，然后切回调度器，把G放回队列，让调度循环重新选人。
这段流程有几个关键点值得注意。
第一，SIGURG本身是Go运行时自己用的信号，正常开发中一般不会和业务代码冲突，但如果你在自己的代码里也用了SIGURG做自定义功能，Go 1.14之后可能会踩到无法预料的坑。
第二，抢占不是“立刻”完成的。如果G正卡在某个系统调用里，信号没法马上打断它；如果G正在做很长的计算，中间会有函数调用和栈检查，信号处理才有机会执行。所以实际运行时间往往略大于10ms，但数量级上不会偏差太多。
第三，抢占之后G是怎么被安排的？实际行为是：被抢占的G会被重新塞回当前P的本地队列，它不会直接被丢到全局队列末尾，这在一定意义上保护了它的“缓存热度”。这个细节也解释了为什么一个空转循环被打断后，下次依然能很快再被选中。
2.4 10ms这个值是怎么定下来的
forcePreemptNS的10ms数值不是拍脑袋定的。它平衡了这样几件事：调度器自身扫描的精度、信号处理的开销、以及用户可感知的延迟。10ms对人来说几乎无感知，对服务器场景来说也算够快；如果把这个值调成1ms，信号触发频率就会暴涨，万一正好有大量长计算G频繁被打断，光信号处理和上下文切换就能吃掉不少CPU。如果调成100ms，一个循环里没有让出点的G会把同P上的其他G饿得肉眼可见。
正因为如此，10ms只是一个兜底阈值，不意味着每个G都能跑满10ms。绝大多数G因为channel、锁、Sleep，会在几微秒到几百微秒内主动让出，根本轮不到信号抢占出场。只有那些无限循环、纯CPU密集计算“不知疲倦”的G，才会被10ms这道红线拦住。
3. 公平性：轮转、偷取与防饿死
3.1 全局队列的权重设计
既然本地队列优先，那全局队列里的G什么时候才有机会被捞出来？如果调度器每次都先看本地队列，那么只要本地队列不清空，全局队列里的G就可能永远轮不到。Go的解决办法是给全局队列一个“准入配额”。
在schedule()里，每执行61次调度循环，就会尝试从全局队列批量取一批G放到本地队列。这个61次是从哪来的？源码注释里说，它是为了避免全局队列被饿死而设的固定权重：本地队列执行约61次，全局队列才有一次多取机会。批量取的时候也不是只取一个，而是尽量一次取走“数量为本队列容量一半”的一批，减少取一次的锁开销。
这样设计的结果是：全局队列的G即便没有本地G那么受欢迎，也总有被“想起来”的时候，等待时间的上界是有保证的，不会出现理论上无限饿死的情况。
3.2 work stealing：多核时代的平衡术
当某个P的本地队列空了，全局队列也空了，而其他P的本地队列还有不少任务时，空闲的P不会傻等，它会去偷。
偷取的逻辑大致这样：从某个随机的目标P开始，调用runqsteal去拿对方本地队列的一半任务（准确说，是n/2个，其中n是目标队列当前长度）。偷一次拿一半，是为了避免把目标P的任务全部搬走——那会导致目标P随后无事可做又反过来偷你的，形成抖动。
Go会限制同时处于spinning状态的M数量，避免所有空闲M一窝蜂去偷同一个P，造成锁竞争。只有当某个P的任务被偷光时，它自己才会去偷别人，这种“需求驱动”的偷取策略比全局定时均衡要轻量得多。
从这里也能看出，偷取本质上就是在多核之间重新分配任务，是公平性的横向维度。纵向维度是同一P上的队列轮转，横向维度是跨P的任务搬运，两者叠加，整个调度器才谈得上相对公平。
3.3 那些“不那么公平”的角落
调度器的公平性是相对的，以下几个场景对某些协程并不那么友好。
第一，新创建的G天然有优势。因为go func()出来的G优先进runnext，而runnext上的G下一轮就可能被调度。如果某段代码在一个循环里不断go func()，这些新G会不断挤占runnext位置，原有队列里的老G就只能往后排。这个设计是故意为之——新任务往往意味着新请求，延迟敏感度通常更高。代价是老任务可能被轻微延迟。
第二，被抢占的G回队位置有讲究。前面说过，抢占后的G一般会被放回本地队列，而不是全局队列。这在单个P上保持了“刚跑过的协程很快还能再跑”的局部性，但同时也意味着一个反复被抢占的循环G，可能会反复插在本地队列靠前的位置，让同队列其他G的等待时间拉长。好在它如果每次运行不满10ms就被主动让出（比如带了一个runtime.Gosched()），行为会温和很多。
第三，某些G会“长时间占着P不放”。典型例子是执行一个很长的系统调用或者CGO调用。此时G和M绑定在一起，P会被让出来，但G并没有让出执行权，它只是把P还给了别人。这不算饥荒，但确实让“M的数量不可控”，极端情况下会创建大量线程。
3.4 极端场景：单核下一百个协程谁先跑
把问题收敛到单核。P只有一个，本地队列只有一个，全局队列也只有一份。调度顺序大体是：runnext优先，然后本地队列FIFO，每61次调度从全局批量捞一次。这样一个协程创建出若干子协程后，正常情况下大家都能按比较均匀的间隔被运行，不会出现某个协程等十几秒的情况。
但如果有人在循环里疯狂go func()，因为runnext总是被新G占住，老G的等待时间会变长。想验证的话，可以写一段代码：一个for循环不断go一个空任务，另一个goroutine每隔100ms打印一次时间戳。在多核和单核下分别观察，你会发现单核下打印时间戳的协程可能被明显延迟，这就是runnext优先级带来的“轻饥饿”。解决办法也很直接：少创建无意义的瞬时协程，或者用带缓冲的channel做流量控制，这比调调度器参数靠谱得多。
4. 抢占机制的版本演进：从“自觉”到“强拆”
4.1 早期协作式抢占的致命伤
Go 1.14之前并不是完全没有抢占，而是只有协作式抢占。编译器的栈检查会在函数序言部分检查栈是否够用；当GC需要STW时，它会通过标记G的栈已满来触发一次抢占。也就是说，编译器在每个函数入口埋了一个“检查点”，如果发现抢占标志，就主动让出。
这套机制的漏洞非常明显：如果一个G陷入没有函数调用的大循环，比如for {}，它就永远碰不到栈检查，也就永远无法被抢占。无数Go开发者在这上面踩过坑：并发写了个死循环，单核程序直接卡死，多核程序GC一直等那个G停下，然后整个进程进入卡顿状态。
4.2 Go 1.14：信号抢占改变了什么
Go 1.14引入的异步抢占，本质上就是用信号强行制造“调度点”。sysmon发现某个G跑太久，就给对应的M发SIGURG，M的信号处理函数会在当前栈上寻找安全点，把G标记为抢占，然后主动切走。编译器的协作式抢占依然存在，但多了这样一条“强制通道”。
这带来的最大变化是：纯CPU密集的G不再能彻底霸占住一个P。即便它从头到尾没有一次函数调用式的让出，也会在10ms左右被信号打断一次。GC的STW也不再因为某条空转协程而无限等待，调度器终于能把G从“正在运行”状态里强行拖走。
需要提醒的是，信号抢占并不意味着“线程在任意时刻都能切走”。如果G正在一个不受信号处理影响的临界区里，或者所在M正在执行一个非常深的原生调用栈，抢占依然要等待安全点。但在常规Go代码里，信号抢占已经足够可靠。
4.3 后续版本里公平性的微调
Go 1.14之后，调度器的公平性并没有发生推翻式的重写，但一直在用细节修补。比如Go 1.17实现了一轮调整，改进了findrunnable()里对netpoll和timer任务的调度时机，避免某些定时任务被长队列遮挡。Go 1.20左右开始对timer做大规模重构，把定时器分散到每个P上，避免全局timers锁成为调度瓶颈。Go 1.21的timer改动又进一步，减少了唤醒P之后无活可干的空转。
这些改进看起来都不叫“公平性”，但实际效果都指向同一个目标：减少调度路径上的非必要等待，让该运行的G更快地被选中。公平性从来不是一项单独的功能，而是队列结构、优先级、抢占、自动唤醒、负载偷取等各种机制共同叠加出来的结果。
5. 实操观测：用代码和工具看清调度行为
5.1 制造一个“霸占CPU”的G并验证抢占
想知道自己的Go版本是否支持信号抢占，写个简单程序就能验证。单核跑：
go复制package main
import (
"fmt"
"runtime"
"time"
)
func main() {
runtime.GOMAXPROCS(1)
go func() {
for {
// 空转，不碰任何调度点
}
}()
time.Sleep(100 * time.Millisecond)
fmt.Println("main goroutine still alive")
}
在Go 1.13或更早版本上，这段代码运行后fmt.Println大概率永远打不出来，因为那个空转的G把唯一的P占死了。在Go 1.14及以后，运行一段时间后主协程的fmt.Println会执行到，虽然可能需要比100ms更长一点的时间，因为空转G会被10ms抢占一次，P在重新调度时还是会优先把那个G再捞回去。这个例子也侧面说明：信号抢占能防卡死，但不代表无限循环的G会“谦让”。
5.2 GODEBUG=schedtrace：最直观的调度观测窗口
运行时内置了调度器日志，不需要额外安装任何工具。设置环境变量就能打开：
bash复制GODEBUG=schedtrace=1000 go run main.go
schedtrace=1000表示每1000毫秒打印一次调度信息。输出大概长这样：
code复制SCHED 1000ms: gomaxprocs=4 idleprocs=0 threads=5 spinningthreads=0 idlethreads=0 runqueue=2 [0 1 3 2]
逐个解释字段：gomaxprocs是P总数，idleprocs是空闲P数，threads是当前M总数，spinningthreads是处于偷取中的M数，runqueue是全局队列长度，[0 1 3 2]是每个P本地队列的长度。
这个输出在排查调度失衡时特别好用。如果某个P的本地队列长期远高于其他P，说明任务分配不均，可能是goroutine创建者和执行者的绑定关系导致；如果runqueue一直很大而idleprocs也很大，说明有任务在排队但P却在闲置，多数原因是任务分布不均或存在锁竞争；如果threads数量比P数量多出一大截，说明有不少M卡在系统调用或CGO里。
5.3 用pprof和trace做更细的观察
schedtrace看的是宏观队列，想看单个G的生命周期，可以用go tool trace。在代码里挂一个trace.Start，跑一小段时间，然后打开trace UI能看到每个G从创建、运行、阻塞到结束的完整时间轴。排查“某个G迟迟没执行”时，trace里G的PROC状态会被标成Runnable还是Waiting，如果长时间是Runnable，说明它一直排不上队；如果长时间是Waiting，说明卡在某个channel或锁上。
日常排查性能问题，我习惯的组合拳是：先用pprof的goroutine profile看协程数量和调用栈分布，再用schedtrace看队列是否均衡，最后针对可疑的协程用trace确认它在时间线上的状态。三层下来，绝大多数调度相关的问题都能定位到具体原因。
6. 常见问题与排查技巧实录
6.1 为什么某个协程一直不执行
遇到这种问题，先别急着怀疑调度器乱了。按这个顺序排查：
- 用
runtime.NumGoroutine()确认协程是否存在，很可能它已经退出或者根本没被创建成功； - 用
go tool pprof抓goroutine stack，看这个G当前状态是Runnable、Waiting还是Syscall。Waiting要找到等待的channel或锁，Syscall要检查是不是卡在某个外部调用里； - 如果是Runnable但一直不运行，用
schedtrace看对应P的本地队列是不是被人反复占满，最常见的原因就是某个循环G在制造新协程并持续抢占runnext。
6.2 为什么time.Sleep的协程会延迟很久
time.Sleep本身就有误差，调度延迟更大时误差更明显。timer唤醒的G不是立刻执行的，它只是被放进了可运行队列，还要参与调度排队。如果这时某个P正在跑一个10ms才被抢占的循环，sleep 1ms的G可能实际等几十毫秒才醒。
业界有句调侃叫“Go的sleep精度只能到秒级”，虽然不是严格准确，但也提醒我们：别拿time.Sleep当精确定时器用，业务对延迟敏感就用定时任务框架或者自己维护堆结构，而不是依赖调度器的排队运气。
6.3 写代码时怎么配合调度器的公平性
调度器能兜底，但好的并发代码应该尽量不麻烦它兜底。我的几个习惯：
- CPU密集任务，如果分成多个阶段，每阶段里主动调用
runtime.Gosched()或time.Sleep(0)让出一次，对公平性帮助很大； - 大量创建协程时用channel做信号量限流，不要无脑
go几百万个任务，把压力全部转嫁给调度队列； - 避免“无限循环+无调度点”的写法，哪怕加一个
select {}等待事件也比裸for {}好； - 对延迟要求高的协程，可以考虑用
runtime.LockOSThread()绑死一个M，让操作系统单独给它分时，但别滥用，M是稀缺资源。
6.4 紧抓“公平性”排查的工具小结
把工具用法汇总成一张速查表，方便以后排查：
| 现象 | 首选工具 | 关键指标 | 可能原因 |
|---|---|---|---|
| 某核CPU打满 | top/htop + schedtrace | 单个P占比高 | G在无限循环或长计算，靠信号抢占兜底 |
| 协程能创建但执行极慢 | pprof goroutine | Runnable堆积 | 本地队列被高优先级任务占满 |
| 全局队列堆积 | schedtrace | runqueue值大 | 任务创建不均衡或系统调用阻塞 |
| 大量线程产生 | schedtrace | threads远大于GOMAXPROCS | 阻塞型系统调用/CGO导致M堆积 |
| 单核性能异常差 | trace | G状态Runnable等待久 | 调度延迟过大，检查锁竞争 |
7. 写在最后的一点体会
反复啃过调度器源码之后，我对“时间片”和“公平性”这两个词的认知发生了很大变化。Go的调度器并没有一个像操作系统那样的固定时间片计数器，它更强调整体运行效率：用runnext加速新协程，用本地队列FIFO保证同P公平，用全局队列权重兜底防饿死，用信号抢占拦住无限循环的协程，再用work stealing平衡多核负载。所谓公平，是这一整套机制共同约束出来的结果，而不是某个单一参数的功劳。
实际写代码的时候，我反而很少去想如何“优化调度器”——那是Go核心团队的事。我更关注的是：自己的并发模型有没有制造大量无意义协程、有没有在临界区里干过久的事情、有没有给延迟敏感任务留出运行空间。把这些问题想清楚，比背多少调度器内部结构都有用。毕竟，调度器做的一切公平性设计，最终都是为了让业务代码跑得顺，而不是反过来替你填并发设计的坑。