1. 调度公平性的源头P本地队列、全局队列和工作窃取如果你写过一段长时间运行的 Go 服务大概会遇到过这种诡异场景某个 goroutine 明明在正常跑其他 goroutine 却像被堵在早高峰地铁口一样怎么挤都上不了车。表面上看这是“卡死”但锁也想过了、死锁也想过了最后查出来的原因居然是调度器的公平性被某个角落里的循环打破了。先别急着看代码我们得从 Go 调度器的原始设计说起。Go 的调度器不是单纯的“协程→线程”映射而是引入了 PProcessor这一层。G 是 goroutineM 是操作系统线程P 是承载调度上下文的虚拟处理器GOMAXPROCS控制的是 P 的数量也就是真正能并行运行的 goroutine 路数。M 想要执行一个 G必须先拿到一个 PP 手里维护着两个重要东西本地可运行队列以及一组调度状态。真正和公平性强相关的是队列。每个 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环境变量。启动你的程序时带上GODEBUGschedtrace1000调度器会每隔 1000 毫秒往 stderr 打印一行当前调度状态。长这样SCHED 1003ms: gomaxprocs8 idleprocs6 threads5 spinningthreads1 idlethreads0 runqueue0 [0 0 0 0 0 0 0 0]逐段拆开看gomaxprocs8说明有 8 个 Pidleprocs6有 6 个 P 空闲说明负载不高runqueue0是全局队列长度最后方括号里的 8 个数字是每个 P 本地队列的长度。如果某个 P 的本地队列长期非零、全局队列也在涨说明任务生产速度大于消费速度。如果方括号里某个 P 长期是 0 但 CPU 占用却很高要么是那个 P 在执行一个长时间运行且不可抢占的 G要么就是 goroutine 卡死在 syscall/CGO 里了。比 schedtrace 更细的是GODEBUGschedtrace1000,scheddetail1。加了scheddetail1之后输出会详细到每个 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?debug1这个页面会 dump 出所有 goroutine 的堆栈和当前状态。debug1格式下你能看到类似这样的行goroutine 123 [runnable, 3 minutes]: main.workerLoop() /app/main.go:42注意方括号里的状态。[runnable]表示这个 goroutine 已经准备好执行但还在队列里等 P如果它前面堆了一堆[runnable]状态的 goroutine而你的 CPU 又没有满那大概率是调度出了问题或者系统线程都被卡死。反之如果一个 goroutine 长时间[running]状态且堆栈一直停在同一个函数那你可能要看看它是不是真的被什么问题缠住了。第三个入口是trace。你需要先抓一段运行期 tracecurl -o trace.out http://localhost:6060/debug/pprof/trace?seconds5 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 涨到 30sCPU 核数全满但 QPS 掉了一大截。查 pprof发现一个 worker 里的for { ... 大量浮点运算 }占了 99% 的 CPU所有其他 goroutine 都堆在[runnable]状态。定位链路是这样的先用GODEBUGschedtrace1000看全局队列发现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 资源想清楚这个你的方案才真正落地。