首次适应法要求空闲区链表按地址升序排列，分配时从头找首个size≥请求大小的块，回收时需检查并合并前后相邻空闲块；FreeMem仅存Start_Address和size，AllocMem存Start_Address、size和processID，链表用std::list以保证O(1)增删。
首次适应法（First Fit）在 C++ 中不是调用现成库函数，而是必须自己组织空闲区链表并手动遍历 —— 你不能靠 malloc 或 new 来模拟系统级分配逻辑，否则就失去了实验意义。
为什么不能直接用 std::list 存裸地址和大小就完事
因为回收时必须能合并相邻空闲块，而仅存地址+大小无法判断“是否相邻”：比如一块空闲区结束于 0x1000，下一块起始是 0x1000，它们才真正连续。所以每个空闲节点必须显式记录 Start_Address 和 size，且插入/删除时要检查 Start_Address + size == next->Start_Address 这类等式。
常见错误是把空闲链表按大小排序（那是最佳适应），或漏掉回收后向前/向后合并的判断分支。
- 首次适应要求链表按地址升序排列，不是按大小
- 分配时从头开始找第一个
size >= request_size的节点 - 若剩余空间 ≤ 阈值（如
minsize = 4KB），不切割，整块分配；否则拆成两块，后半段保留在链表中 - 回收时先插入新空闲节点，再依次检查它与前驱、后继能否合并 —— 顺序不能反，否则指针失效
FreeMem 和 AllocMem 结构体怎么设计才不出错
结构体里不要存冗余字段，比如不需要 end_address（可由 Start_Address + size 算出），否则更新一处忘了另一处，状态就错乱。重点保留可验证关系：
立即学习“C++免费学习笔记（深入）”；
-
FreeMem只需Start_Address和size，构造时做断言：size > 0 -
AllocMem需要Start_Address、size、processID，但不用存“是否已分配”标志 —— 它天然在Allocted_List里就代表已分配 - 两个链表都用
std::list，别用vector：频繁插入删除时list是 O(1)，vector是 O(n)
示例片段（关键判断）：
auto it = Free_List.begin();
while (it != Free_List.end()) {
if (it->size >= request_size) {
// 找到首个满足条件的
break;
}
++it;
}
if (it == Free_List.end()) return false; // 分配失败
回收时合并逻辑最容易漏掉的三种情况
回收一个刚释放的内存块，它可能和前面一块、后面一块、或前后两块都空闲 —— 这三种情况必须分开处理，不能只写一个 if。
- 前面空闲：
prev_it->Start_Address + prev_it->size == new_block.Start_Address - 后面空闲：
new_block.Start_Address + new_block.size == next_it->Start_Address - 前后都空闲：先合并前驱，再用合并后的新节点去比对后继（注意迭代器失效！）
- 合并后要从链表中 erase 被吞掉的节点，且确保
erase不导致后续迭代器失效
典型坑：用 std::list::erase(it++) 写法在合并多块时跳过某个节点，结果碎片没清干净。
调试时怎么看分配是否真符合首次适应规则
最简单办法：每次分配前打印整个 Free_List，按 Start_Address 排序后逐行看。如果申请 50KB，而第一个地址最低、大小 ≥50KB 的空闲块是起始于 0x2000 的 80KB 块，那它就必须被选中 —— 即使后面有更紧凑的 55KB 块在 0x5000。
输出格式建议固定列宽，例如：
[Free] 0x0000: 120KB [Free] 0x0078: 40KB ← 0x78 = 120 十进制，说明紧接上一块 [Free] 0x00a0: 60KB
这样一眼能看出地址连续性，也方便验证合并是否生效。
真正难的不是写对单次分配，而是让多次分配+回收+合并之后，链表始终维持地址有序、无重叠、无间隙（除真实碎片外）—— 这需要每一步操作后都做链表自检，比如遍历检查 it->Start_Address + it->size Start_Address。
