第0级队列时间片最短是为了保障交互式任务低延迟响应；若过大则退化为轮转调度，丧失反馈机制，通常设1–4ms并逐级翻倍，且须依负载动态调整。
多级反馈队列中，为什么第 0 级队列的时间片必须最短？
因为第 0 级是最高优先级队列，目标是快速响应交互式任务；如果它的时间片过大，就会退化成轮转调度，失去“反馈”意义——新进程或刚唤醒的进程进第 0 级，若被卡住执行 100ms，就违背了低延迟初衷。
实际设定时，time_slice[0] 通常取 1–4ms（取决于系统精度），后续每级翻倍：time_slice[i] = time_slice[i-1] * 2。注意：不是固定写死为 1, 2, 4, 8，而应根据实测负载调整，比如高吞吐场景可设为 2, 4, 8, 16，避免第 0 级过于激进导致上下文切换爆炸。
- Linux 的 CFS 不用时间片，但 MFQ 必须显式管理，否则无法触发降级
- 若某级队列为空，调度器必须跳过，不能阻塞等待——检查
queues[i].empty()再进入下一级 - 时间片单位统一用
int（毫秒），避免浮点运算和std::chrono在嵌入式或教学环境引发编译/链接问题
进程降级逻辑：什么条件下从 queue[i] 移到 queue[i+1]？
仅当进程在当前队列耗尽其分配的时间片仍未完成时，才降级。关键点在于：**不是每次调度都降，也不是按等待时间降，而是按 CPU 使用量降**。
实现上，每个 Process 结构体需记录 remaining_time 和 current_queue_level；每次从队列取出后，用 std::min(remaining_time, time_slice[level]) 做本次执行时长，再更新 remaining_time -= executed。若 remaining_time > 0，则 push 到 queues[level + 1]（前提是未超最大级数）。
- 错误做法：把“就绪态等待超时”当作降级条件——MFQ 不看等待时间，只看 CPU 执行是否用完配额
- 边界处理：若
level == MAX_LEVEL - 1且仍没完成，应留在最后一级继续轮转，而非丢弃或报错 - 避免重复入队：降级前先从原队列
pop（用 list::erase 或 queue 模拟时需用索引/迭代器安全移除）
如何让优先级“动态”但不破坏队列层级语义？
MFQ 本身不维护传统意义上的“优先级数值”，层级号 level 就是动态优先级：数字越小，优先级越高。所谓“动态”，体现在两个动作：
- 新进程始终进入
queue[0]—— 这是最高优先级入场券 - 被 I/O 中断唤醒的进程，也应回到
queue[0]（体现“交互性奖励”），而不是回到原级 - 长时间运行但未完成的进程，逐级下沉 —— 这是“惩罚”
不要给每个进程加 priority_score 字段再排序，那会混淆模型。真正的动态性来自入队位置决策，而非数值比较。示例片段：
if (p.state == READY && p.was_woken_by_io) {
queues[0].push(p); // 唤醒即重置优先级
} else if (p.remaining_time > 0) {
int next = std::min(p.current_level + 1, MAX_LEVEL - 1);
queues[next].push(p);
}
std::queue 不够用：为什么必须用 std::list 或自定义容器？
std::queue 底层默认是 std::deque，只支持头出尾进，无法在中间查找、删除指定进程（比如某进程因 I/O 完成需提前唤醒并插回第 0 级）。而真实调度中，必须支持：
- 按 PID 查找并移除某个等待中的进程（I/O 完成回调）
- 将刚唤醒的进程插入第 0 级队首（非尾部），以抢占下一周期
- 遍历某级队列统计平均等待时间（调试/监控用）
所以推荐用 std::list<process></process> 存每级队列，用 std::vector<:list>></:list> 管理多级。插入队首用 queues[0].push_front(p)，查找用 std::find_if 配合 lambda，删除用 erase 迭代器——这些操作 std::queue 根本不提供。
别为了“看起来像队列”而硬套 std::queue，MFQ 的每一级本质是可随机访问的等待池，不是 FIFO 黑盒。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
