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　用目標指導算法選擇的思路

面對具體場景，讀者可以按“負載特征—系統類型—關鍵目標”的順序篩選算法側重：若題干強調“用戶交互卡頓”，優先關注響應時間／可預測性；若強調“批量作業堆積”，優先關注吞吐量／平均周轉時間；若出現“截止期”“定時任務”，自然轉向按時完成與確定性。在此基礎上，再考慮公平與避免饑餓的長期約束。記住：調度算法的“好壞”不是抽象的，而是相對于這一節明確的目標而言的。