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>></:queue> 管理 4–5 个队列，每个队列内 FIFO，队列间按索引序优先调度。
Process 结构体必须携带哪些字段
仅存 pid 和 burst_time 不够。模拟中要判断是否该降级、是否该提升、是否已完成，需要：
立即学习“C++免费学习笔记（深入）”；
-
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<Process>>，共 4 层
for (int level = 0; level < queues.size(); ++level) {
if (!queues[level].empty()) {
Process& p = queues[level].front();
int quantum = get_quantum(level); // 如：8, 16, 32, 64
if (p.total_cpu_time + quantum >= 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 < queues.size()) {
p.current_queue_level = level + 1;
p.time_in_queue = 0; // 进入新队列，等待时间重置
queues[level + 1].push(p);
} else {
queues.back().push(p); // 最底层不再降级
}
}
break; // 每 tick 只调度一个进程
}
}
关键点：get_quantum(level) 必须随 level 严格递增；降级前要检查 level + 1 是否越界；break 不可省略，否则破坏“高优队列优先”的本质。
如何模拟“长时间等待自动提升”
这是最容易被忽略的环节。很多实现只做降级不做提升，导致交互式进程永远沉底。标准 MLFQ 要求：每隔一定系统时间（如 50 tick），扫描所有就绪进程，将 time_in_queue >= 50 的进程提到更高队列（通常提回 level 0 或 level 1）。
- 不能在调度主循环里每次 tick 都扫全量——性能爆炸
- 推荐用“懒提升”：只在每次准备从空队列向下查时，触发一次提升检查
- 提升后记得重置
time_in_queue，否则下次又立刻再提
例如，在进入 level = 1 前插入：
if (queues[0].empty() && need_boost_check()) {
boost_all_waiting_processes(); // 将所有 time_in_queue >= BOOST_THRESHOLD 的进程移到 level 0
}
真实系统中这个提升周期常设为几十到几百毫秒；模拟中设为 30–50 tick 较合理，太短会削弱优先级区分度，太长会让短作业饿死。
真正难的不是写完四个队列的 push/pop，而是让「降级时机」「提升触发条件」「时间片计算」三者咬合严丝合缝——差一个 或漏一次 <code>time_in_queue 重置，整个调度行为就会偏离 MLFQ 本意。
