不能直接用new/delete实现自定义堆管理器，因其底层仍依赖malloc/free或系统调用，无法绕过默认堆；真正可控的起点是placement new配合手动管理内存块，需维护空闲链表、处理对齐、元数据及多线程安全。
为什么不能直接用 new/delete 实现自定义堆管理器
因为 new 和 delete 底层仍依赖 malloc/free 或系统调用（如 mmap），无法绕过默认堆；想真正控制内存布局、分配策略、碎片整理，必须从更底层入手——比如直接向操作系统申请大块内存页，再在用户态切分管理。
常见错误是试图用 new char[size] 分配一块“池”，然后用指针手动偏移模拟分配，但这样无法处理对齐、元数据存储、多线程竞争等问题，极易崩溃或泄漏。
- 真正可控的起点是
operator new(size_t, void*)（placement new）配合自管内存块 - 需要自己维护空闲链表或位图，记录哪段可用、哪段已分配
- 所有分配返回的指针，其指向地址必须满足最严格对齐要求（通常是
alignof(std::max_align_t)）
如何用指针管理内存块并实现首次适配分配
核心是把一大块连续内存（比如 1MB）看作字节数组，用指针算术 + 头部元数据做链表节点。每个已分配块头部存一个 size_t 表示大小，空闲块额外存一个指向下一个空闲块的指针。
struct FreeBlock {
size_t size;
FreeBlock* next;
};分配时遍历空闲链表，找第一个 size >= requested + sizeof(FreeBlock) 的块，拆分（若剩余空间足够塞下新空闲头），更新指针：
立即学习“C++免费学习笔记（深入）”；
- 原空闲块的
next指针要重定向，不能只改局部变量 - 拆分后新空闲块的
size要减去已分配部分和自身头部，否则下次会误判可用空间 - 返回的指针必须跳过头部：
return reinterpret_cast<char>(block) + sizeof(FreeBlock)</char>
释放时怎么靠指针反推块头并合并相邻空闲块
释放函数接收的是用户使用的指针（比如 p），必须能反算出它前面的 FreeBlock*。这要求分配时返回的指针严格基于块头偏移，且不被用户修改。
典型做法：释放时用 reinterpret_cast<freeblock>(static_cast<char>(p) - sizeof(FreeBlock))</char></freeblock> 回溯。但前提是分配逻辑始终保证这个偏移成立——如果用了自定义对齐（如 16 字节对齐），头部可能不是紧贴前缘，此时需额外存储偏移量或用固定对齐策略。
- 合并仅检查物理相邻：当前块末地址是否等于下一空闲块起始地址，或前一空闲块末地址是否等于当前块起始地址
- 合并时要修正链表指针，尤其注意是否为链表头节点，避免悬空
head - 未合并的块插入空闲链表时，建议按地址排序，方便后续合并判断
多线程下指针操作为何容易出错及简单防护
多个线程同时修改同一个 FreeBlock* head 或遍历/修改链表，会导致指针被覆盖、跳过节点、双重释放。单纯加锁整个分配器性能差，但用原子指针（std::atomic<freeblock></freeblock>）又不能直接原子地更新 head->next。
推荐做法是把全局空闲链表拆成每线程本地缓存（TLS），定期与中心链表同步；或者用 CAS 循环重试更新头指针：
FreeBlock* expected = head.load();
while (!head.compare_exchange_weak(expected, new_head)) {
// 重试
}- 不要在临界区里做复杂计算（如遍历查找），只做指针交换和简单字段更新
- 释放时若发现目标块与本地缓存块地址连续，优先合并进 TLS，减少中心锁争用
- 所有指针运算必须用
char*或uintptr_t转换，避免有符号溢出或平台指针宽度差异
真正难的不是写通逻辑，而是让所有指针偏移、对齐、元数据布局在不同编译器、不同 STL 实现下都稳定——建议先禁用异常、RTTI，用 -fno-rtti -fno-exceptions 编译，并显式校验 alignof 和 sizeof。
