为什么round robin（RR）算法不适用于作业调度，仅适用于进程调度？

首先明确两类调度的核心差异，再分析RR不适用的根本原因：

• 作业调度（长程调度）：调度对象是外存后备队列中的完整作业，作用是筛选符合条件的作业调入内存、创建对应进程后移交进程调度处理，调度频次极低，通常几秒到几分钟才会触发一次，作业一旦调入内存会驻留直到整体运行结束。
• 进程调度（短程调度）：调度对象是内存中的就绪进程，作用是给进程分配CPU执行权限，调度频次极高，通常几十到几百毫秒就会触发一次，进程用完时间片就会让出CPU回到就绪队列。

核心原因1：RR的时间片机制与作业调度的运行逻辑完全不兼容 #

RR算法的核心设计是给每个调度单元分配固定长度的时间片，时间片耗尽后强制抢占CPU切换到下一个单元。如果把这套逻辑套用到作业调度上，就要求作业运行一个时间片后就被换出到外存、切换下一个作业调入内存，这种内存<->外存的上下文切换开销是完全不可接受的：GB级的作业数据换入换出耗时通常是秒级甚至分钟级，远高于RR常规的毫秒级时间片长度，会导致系统99%的资源都浪费在作业切换上，吞吐量直接暴跌到不可用的程度。

核心原因2：RR的设计目标和作业调度的核心诉求相悖 #

作业调度的核心目标是提升系统整体吞吐量、降低作业平均周转时间，会优先调度短作业、IO密集型作业或者高优先级作业，尽可能让更多作业更快完成。而RR的设计目标是保障所有调度单元的公平性，不区分作业长度、类型、优先级，所有作业均匀分配调度机会，用在作业调度场景会导致大量短作业被长作业阻塞，作业平均周转时间飙升，完全无法满足作业调度的性能要求。

补充说明 #

RR并非完全不可能用于作业调度，只是在通用操作系统、传统批处理系统的标准实现中，RR带来的收益远低于其产生的性能损耗，所以不会被采用。部分对公平性要求远高于吞吐量的特殊定制批处理场景，也存在类RR的作业调度实现，但不属于通用方案。

内容的提问来源于stack exchange，提问作者Yanshihang