1. 调度公平性的源头：P本地队列、全局队列和工作窃取
如果你写过一段长时间运行的 Go 服务，大概会遇到过这种诡异场景：某个 goroutine 明明在正常跑，其他 goroutine 却像被堵在早高峰地铁口一样，怎么挤都上不了车。表面上看这是“卡死”，但锁也想过了、死锁也想过了，最后查出来的原因居然是：调度器的公平性被某个角落里的循环打破了。
先别急着看代码，我们得从 Go 调度器的原始设计说起。Go 的调度器不是单纯的“协程→线程”映射，而是引入了 P（Processor）这一层。G 是 goroutine，M 是操作系统线程，P 是承载调度上下文的虚拟处理器，GOMAXPROCS控制的是 P 的数量，也就是真正能并行运行的 goroutine 路数。M 想要执行一个 G，必须先拿到一个 P；P 手里维护着两个重要东西：本地可运行队列，以及一组调度状态。
真正和公平性强相关的，是队列。每个 P 都有一个本地运行队列，源码里就是 P 结构体上的runq [256]guintptr，一个容量为 256 的环形数组，配合runqhead和runqtail两个游标使用。生产者和消费者都在这个环形队列上操作，大多数时候不需要碰全局锁。全局队列则是一个需要持有sched.lock才敢动的链表，存的是那些没能塞进本地队列的 goroutine。
这里你就能看出第一个公平性问题的雏形：新产生的 goroutine 默认会先进入当前 P 的本地队列，只有本地队列满了，才会通过runqputslow把一半任务丢到全局队列里去。换句话说，本地队列是“亲儿子”，全局队列是“养子”。如果没有额外的规则兜底，一个繁忙的 P 完全可以一直消费自己的本地队列，让全局队列里的任务永远饿着。
于是工作窃取（work stealing）机制登场了。当一个 P 的本地队列空了，它会去其他 P 的本地队列里“偷”一半的任务过来执行。runqsteal的实现就是取对方本地队列长度的一半，批量搬走。偷一半而不是全偷，是为了减少两个 P 之间的锁竞争，同时让负载尽量平滑。配合 GOMAXPROCS 的并行度，工作窃取解决的是“某些 P 空转、某些 P 撑爆”的不均衡问题。
但工作窃取解不了另一个问题：如果你的本地队列压根就没空过，这个 P 上的 goroutine 会一直执行，其他 P 上的任务和全局队列里的任务可能根本轮不上。这个问题不在负载均衡层面，而在时间片公平层面。Go 必须有一个机制，强制让每个 P 时不时“回头看一眼”全局队列。这就是接下来要说的东西——调度循环里的那个特殊数字。
2. 61 这个数字：Go 怎么防止“本地队列霸凌”全局队列
打开runtime/proc.go，找到schedule()函数，你会看到一段代码：
if gp == nil { // Check the global runnable queue once in a while to ensure fairness. // Otherwise two goroutines can completely occupy the local runqueue // by always respawning each other. if _g_.m.p.ptr().schedtick%61 == 0 && sched.runqsize > 0 { lock(&sched.lock) gp = globrunqget(_g_.m.p.ptr(), 1) unlock(&sched.lock) } }源码注释已经把意图写得非常直白：定期从全局队列取一个任务，保证公平。schedtick是当前 P 的调度次数计数，每完成一次调度加一。当它是 61 的整数倍时，调度器会尝试从全局队列里取一个 G 出来执行。这意味着什么？一个 P 每执行 61 个本地队列任务，就会强制回头看一眼全局队列。
为什么是 61，而不是 2、10、1000？网上有人说是出于经验值，有人翻出了老版本 commit 找灵感。我的理解是：这个数字要和本地队列容量 256 配合看。61 远小于 256，说明即便本地队列很满，全局队列里的任务最多也就等一轮本地队列循环就能被瞥见，饿死风险被压在可控范围内。这个周期又不会太短，因为频繁拿全局队列需要抢全局锁，会破坏本地队列带来的缓存局部性优势，反而降低吞吐。
不过，schedule()里的这个 61 次检查并不是全部。findrunnable()里的取任务顺序也有讲究，一个 M 寻找可运行 goroutine 的顺序大致是：
- 先从当前 P 的本地队列拿；
- 每 61 次调度拉一次全局队列；
- 本地队列为空时，尝试从其他 P 偷一半任务；
- 偷不到，去检查 netpoll 是否有因网络 IO 就绪而被挂起的 goroutine；
- 都拿不到，进入休眠等待被唤醒。
注意globrunqget这个函数还有个小细节：如果全局队列积压的任务非常多，它不会只取一个，而是按n = sched.runqsize/gomaxprocs + 1计算出一个批量值，上限是本地队列的一半。也就是说，一旦全局队列出现堆积，调度器会把任务成批搬回本地。这时候的公平性不只看“取不取”，还要看“取多少”。
这套机制解释了一个现象：为什么你往全局队列丢一个任务，它并不会立刻执行，但也不会永远不执行。除非系统已经极端到所有 P 都在忙，否则最多等一轮完整的“61 次调度周期”，这个任务就会被某个 P 捡走。从延迟角度看，61 次本地调度的时间通常微乎其微，所以大多数业务代码根本感知不到这个“回头”动作。
但你可能会想，61 次检查保证的只是“任务有机会被调度”，如果某个 goroutine 拿到 CPU 后死循环跑 10 分钟不放手，那公平性照样崩。这里就引申出下一层问题：Go 怎么把一个正在运行的 G 从 CPU 上拽下来？
3. 从协作式到信号抢占：Go 1.14 如何给失控 goroutine 套上缰绳
很多人不知道，早期 Go 的抢占其实是“协作式”的。在 Go 1.14 之前的版本，一个 goroutine 只有在碰到函数调用、栈扩容、channel 操作这类“协作点”时，才会检查自己是否应该让出 CPU。编译器会在函数入口和栈检查逻辑里插入抢占检查代码，runtime.morestack()附近就是典型的检查点。这意味着什么？如果你的 goroutine 是一个紧凑的纯计算循环，不调用任何函数、不分配栈、不碰 channel，那调度器再急也拿它没办法，其他 goroutine 只能看着这个“黑心住户”霸占 P。
我印象很深，以前在 Go 1.13 时代排查过一个线上事故：一个 worker 里写了for { sum += i*i*i }，里面没有函数调用，也没有 IO，结果这个 goroutine 把整个进程的 CPU 吃满，其他 goroutine 的响应时间一路飙到几十秒，看起来就像死锁了一样。后来靠go tool pprof定位到那个循环，在合适的位置加了runtime.Gosched()才救回来。
Go 1.14 引入了基于信号的异步抢占，才从根上解决了这个问题。现在sysmon这个系统监控线程会在后台定期扫描所有正在运行的 P，如果发现某个 G 的运行时间超过了forcePreemptNS——这个值在源码里是10 * 1000 * 1000，也就是 10 毫秒——就会向对应的 M 发送一个 SIGURG 信号。信号处理函数会执行asyncPreempt，在正在运行的 goroutine 上下文中插入一个抢占点，迫使它让出 CPU 并重新进入调度循环。
如果拿生活类比，协作式抢占像是“靠自觉排队”：每个人办完事自己走人；异步抢占则是“保安看时钟，到点直接请你出去”。这个变化对公平性的意义是革命性的：哪怕你的 goroutine 是一个没有任何函数调用的死循环，最多 10ms 也会被信号打断一次。
但“10ms 被强抢”不等于“公平性万无一失”。信号抢占有一个天然盲区：如果正在执行的代码处于系统调用、CGO 调用、或者某些无法安全处理信号的关键区段，SIGURG 可能不会立即生效，P 会先被让出给其他 M 使用，等原 goroutine 真正回到可抢占状态，再完成调度。另外，异步抢占本身也有开销，信号引入了额外的上下文切换成本，在极端高并发场景下，调度抢占信号甚至可能影响 GC 的 STW 耗时。所以你在生产环境里用 Go 1.14+，大部分时候不用再手动塞runtime.Gosched()，但你仍然需要知道自己代码里的密集计算会在什么时候被调度器“打断”。
还有一个常见误解：runtime.Gosched()不是抢占，它只是把当前 goroutine 放回可运行队列的尾部，主动让出 P。它适合用在“我知道自己该让一让但调度器还没强制触发”的场景，比如计算密集型任务里每隔几万次迭代主动让一次。但如果你每个迭代都Gosched()，反而会因为频繁入队出队放大调度开销，得不偿失。
到这为止，Go 调度器保证的是：所有 goroutine 都有机会被调度，没有哪个任务会被永久饿死。但注意，“有机会被调度”不等于“高优先级的任务先跑”。Go 官方从来没有给 goroutine 提供过类似线程优先级的SetPriority接口。那如果我确实有优先级需求，该怎么办？
4. “优先级”的真相：没有 priority 字段，但有三种软实现
先说为什么 Go 不提供优先级机制。一方面，GMP 模型是多对多调度，一个 G 可能在不同 M 上跑来跑去，真正的 OS 线程优先级没法直接映射到 G 上；另一方面，给协程分优先级会大幅增加调度器复杂度，容易引入优先级反转、饥饿、死锁等各种问题，设计与维护成本极高。Go 的选择是“不搞显式优先级，用公平性兜底”。这招在绝大多数场景下是对的，但真到了需要优先级的场景，我们只能自己动手。
我实际用下来，比较靠谱的软优先级方案有三个。
第一种是两级分发器。有人喜欢叫它 dispatcher 模式：把任务按优先级放进不同的 channel，由一个独立的分发 goroutine 统一取任务，再提交给底层 worker 池执行。这里有个大坑，很多人第一次写都会翻车：直接在select里同时监听高优和低优 channel，以为高优任务多了，select就会多选中高优 channel。实际上 Go 的select在多个 case 都就绪时，会按伪随机算法随机挑一个，高优先级的任务再多，低优先级的任务也有近似均等的机会被选中。结果就是高优先级任务的平均延迟不降反升，白忙一场。
正确的严格优先写法是：先非阻塞检查高优 channel，拿到就继续；高优 channel 空了，才去低优 channel 拿。下面是一个最小可运行的严格优先分发器：
type Task struct { Fn func() } func strictPriorityDispatcher(highCh, lowCh <-chan Task, worker func(Task)) { for { select { case t := <-highCh: worker(t) continue default: } select { case t := <-highCh: worker(t) case t := <-lowCh: worker(t) default: runtime.Gosched() } } }这个实现反映了一个取舍：当高优任务持续不断时，低优任务会被完全饿死。业务上如果你想兼顾“高优快”和“低优不被饿死”，就别用严格优先，改用加权公平。思路很简单：给高优任务设一个额度，比如跑 5 个高优任务后强制拿 1 个低优任务，类似“高优每轮 5 次配额，用完就先看低优”。配额制几乎是所有生产级优先队列的通用解法。
第二种是主动让出配合“调度密度”策略。思路是：给高优任务更多的执行窗口，靠runtime.Gosched()控制低优任务的执行频率。比如低优任务每跑一个批次就主动Gosched()一次，让高优 worker 有机会抢占 P。这个方法简单粗暴，适合任务量不大、又不愿意引复杂度的情况。但它不够精确，只适合“差不多就行”的软实时需求。
第三种是runtime.LockOSThread加独占线程的边界做法。LockOSThread()可以把当前 goroutine 和它所在的 M 绑定，之后这个 M 只服务这个 goroutine。配合GOMAXPROCS之外的额外线程，你可以让某个高优 worker 独占一个线程，减少线程切换抖动。代价是线程资源被占用，goroutine 也失去了跨线程调度的灵活性，用完后必须及时UnlockOSThread，否则线程就泄漏了。这个方案本质上是用资源换稳定性，不是真正的优先级调度，但它确实能在一些特殊场景下（比如音视频处理、实时信号采集）达到类似效果。
我自己的建议排序是：绝大多数业务场景用加权公平；少数强需求用严格优先 + 对低优任务做饥饿保护；LockOSThread 只在碰到底层代码或需要线程局部状态时用。千万少碰那种“用 select 随机选 case 强行假装有优先级”的写法，那只会给你一个虚假的控制感，该慢的还是一样慢。
不过话说回来，你选择哪种优先级策略，最后都需要验证。凌晨三点线上出问题的时候，光靠读代码是定位不了调度问题的，手上得有工具。
5. 观测调度器的四个入口：schedtrace、scheddetail、pprof、trace
先提一个最容易上手的工具：GODEBUG环境变量。启动你的程序时带上GODEBUG=schedtrace=1000，调度器会每隔 1000 毫秒往 stderr 打印一行当前调度状态。长这样：
SCHED 1003ms: gomaxprocs=8 idleprocs=6 threads=5 spinningthreads=1 idlethreads=0 runqueue=0 [0 0 0 0 0 0 0 0]逐段拆开看：gomaxprocs=8说明有 8 个 P；idleprocs=6有 6 个 P 空闲，说明负载不高；runqueue=0是全局队列长度；最后方括号里的 8 个数字，是每个 P 本地队列的长度。如果某个 P 的本地队列长期非零、全局队列也在涨，说明任务生产速度大于消费速度。如果方括号里某个 P 长期是 0 但 CPU 占用却很高，要么是那个 P 在执行一个长时间运行且不可抢占的 G，要么就是 goroutine 卡死在 syscall/CGO 里了。
比 schedtrace 更细的是GODEBUG=schedtrace=1000,scheddetail=1。加了scheddetail=1之后，输出会详细到每个 P 的状态、每个 M 的状态、每个线程的空闲情况。信息量很大，适合做深度定位，但需要花点时间适应格式。我建议平时先用基础版看个大概，确认线索之后再上 detail。
第二个入口是net/http/pprof。如果你的服务已经挂了import _ "net/http/pprof"，直接访问：
go tool pprof http://localhost:6060/debug/pprof/goroutine或者用浏览器打开：
http://localhost:6060/debug/pprof/goroutine?debug=1这个页面会 dump 出所有 goroutine 的堆栈和当前状态。debug=1格式下，你能看到类似这样的行：
goroutine 123 [runnable, 3 minutes]: main.workerLoop() /app/main.go:42注意方括号里的状态。[runnable]表示这个 goroutine 已经准备好执行，但还在队列里等 P；如果它前面堆了一堆[runnable]状态的 goroutine，而你的 CPU 又没有满，那大概率是调度出了问题或者系统线程都被卡死。反之如果一个 goroutine 长时间[running]状态且堆栈一直停在同一个函数，那你可能要看看它是不是真的被什么问题缠住了。
第三个入口是trace。你需要先抓一段运行期 trace：
curl -o trace.out http://localhost:6060/debug/pprof/trace?seconds=5 go tool trace trace.out打开 trace 页面后，重点看 “Goroutine analysis” 和 “Proc” 视图。在 Proc 视图里，每一个横行代表一个 P，上面的一根根时长大条代表这个 P 正在执行哪个 goroutine。如果某个 P 长时间被同一个 goroutine 占据，颜色条几乎不切换，这就是典型的“P 被霸占”信号。Goroutine analysis 视图则能看到每个 goroutine 的状态时长分布，比如某个 goroutine 在Runnable状态停留了很久，说明它一直在等调度。
第四个入口比较新，是runtime/metrics。你可以在代码里通过runtime/metrics包读取/sched/pauses/total:seconds、/sched/latencies:seconds这类指标。这个更适合做成监控告警而不是临时排查。我已经见过不少团队把调度抢占延迟接进 Prometheus，一旦某段时间调度抢占延迟异常偏高，说明线上有 goroutine 正在被频繁强抢，往往伴随业务延迟抖动。
说句大实话：这些工具单看某一个都容易误判，最好组合起来。比如schedtrace告诉你全局队列在堆积，pprof 告诉你堆积的角色是谁，trace 告诉你它到底卡在哪个阶段，runtime/metrics告诉你这个问题是不是持续性的。四样东西凑齐了，你的定位基本不会跑偏。
6. 调度饥饿排查实录：三个案例的完整定位链路
工具归工具，真正你要学会的是“排查链路”。我拿三个亲身踩过的坑当例子讲一下，每个都能看出调度器公平性问题在真实场景里的形态。
第一个案例是 Go 1.13 时代的纯计算循环饿死其他 goroutine。现象：服务接口延迟从 2ms 涨到 30s，CPU 核数全满，但 QPS 掉了一大截。查 pprof，发现一个 worker 里的for { ... 大量浮点运算 }占了 99% 的 CPU，所有其他 goroutine 都堆在[runnable]状态。定位链路是这样的：先用GODEBUG=schedtrace=1000看全局队列，发现runqueue在快速增长，说明很多任务根本没有机会被调度；再用go tool pprof抓 CPU profile，一眼锁定那个纯计算循环。当时没有异步抢占，最终解法是给循环加了一个runtime.Gosched()，让出时间片给其他 goroutine。后来我把服务升级到 Go 1.14，同样一段代码不需要手动Gosched也能被定期强抢，这个案例后来成了我跟别人讲“为什么 Go 1.14 是里程碑版本”时的经典素材。
第二个案例是我在业务里植入自定义“优先级”导致的故障。当时我负责的一个服务，上游不同等级用户的任务需要不同响应速度。我图省事，用两个 channel 加一个select做分发，代码如下：
select { case t := <-highCh: handleHigh(t) case t := <-lowCh: handleLow(t) }结果线上表现很奇怪：低优任务量一大，高优任务的 P99 延迟也跟着飙升，和没做优先级系统几乎一样。后来我意识到，select在多个 case 同时就绪时会随机选择，高优任务并不享受任何优先权。改成“先非阻塞检查高优 channel，再查低优”之后，高优先级的 P99 立刻降了一个数量级。这个案例让我彻底记住了：任意一个“既然用 Go 就天然有优先级”的幻觉都要不得。
第三个案例是一个典型的调用链饥饿。现象是整个服务卡顿，但 CPU 使用率只有 30%，看起来像空跑。schedtrace显示每个 P 本地队列都是 0，全局队列也是 0，压根没有任务在排队。后来用trace一看，发现有一个 goroutine 卡在syscall状态，而且因为 syscall 卡太久，它的 P 被系统自动移交给了其他 M，新 M 起来后也在等同一个 syscall 返回，线程数蹭蹭往上涨。这个问题的根因不在调度器，而是某个第三方 CGO 库调用了阻塞式的原生 socket 读取，把线程卡死了。这提醒我：调度器公平性再强，也挡不住底层的阻塞调用。遇到“CPU 不高但系统卡顿”的症状时，不要第一时间怀疑调度器，先用go tool trace看线程状态。
这套排查链路走完，你可以发现一个规律：真正的调度器公平性问题，反而在 Go 1.14 之后越来越少见了；更多时候，问题出在我们自己写的“绕开调度器”的代码上——要么是底层阻塞调用占死了线程，要么是自己实现了一套拙劣的优先级逻辑。
说句心里话，我研究 Go 调度器公平性这几年，最大的体会是：调度器能保证的只是“大家都有机会跑”，它不承诺“该你先跑就先跑你”。如果你需要的是后者，那就得自己设计任务分发策略。而且无论设计得多漂亮，一定要先想清楚一个问题：高优任务的优先级是靠什么换来的？是牺牲低优的延迟，是牺牲系统吞吐，还是牺牲 CPU 资源？想清楚这个，你的方案才真正落地。
