2.2.2　调度的目标

当系统中“想运行”的实体多于 CPU 的数量时，调度就不可避免地要在“效率”与“公平”之间做取舍。直观地说，一类目标希望把硬件压榨到更高的利用率，让单位时间内做更多的工作；另一类目标则关心个体体验，让单个作业或交互请求更早得到处理、等待更少、响应更稳。把这些目标与度量对应起来，读者在分析不同算法时才知道“该看哪一项数据”。

2.2.2.1　通用度量与直观目标

衡量调度“好不好”，通常不会只看单一指标，而是几项度量的组合。为了建立直觉，可以先把它们对齐到常见的体验或运营诉求上，再进入正式术语。

（1）CPU 利用率：期望处理机尽量“有活可干”，空转比例越低越好。该指标体现硬件使用效率，是长周期运营视角的核心目标之一。
（2）吞吐量：单位时间内完成的作业数量越多越好。它对应“单位时间干了多少活”，常与 CPU 利用率一起考量系统整体产出。
（3）周转时间／平均周转时间：从作业提交到作业完成所经历的总时间，希望越短越好；为了兼顾不同规模作业，常配合带权周转时间讨论“公平的快慢”。
（4）等待时间：作业在就绪队列中“干等 CPU”的累计时间，希望越短越好；它直接反映调度是否让作业长时间排队。
（5）响应时间：交互或时间分片场景下，从请求发出到系统首次给出可感知反馈的时间，希望越短且越稳定。对终端用户而言，响应时间往往比“最终完成得多快”更重要。
（6）可预测性（抖动小）：相同类型任务的等待与响应不应忽快忽慢。对在线业务与实时场景，稳定性与一致性本身就是目标。

这些度量彼此牵制：例如追求极致吞吐量时，个体响应可能变差；强压响应时间时，CPU 利用率与吞吐量可能下降。理解这种张力，是做出“场景化选择”的前提。

2.2.2.2　不同系统类型的侧重

并非所有系统对目标的偏好都一样。把典型环境分开放，可以更清晰地理解调度“在乎什么”。

（1）批处理系统：更关注吞吐量与平均周转时间，同时力求较高的CPU 利用率。批处理负载通常无人交互，短作业不应长期被长作业压制，因此在追求整体产出时，也要兼顾等待时间与“对短作业的友好度”。
（2）交互式系统：更看重响应时间与可预测性。用户希望“点一下就有反应”，哪怕最终计算稍慢也能接受。因此，调度应优先保证前台任务的及时切片与反馈，同时避免某些低优先级任务饥饿。
（3）实时系统：目标从“平均更好”转为“按时完成”。硬实时强调截止期满足率与时间行为的确定性，软实时则在保证核心任务按时的前提下，追求整体资源利用率。这里“可预测性”与“优先级约束”比平均指标更重要。

把系统类型与指标偏好对齐，有助于在题目给出“工作负载背景”时迅速判断该优先哪一类目标。

2.2.2.3　公平与优先的平衡

仅有平均指标并不能说明一切。实践中还需要处理“谁更重要”与“是否被长期忽视”的问题。调度在这方面的目标主要体现在两点：一是公平性，即相近类别的作业应获得相近的处理机机会，避免因偶然因素产生极端差异；二是避免饥饿，在长期运行中不让低优先级或长作业一直得不到服务。常见的做法是通过优先级表达相对重要性，再以老化机制等手段在长期统计上恢复公平。对考研解题而言，看到“长期无响应”“低优先级作业一直排队”等描述，就要联想到“饥饿”“公平”“老化”这些目标词。

2.2.2.4　面向整体效率的协同取舍

除了单点指标，调度还要实现不同资源之间的协同：CPU、I／O 设备与内存最好都“有活干”。因此，目标上会鼓励I／O 密集型与CPU 密集型任务的并行推进，以提升系统整体吞吐量和设备利用率；同时也希望上下文切换开销不过度膨胀，避免因频繁切换而把时间花在“换人不干活”上。换言之，调度既关注“选对人上场”，也关注“别老换人”。这些都是目标层面的取舍，具体如何达成留待后续实现与算法小节展开。

2.2.2.5　用目标指导算法选择的思路

面对具体场景，读者可以按“负载特征—系统类型—关键目标”的顺序筛选算法侧重：若题干强调“用户交互卡顿”，优先关注响应时间／可预测性；若强调“批量作业堆积”，优先关注吞吐量／平均周转时间；若出现“截止期”“定时任务”，自然转向按时完成与确定性。在此基础上，再考虑公平与避免饥饿的长期约束。记住：调度算法的“好坏”不是抽象的，而是相对于这一节明确的目标而言的。