一、调度基础：实时系统定义、硬实时与软实时区别、调度算法评价指标

1.1 到底什么是实时系统？

先聊聊实时系统的定义。很多人一听「实时」，就以为是「快」。其实不是。

实时系统的核心，不是算得快，而是在规定时间内必须完成。我习惯这么跟团队讲：你点外卖，30分钟送到，这叫实时。如果第31分钟才到，就算饭还是热的，系统也已经「失败」了。

实时系统，说白了就是时间确定性的系统。它保证任务在截止时间之前完成。至于CPU跑多快，那是另一回事。

我在项目中遇到过不少新人，上来就问我：「这个系统延迟只有10微秒，算不算实时？」我通常会反问：「你能保证最坏情况下也是10微秒吗？」如果不能，那就不是实时系统。

1.2 硬实时 vs 软实时：差在哪里？

这个区别，我建议你从「错过截止时间的后果」来理解。

特性	硬实时	软实时
错过截止时间	系统崩溃 / 灾难性后果	性能下降 / 用户体验变差
典型场景	飞行控制、安全气囊、心脏起搏器	视频播放、在线游戏、语音通话
调度策略	必须可调度性验证	尽力而为 + 统计保证
我个人的看法	「要么准时，要么死」	「偶尔卡顿，可以接受」

嗯，这里要注意。硬实时系统里，一次失败都不允许。我当年做汽车电子项目时，一个刹车控制任务的截止时间是5ms。如果超了，哪怕只有一次，测试直接不通过。为什么？因为真实场景下，那一次超时可能就是一场事故。

软实时就不一样了。你看视频偶尔卡一下，顶多骂两句，系统不会崩溃。所以软实时系统的调度，通常允许一定的错过率，比如99.9%的任务在截止时间前完成就行。

1.3 调度算法的评价指标

评价一个调度算法好不好，不能只看「快不快」。我一般从三个维度来看：

1.3.1 可调度性

这是硬实时系统的生死线。可调度性，就是问一个问题：给定一组任务，调度算法能不能保证所有任务都在截止时间前完成？

我记得有一次评审会上，架构师拍胸脯说「我们的调度没问题」。我当场让他算一下可调度性测试。结果一算，CPU利用率已经超过100%了。嗯，这就是典型的「感觉良好，实际崩盘」。

常用的可调度性测试方法：

• 利用率测试：对于RM调度，如果CPU利用率 ≤ n(2^(1/n) - 1)，则可调度
• 响应时间分析：计算每个任务的最坏情况响应时间，与截止时间比较
• 模拟验证：跑最坏情况下的任务序列，看是否超时

1.3.2 响应时间

响应时间，指的是从任务被触发到任务完成的时间。这里面有个关键点：最坏情况响应时间比平均响应时间重要得多。

你想想看，在实时系统里，平均响应时间再好看，如果最坏情况超时了，那也没用。我习惯用这个公式：

响应时间 = 任务执行时间 + 调度延迟 + 抢占延迟 + 资源等待时间

其中，抢占延迟是最容易被忽略的。我在一个项目中遇到过，任务本身只跑2ms，但因为被高优先级任务频繁抢占，实际响应时间达到了15ms。这就是典型的「执行时间短，响应时间长」。

1.3.3 吞吐量

吞吐量，就是单位时间内系统能完成的任务数量。这个指标在软实时系统中更重要。

举个例子：一个视频解码系统，每秒需要处理30帧。如果吞吐量能达到35帧/秒，那系统就绰绰有余。但如果只有25帧/秒，那就会卡顿。

吞吐量和响应时间，其实是一对矛盾。我个人的经验是：

• 硬实时系统：优先保证响应时间，吞吐量够用就行
• 软实时系统：在保证一定响应时间的前提下，尽量提高吞吐量

1.4 知识体系总览

下面这张图，是我梳理的本章知识结构。你可以把它当作一个「地图」，后面几章都会围绕这些核心概念展开。

1.5 本章小结

这一章，我们聊了三个核心概念：

• 实时系统：不是快，而是准时。逻辑正确 + 时间正确，缺一不可。
• 硬实时 vs 软实时：区别在于错过截止时间的后果。硬实时是「要么准时，要么死」，软实时是「偶尔卡顿，可以接受」。
• 三个评价指标：可调度性（能不能跑）、响应时间（跑得快不快）、吞吐量（跑得多不多）。

我个人建议，你在开始设计调度算法之前，先把这三个概念吃透。尤其是可调度性，这是硬实时系统的命门。我见过太多项目，前期不重视可调度性分析，后期上线才发现任务跑不完，最后只能降频、砍功能，得不偿失。

---

公众号:蓝海资料掘金营，微信deep3321