MLFQ不能只靠静态优先级数组实现，因其核心是动态优先级：需根据运行时间、I/O行为、等待时长实时调整进程队列层级；固定数组无法响应这些变化，易致饥饿或延迟。
为什么 multilevel_feedback_queue 不能只靠静态优先级数组实现
多级反馈队列（MLFQ）的核心是“动态优先级”——进程在高优先级队列运行后被降级，I/O等待后可回退，长时间未调度的进程还会被提升。如果用固定数组存优先级（比如 priority[5]），就无法响应运行时行为变化，容易导致饥饿或响应延迟。
真实模拟必须跟踪每个进程的：当前队列层级、在该队列已运行时间、是否刚完成 I/O、上次被调度时间。这些状态决定了下一次调度前要不要迁移队列。
-
std::vector<:queue>></:queue>存各层就绪队列，索引 0 是最高优先级 - 每个
Process结构体里加current_level和time_in_current_level字段 - 每次
tick()更新时检查：若time_in_current_level >= quantum[level]，则移到下一级（除非已是最低级）
如何正确处理 I/O 事件触发的优先级回退
用户常误以为“只要进程发起 I/O 就立刻升到最高级”，但标准 MLFQ 规则是：仅当进程因 I/O 阻塞而主动让出 CPU（非时间片用完），且它之前在较低层运行，才考虑提升——否则会破坏公平性。
关键判断逻辑在 handle_io_event() 中：
立即学习“C++免费学习笔记（深入）”；
- 先将进程从当前就绪队列移出，加入
blocked_queue - 记录
last_io_time = current_tick - 当它从阻塞恢复时，检查
current_level > 0 && last_io_time > last_scheduled_time，才重置为 level 0 - 注意：不能无条件提升，否则 CPU 密集型进程伪造 I/O（如频繁
sleep(1)）就能长期霸占高优队列
std::priority_queue 不适合做 MLFQ 的就绪队列
很多初学者用 std::priority_queue<process std::vector>, CompareByPriority></process> 来模拟多级队列，结果发现无法按时间片轮转、无法批量迁移进程、无法快速定位某一层的所有进程。
根本原因：std::priority_queue 是堆结构，只保证 top() 最大/最小，不提供遍历、分层访问或按条件批量操作的能力。
- 正确做法是用
std::vector<:queue>></:queue>—— 每层一个 FIFO 队列，调度器从 level 0 开始扫描，取 front() 执行 - 需要“抢占式”时，在
tick()中检查当前运行进程是否超时，超时就 pop 并 push 到下一层队尾 - 若某层为空，直接跳过，不需重建堆或重排序
时间片（quantum）设置不当会导致吞吐量骤降
常见错误是给每层都设相同 quantum，比如全设为 4ms。这会让 MLFQ 退化成普通 RR，失去对短作业友好、长作业不饿死的优势。
典型配置应呈指数衰减（越低优先级，时间片越大）：
- level 0:
quantum = 2（响应交互式任务） - level 1:
quantum = 4 - level 2:
quantum = 8 - level 3+:
quantum = 16或改用 FCFS（避免过度切上下文）
实测中，若 level 0 的 quantum 超过 5，键盘输入延迟就会明显可感；若 level 3 的 quantum 小于 10，编译类长任务的上下文切换开销占比会超过 12%。
动态调整比固定值更稳：可让 quantum[level] = base_quantum * (1 ，再配合老化机制（每隔 100 tick 把所有进程 <code>current_level 重置为 max(0, current_level - 1)）防饥饿。
