📚 课程目录第4章调度抖动产生的根本原因

调度抖动产生的根本原因

调度抖动不是玄学，也不是随机现象。说白了，它背后有非常明确的根因。我在排查帧率问题时，发现绝大多数抖动都能归到五个原因上：上下文切换、优先级反转、锁竞争、中断、CPU迁移。你想想看，这五个因素只要有一个冒头，调度延迟就上去了，帧率自然就不稳。

理解这些根因，才能对症下药。而不是盲目调参数，那是在碰运气。

上下文切换，说白了就是操作系统把当前线程的寄存器、程序计数器、栈指针等状态保存起来，再恢复下一个线程的状态。这个过程需要时间，少则几微秒，多则几十微秒。看起来不多，但如果一秒内切换上千次呢？

我记得之前排查过一个Android游戏的帧率问题，画面每隔几秒就卡一下。用systrace抓了一圈，发现帧率掉到30fps的时候，每秒上下文切换次数飙到了8000多次。什么概念？光是切换开销就占了CPU时间的15%以上。

为什么会切这么频繁？
因为线程数设得太多了，而且都用的是默认的CFS调度策略，时间片一到就切。解决方案也不复杂：

避坑指南：我曾经在优化时只盯着"切换次数"看，忽略了"切换耗时"。后来才发现，不同芯片的切换开销能差3倍。所以不光要看次数，还要看单次开销。

优先级反转是个经典问题了。情况是这样的：一个高优先级线程等待的资源，被一个低优先级线程占着，而低优先级线程又被中优先级线程抢占了CPU，导致高优先级线程干等着。

你想想看，高优先级任务本来应该最先执行，结果被两个低优先级的任务间接阻塞了。这不反了吗？

我在做车载仪表盘项目时遇到过这个问题。显示刷新线程优先级最高，但它在等一个共享的帧缓冲区锁。这个锁被一个低优先级的日志写入线程占着，而日志线程又被几个中优先级的网络任务抢占了CPU。结果就是：仪表盘画面卡住，日志还在慢慢写。

解决方案主要有两种：

个人建议：我比较推荐优先级继承，实现简单，Linux的rtmutex默认就支持。但要注意，继承链不能太长，否则复杂度会上升。

锁竞争不仅仅是"等待"的问题。当多个线程同时争抢一把锁时，没抢到的线程要么休眠（mutex），要么原地自旋（spinlock）。自旋锁尤其害人——它在空转消耗CPU，调度器还不会把它换出去。

我在优化一个视频处理管线时，发现8个线程抢同一把锁，平均等待时间到了200微秒。200微秒看起来不大，但在60fps的要求下，一帧只有16.7毫秒，200微秒就占了1.2%。更关键的是，锁竞争的方差特别大，有时候等1毫秒，有时候等20微秒，这就直接导致帧率抖动了。

优化方向：

坑：我曾经把一把大锁拆成32把小锁，结果锁本身占的内存比数据还大，缓存行 bouncing 反而更严重了。所以细粒度不是越细越好，要结合实际场景。

中断是硬件用来通知CPU"有事了"的机制。问题是，中断处理程序（ISR）的优先级高于任何用户态线程。一旦中断来了，当前正在执行的线程直接被"掐断"。如果中断频率高，或者处理时间长，调度延迟就会剧烈波动。

我遇到过最典型的场景是网卡中断。千兆网卡在高负载下，每秒能产生几万次中断。每次中断处理虽然只有几微秒，但架不住次数多。渲染线程经常被"打断"，导致帧间隔从16ms突然变成20ms、25ms。

怎么解决？

曾经有个案例：一个实时音频项目，中断导致音频buffer underrun。我们把中断亲和性绑到core0，音频线程绑到core3，问题就解决了。简单有效。

CPU迁移指的是线程从一个核心被调度到另一个核心上执行。迁移本身的开销不大，真正的代价在于缓存失效。L1/L2缓存里存的都是"热"数据，一换核心，全得重新加载。

我记得在调试一个图像处理管线时，发现帧率每隔几秒就掉一次。查看调度记录，发现管线中的工作线程每2-3秒就被迁移到另一个核心。迁移后，L1命中率从95%掉到60%，L2命中率从80%掉到40%。性能直接腰斩。

为什么会迁移？
因为CFS调度器追求负载均衡，它觉得"每个核心跑一样多的线程"就是公平。但它不知道缓存亲和性这回事。

优化方法：

这五个原因，每一个都能单独引发调度抖动。更麻烦的是，它们经常组合出现。比如锁竞争可能导致上下文切换增加，中断又可能触发CPU迁移。排查的时候，我的习惯是先用perf stat或ftrace看全局指标，锁定嫌疑最大的2-3个方向，再深入分析。别想着一次全搞定，逐个击破才是正道。

一句话总结：调度抖动的根因不外乎这五类。你遇到的任何一个帧率问题，都能在这张表里找到影子。记住：先定位，再优化，别盲目动手。