全局重载 operator new/delete 在嵌入式中不可靠，因裸机/RTOS 常无完整 libc 且编译器可能绕过重载；必须结合类成员重载、全签名覆盖、对齐支持与线程安全内存池才能确保所有分配受控。
为什么全局重载 operator new 和 operator delete 在嵌入式里不直接管用
嵌入式环境下，new 和 delete 默认调用的底层分配器（比如 malloc/free）往往依赖 libc 的堆管理，而很多裸机或 RTOS 环境压根没完整 libc，或者堆不可靠、不可预测。更关键的是：C++ 标准允许编译器在某些场景下绕过重载的全局 operator new —— 比如 placement new、静态对象构造、甚至部分模板实例化内部的临时对象分配，都可能走默认路径。
所以单纯重载全局版本，不能保证所有 new 都落到你的内存池上；必须同时控制类粒度和链接时行为。
怎么让某个类的所有 new 都强制走内存池
给类显式声明成员版 operator new 和 operator delete 是最可靠的方式。编译器遇到 new MyClass 时，优先查找类内定义，找不到才查全局。
- 必须成对定义：只要重载了
operator new，就得提供匹配的operator delete，否则析构后内存无法正确回收 - 推荐使用
noexcept版本：嵌入式不允许异常传播，void* MyClass::operator new(size_t sz) noexcept更安全 - 内存池分配失败应返回
nullptr（而非抛异常），并确保调用方检查——C++11 起new默认是“throwing”，但成员重载不受此限 - 示例：
class SensorData { public: void* operator new(size_t sz) noexcept { return mempool_alloc(sz); // 假设你有这个函数 } void operator delete(void* ptr) noexcept { if (ptr) mempool_free(ptr); } };
全局重载仍然有必要，但得避开常见陷阱
全局重载不是为了“兜底”，而是为了捕获那些没显式指定类、又确实需要统一管控的分配，比如 STL 容器（如果你用了 std::vector 等）或第三方库里的动态分配。
立即学习“C++免费学习笔记（深入）”；
- 必须重载全部四种子签名：
operator new/operator delete（普通版）、operator new[]/operator delete[]（数组版），否则数组new会调用默认malloc - 不要在全局
operator new里调用std::abort()或死循环——嵌入式系统需要可预测的 fail-fast 行为，返回nullptr并由上层处理更合适 - 链接顺序很重要：确保你的重载定义在链接时优先于 libc 的实现。GCC 下可用
-Wl,--undefined=operator new强制解析，或把重载代码放在最前面的 object 文件中 - 注意
placement new不可重载：它只是个语法糖，不会调用任何operator new，所以无需也**不能**重载它
内存池本身要注意对齐和线程安全
嵌入式里 new 分配的对象可能含 double、SIMD 类型或硬件寄存器映射结构体，对齐不足会导致硬故障。
- 内存池分配函数（如
mempool_alloc）必须支持按需对齐：C++17 起operator new第二参数是std::align_val_t，需重载带该参数的版本：void* operator new(size_t, std::align_val_t) - 如果多个中断或任务可能并发调用
new，内存池内部必须加临界区保护（比如关中断、用互斥量），但要注意互斥量本身是否依赖动态分配——建议用静态初始化的FreeRTOSStaticSemaphore_t或裸机自旋锁 - 避免碎片：固定块内存池比动态分割更可控；若用 slab 分配，确保块大小覆盖常用对象尺寸（如 32B/64B/128B），并预留少量“大块”应对例外
真正难的不是写几行 operator new，而是确认每个 new 调用路径都落在你的控制之下——包括编译器生成的临时对象、模板元编程触发的隐式分配、以及链接进来的静态库代码。动手前，先用 nm -C your.elf | grep 'new' 检查符号绑定是否如你预期。
