MLFQ不能只用一个std::priority_queue，因其无法支持队列分层、动态迁移及批量优先级调整；需用std::vector管理多个FIFO队列，并在Process中维护current_queue_level、time_in_queue、total_cpu_time和last_run_tick字段。
多级反馈队列（MLFQ）调度在 C++ 中不是开箱即用的功能，必须手动建模时间片轮转、优先级降级、队列提升等行为；直接套用 std::priority_queue 会失效，因为它不支持动态调整元素优先级，也不维护多个独立队列间的迁移逻辑。
为什么不能只用一个 std::priority_queue
MLFQ 的核心是「队列分层 + 动态迁移」：高优先级队列时间片短、不抢占低优先级队列运行中的进程，但若进程用完时间片就降级到下一级；而长时间等待的进程需被提升（如每过 1 秒所有就绪进程升一级）。std::priority_queue 是静态堆，无法：
- 对某个特定进程快速找到并修改其当前所在队列层级
- 批量将一批进程从第 2 队列移到第 1 队列（提升）
- 在调度循环中按队列索引顺序遍历（第 0 队列 > 第 1 队列 > …）
正确做法是用 std::vector<:queue>> 管理 4–5 个队列，每个队列内 FIFO，队列间按索引序优先调度。
Process 结构体必须携带哪些字段
仅存 pid 和 burst_time 不够。模拟中要判断是否该降级、是否该提升、是否已完成，需要：
-
int current_queue_level：当前所处队列编号（0 最高） -
int time_in_queue：在当前队列已等待的时间（用于超时提升） -
int total_cpu_time：已获得的 CPU 时间总和（用于判断是否用完 burst） -
int last_run_tick：上一次被调度执行的系统 tick（用于计算响应时间、周转时间）
注意：burst_time 是只读的原始需求值，不能被修改；所有运行进度用 total_cpu_time 累加，否则无法复现“I/O 后返回时重置时间片但保留优先级”的语义。
时间片分配与降级逻辑怎么写才不出错
常见错误是把“时间片耗尽”和“进程主动阻塞（如 I/O）”混为一谈。MLFQ 规则明确：只有被调度后运行满时间片才降级；若进程在队列里没轮到就发生 I/O，则它留在原队列、不降级、不重置 time_in_queue。
典型实现节选：
// 假设 queues 是 vector<queue>>，共 4 层
for (int level = 0; level = p.burst_time) {
// 本次执行就能完成
p.total_cpu_time = p.burst_time;
// 完成，不入任何队列，记录 finish_tick
record_finish(p);
} else {
// 执行一个时间片后未完成 → 降级
p.total_cpu_time += quantum;
queues[level].pop();
if (level + 1 <p>关键点：<code>get_quantum(level)</code> 必须随 level 严格递增；降级前要检查 <code>level + 1</code> 是否越界；<code>break</code> 不可省略，否则破坏“高优队列优先”的本质。</p>
<h3>如何模拟“长时间等待自动提升”</h3>
<p>这是最容易被忽略的环节。很多实现只做降级不做提升，导致交互式进程永远沉底。标准 MLFQ 要求：每隔一定系统时间（如 50 tick），扫描所有就绪进程，将 <code>time_in_queue >= 50</code> 的进程提到更高队列（通常提回 level 0 或 level 1）。</p>
<ul>
<li>不能在调度主循环里每次 tick 都扫全量——性能爆炸</li>
<li>推荐用“懒提升”：只在每次准备从空队列向下查时，触发一次提升检查</li>
<li>提升后记得重置 <code>time_in_queue</code>，否则下次又立刻再提</li>
</ul>
<p>例如，在进入 <code>level = 1</code> 前插入：</p>
<pre class="brush:php;toolbar:false;">
if (queues[0].empty() && need_boost_check()) {
boost_all_waiting_processes(); // 将所有 time_in_queue >= BOOST_THRESHOLD 的进程移到 level 0
}
真实系统中这个提升周期常设为几十到几百毫秒；模拟中设为 30–50 tick 较合理，太短会削弱优先级区分度，太长会让短作业饿死。
真正难的不是写完四个队列的 push/pop，而是让「降级时机」「提升触发条件」「时间片计算」三者咬合严丝合缝——差一个 或漏一次 time_in_queue 重置，整个调度行为就会偏离 MLFQ 本意。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
