经过上一节的讨论之后，我们期望解决两个方向的问题
- optimize turnaround time: 尽管我们知道SJF是最优解，但是现实中我们无法知道一个任务要运行多久
- optimize response time: RR虽然可以优化响应时间，但代价是周转时间很长。
MLFQ维护了多个队列，每个队列拥有不同的优先级priority level, 每个处于就绪态的任务都被放到某个队列之中。
MLFQ的基本规则
- Rule 1: If priority(A) > priority(B), A runs while B doesn't. 当较高优先级的队列中有任务时，优先级高的先运行。
- Rule 2: IF priority(A) == priority(B), A & N run in RR. 同一个优先级队列内的任务依照时间片轮转运行。
在MLFQ中，每个任务的优先级会发生变化。例如，如果一个任务经常发出IO请求并放弃CPU, 则其会被维持在较高优先级；如果一个任务经常在时间片内调用CPU做大量计算，则其优先级可能被降低。总的来说，MLFQ试图在运行过程中学习各个任务的特点。
- Rule 3: 当一个任务进入系统，它被放入最高优先级的队列
- Rule 4a: 如果一个任务用尽了分配给它的时间片，则它的优先级被降低，即放入下一个队列的队尾
- Rule 4b: 如果一个任务在用尽时间片之前放弃了CPU, 则它的优先级不变，放入当前队列的队尾
到目前为止上面几条规则仍然存在问题，
- starvation饥饿：如果不断有高优先级的任务到来，则处于低优先级队列的任务很难有机会得到运行。
- 系统的用户可能通过某些技巧欺骗操作系统，使其自身始终处于优先级较高的队列。
- 一个任务的行为可能会随时间发生变化，因此MLFQ所认为的任务的特征可能不准确。
- Rule 5: 每经过一个周期S，将所有任务都提升到最高优先级的队列。
上面提到，用户可能通过一些技巧把自身保留在较高优先级，例如频繁发出IO请求。为了防范这样的情况，我们需要更准确地描述一个任务对于CPU的使用率，
- Rule 4: 如果一个任务使用CPU的总时间相对于分配给它的总时间的比例高于某个值，则它的优先级会被降低。 这样的统计方法需要记住一个任务一直以来的CPU使用情况，而不是仅仅一次时间片运行中的CPU使用情况。
上面几条规则只能描述MLFQ的原理，但具体的实现则需要很多其它信息和参数。例如，应该维护几条队列？每条队列对应的时间片应该各为多少？Priority Boost一个间隔多久进行？
各个操作系统可能会有不同的参数，在规则上可能略有不同，但总的来说思路是一致的。
- 高优先级队列中的任务优先运行
- 同一个优先级队列中的任务按照时间片轮转运行，各个队列的时间片长度可能不同
- 但一个任务到达系统中，会被放到可能的最高优先级队列（有些系统把真正的最高优先级保留给了内核）
- 如果一个任务使用的总CPU时间占据分配的总时间片的比例超越一定的值，则该任务优先级会被降低
- 每间隔一个周期S，队列中的所有任务都会被提升到最高优先级。