嵌入式需避免new/delete，因其依赖不可靠的标准堆分配器，易导致分配时间不确定、内存碎片、实时性破坏及中断不安全；应采用静态内存池等确定性方案。
为什么嵌入式里要避免 new/delete
因为标准堆分配器（malloc/new）在资源受限设备上会引入不可预测的分配时间、内存碎片和运行时依赖。RTOS 或裸机环境通常禁用 libc 的堆实现，甚至链接时直接丢弃 __heap_start。固定块内存池绕过堆管理，所有内存预分配在编译期或启动时静态划定，后续只做指针偏移+位图/链表标记。
怎么用静态数组实现 FixedBlockAllocator
核心是把一块连续内存（比如 static uint8_t pool[4096]）切分为等长块，用自由链表管理空闲块。不依赖任何动态结构——链表节点就藏在每个空闲块头部。
- 每个块至少预留
sizeof(void*)空间存下一个空闲块地址（即“free list pointer”） - 块大小必须 ≥
sizeof(void*)，且对齐到目标平台最小对齐要求（常为 4 或 8 字节） - 初始化时遍历整个池，把每块首地址写入前一个块的指针域，串成单向链表；头指针指向第一块
-
allocate()取链表头，更新头指针为该块存储的下一个地址；deallocate(ptr)把ptr插回链表头
class FixedBlockAllocator {
static constexpr size_t BLOCK_SIZE = 64;
static constexpr size_t POOL_SIZE = 8192;
alignas(8) static uint8_t pool_[POOL_SIZE];
static void* free_list_;
<p>public:
static void init() {
free<em>list</em> = pool_;
uint8<em>t* p = pool</em>;
for (size_t i = 1; i < POOL_SIZE / BLOCK_SIZE; ++i) {
*reinterpret_cast<void*<em>>(p) = p + BLOCK_SIZE;
p += BLOCK_SIZE;
}
</em>reinterpret_cast<void**>(p - BLOCK_SIZE) = nullptr;
}</p><pre class='brush:php;toolbar:false;'>static void* allocate() {
if (!free_list_) return nullptr;
void* ptr = free_list_;
free_list_ = *reinterpret_cast<void**>(ptr);
return ptr;
}
static void deallocate(void* ptr) {
*reinterpret_cast<void**>(ptr) = free_list_;
free_list_ = ptr;
}};
如何防止多线程或中断重入破坏 free_list_
裸机或 RTOS 下，若分配器可能被 ISR 和任务同时调用，free_list_ 修改必须原子。不能靠 std::atomic（它可能隐含锁或依赖未启用的硬件特性），而应直接关中断或用 OS 提供的临界区 API。
立即学习“C++免费学习笔记（深入）”；
- ARM Cortex-M：用
__disable_irq()/__enable_irq()（CMSIS）包裹allocate/deallocate关键段 - FreeRTOS：用
taskENTER_CRITICAL()/taskEXIT_CRITICAL() - 切勿在中断里调用未加保护的分配器——即使关了中断，也要注意嵌套中断场景（需检查是否已处于临界区）
为什么不能直接用 std::pmr::monotonic_buffer_resource
std::pmr::monotonic_buffer_resource 是单向分配器，不支持 deallocate 任意块，只支持整体重置。它适合短生命周期、批量申请后统一释放的场景（如帧内临时对象），但不符合“无堆动态内存池”的核心诉求：即精确回收、重复利用单个块。
另外，std::pmr 依赖 std::memory_resource 抽象层，在多数嵌入式工具链（如 arm-none-eabi-g++ 默认配置）中未启用或缺少底层支持，链接时常报 undefined reference to 'operator new(unsigned long, std::nothrow_t const&) 类错误。
真正关键的是：你得亲手控制每一块内存的生命周期，而不是交给抽象层猜你的意图。
