MLFQ不能只靠固定时间片轮转，因其核心是进程行为驱动的优先级漂移；固定时间片会导致短任务反复降级、响应变差，必须通过动态调整逻辑（如等待时间阈值提升、突发时间加权平均判断I/O密集型）实现精准调度。
为什么 multilevel_feedback_queue 不能只靠固定时间片轮转
多级反馈队列（MLFQ）的核心不是“多级”本身，而是「进程行为驱动的优先级漂移」。如果每级都用固定时间片（比如 Level 0：10ms，Level 1：20ms），新进程一进来就进最高优先级队列，但一旦被抢占就降级，会导致短任务反复降级又升不回来——fork() 后的子进程、交互式 GUI 线程会迅速沉底，响应变差。
真正关键的是动态调整逻辑：运行越短、等待越久、I/O 越频繁，越该被“托举”。实操中必须做到：
-
boost_priority()每隔一定调度周期（如 100ms）扫描所有就绪进程，对wait_time > 2 * avg_wait_time的进程强制提升一级（但不超过初始等级） - 每次从就绪队列取进程前，先调用
update_priority_based_on_burst_history()，用最近 3 次 CPU 突发时间加权平均值反推“是否为 I/O 密集型”——若avg_burst 且 <code>last_io_time > now - 50ms，则重置到 Level 0 - 禁止跨级跳跃：从 Level 2 降级只能到 Level 3，不能直接扔进 Level 5；升权也只允许 +1，避免抖动
std::priority_queue 无法直接支撑 MLFQ 的层级跳转需求
C++ 标准库的 std::priority_queue 是单层堆，不支持按需把某个元素从 Level 2 移到 Level 0，也不支持按插入顺序遍历同一级内的进程。硬套会导致你不得不每次降级都重建整个队列，O(n log n) 开销爆炸。
正确做法是分层存储 + 手动索引：
立即学习“C++免费学习笔记（深入）”；
- 用
std::vector<:queue>></:queue>表示 5 级队列，每级一个 FIFO 队列（保证同级先进先出） - 维护一个全局
std::unordered_map<int int></int>记录每个pid当前所在 level（避免遍历时逐级搜索） - 调度时从 Level 0 开始 scan：若
queues[level].empty()则 level++；否则取queues[level].front()，执行完再根据规则决定 push 到哪一级的尾部
注意：std::queue 不支持随机访问，所以别试图“把第 3 个进程提前”——MLFQ 本就不该支持这种操作，那是实时调度器干的事。
如何让 Process 结构体同时承载静态配置与动态状态
很多初版实现把优先级、剩余时间片、历史突发时间全塞进一个结构体，结果一调度就改得面目全非，调试时分不清哪个字段是初始化值、哪个是当前快照。
推荐拆成两层：
- 静态部分（构造时定死）：
pid、init_level、arrival_time、total_cpu_time（总需 CPU 时间） - 动态部分（调度中持续更新）：
current_level、remaining_time_slice、last_run_end、burst_history[3]（循环数组存最近三次 CPU 使用时长）
关键细节：remaining_time_slice 必须在每次进入某级队列时重置，而不是继承上一级的残值。例如从 Level 1（时间片 20ms）降级到 Level 2（时间片 40ms），要设为 40，不是继续用剩下的 12ms。
模拟器里最容易被忽略的「时钟推进」陷阱
真实 OS 有硬件定时器中断，但模拟器没有。如果你写 while (!all_finished) { schedule_one_round(); }，那所有进程都在零时间完成，wait_time 全是 0，优先级永远不变化。
必须显式建模时间流逝：
- 维护全局变量
global_clock（类型long long，单位 ms） - 每次取出一个进程
p后，先做global_clock += std::min(p.remaining_time_slice, p.remain_cpu) - 然后更新
p.wait_time = global_clock - p.last_run_end - p.remaining_time_slice（注意：不是 arrival_time） - I/O 事件触发时（比如键盘输入），也要推进时钟：假设 I/O 延迟 15ms，则
global_clock += 15，并把对应进程唤醒后插回对应 level 队列
这个时钟推进逻辑一旦漏掉或错位，整个动态优先级机制就失效——你会看到所有进程卡在 Level 4 不动，因为 wait_time 始终算不准。
