C 的 placement new 是一个容易被低估的特性。很多人第一次见到它是在内存池、嵌入式代码或者某些高性能库的源码里new (ptr) T(...)这种写法看起来只是把参数换了个位置实则把new的两步语义——分配内存和构造对象——彻底拆开了。不过市面上多数资料讲到void*这个标准版本就收尾了很少提到标题里说的“扩展语法”通过重载operator new你可以让new表达式带上自己的参数在任意指定的内存来源上构造对象。这篇文章就专门聊这份扩展语法从标准形态讲到自定义重载再落到内存池实战和排错经验适合已经在写 C、想更进一步控制对象生命周期和内存布局的人。1. placement new 的标准形态它拆开的究竟是哪两步1.1 两个入门的标准版本void* 与 nothrow先看第一个标准版本也是大家最熟悉的形式#include new #include iostream struct Point { int x, y; }; int main() { // 在已有缓冲区中构造 Point返回指向新构造对象的指针 alignas(Point) unsigned char buf[sizeof(Point)]; Point* p new (buf) Point{1, 2}; std::cout p-x , p-y \n; // placement new 没有对应的 placement delete必须手动析构 p-~Point(); }这段代码背后发生了什么new (buf) Point{1,2}这个表达式的处理可以拆成两步调用operator new(sizeof(Point), buf)。在返回的地址上调用Point的构造函数。标准库在new头文件里提供了void* operator new(std::size_t, void*) noexcept; void* operator new[](std::size_t, void*) noexcept;void*版本只是原样返回第二个参数不做任何内存分配也不对齐、不检查容量。所以它本质上不是“分配器”而是“构造器”。第二个标准版本是nothrowint* q new (std::nothrow) int(42); if (!q) { // 内存分配失败时返回 nullptr而不是抛 std::bad_alloc }从语法结构上看std::nothrow也是作为一个额外参数传入operator new(std::size_t, const std::nothrow_t)。它和void*版本一样共同点是都对应着标准库预置的operator new重载编译器在解析new表达式时会自动匹配到这些版本。1.2 拆开“分配”和“构造”意味着什么普通new表达式看起来是一步实际上也是两步1. 分配内存调用 operator new( sizeof(T) )可能抛 std::bad_alloc 2. 构造对象在分配好的内存上调用 T 的构造函数对应的delete表达式则是1. 析构对象调用 T 的析构函数 2. 释放内存调用 operator delete( void* )placement new 的作用就是把步骤 1 里的“分配内存”换成了你准备好的地址。这个拆开带来的直接控制力是对象需要的存储空间可以来自任意来源。栈上的数组、静态区、共享内存、mmap 映射的区域、DMA 缓冲区甚至是你自己维护的一个固定块池统统可以。但很多人会忽略一个反直觉的事实new (buf) T(...)不能用delete p来回收。因为编译器无法知道你传入的buf是从哪里来的自然也谈不上该用什么方式释放。你只能手动调用析构函数再交给原来的存储所有者处理。这一条是整个扩展语法的基础后面讲重载时也绕不开它。2. 扩展语法的核心机制operator new 重载才是真正的入口2.1 new 表达式中的参数是怎么被解析的标题里的“扩展语法”指的不只是标准库提供的两个operator new重载而是 C 允许你自己定义带任意额外参数的operator new。这个能力经常被忽略却非常强大。看一个简单的例子。假设你在开发一个游戏服务端需要频繁创建和销毁小型玩家对象不希望每次都走malloc/free所以准备了一个 arena。你可以在类里定义自己的 placement 重载#include cstddef #include new #include stdexcept class Arena { public: void* alloc(std::size_t size) { // 这里简单示例实际会从一块大内存里偏移分配 if (size capacity_) { throw std::bad_alloc(); } void* p reinterpret_castvoid*(memory_ offset_); offset_ size; return p; } void dealloc(void*) noexcept { // arena 的释放通常是一次性全部回收这里不做事 } private: alignas(std::max_align_t) unsigned char memory_[4096]; std::size_t offset_ 0; std::size_t capacity_ 4096; }; struct Actor { int hp 100; int x 0; int y 0; // 两个关键重载 static void* operator new(std::size_t size, Arena arena) { return arena.alloc(size); } static void operator delete(void* p, Arena arena) noexcept { arena.dealloc(p); } }; int main() { Arena arena; Actor* a new (arena) Actor(); // 用完手动析构 a-~Actor(); }注意到new (arena) Actor()这个表达式了吗编译器会在这个类的作用域里查找operator new找到匹配的operator new(std::size_t, Arena)于是自动完成调用void* raw Actor::operator new(sizeof(Actor), arena); Actor* a new (raw) Actor();重载的规则其实很明确第一个参数必须是std::size_t编译器会传入sizeof(要构造的类型)。后面的参数可以任意用户把new (...)括号里写什么就按类型匹配什么。如果定义在类里它默认是静态成员函数即使你不写static也如此。全局重载也可以但影响面大一般不建议随便污染全局命名空间。2.2 常见扩展形态栈上、对齐、调试信息基于这个机制可以扩展出来的形态非常多。我实际用过的有三种。第一种栈上对象。标准new (buf) T(...)其实已经能实现栈上构造但如果你希望在栈上分配一个可变大小的临时对象写法可以组合alloca或者栈缓冲区。某些嵌入式环境会封装一个StackArena然后把new (stackArena) Task()用在中断上下文里因为那里不能安全调用malloc。第二种带对齐要求的内存。当类型有扩展对齐要求比如alignas(64)普通缓冲区根本不够用。你可以在重载里做对齐处理让调用方无感知struct alignas(64) CacheLineValue { int data; static void* operator new(std::size_t size, Arena arena) { return arena.allocAligned(size, 64); } static void operator delete(void*, Arena) noexcept {} };第三种调试信息。我维护过一段无人敢动的老代码里面有很多从自定义池里new出来的对象一旦池泄漏根本不知道是谁没归还。后来加了一个带源码位置的重载struct LeakChecked { static void* operator new(std::size_t size, const char* file, int line) { void* p ::operator new(size); std::cout alloc size at file : line \n; return p; } static void operator delete(void* p, const char*, int) noexcept { ::operator delete(p); } }; // 用法 auto* obj new (__FILE__, __LINE__) LeakChecked();这里__FILE__和__LINE__直接作为额外参数传进重载分配信息就自动带上了。如果要避免每次写这两个宏可以用宏把new包装一下不过宏里的逗号处理要小心我建议宁可多写几个字符也别滥用宏替换至少调试起来少一层魔法。2.3 和 allocator_traits、PMR 的关系看到这里你可能会问如果很多地方都要用自定义分配为什么不直接用标准分配器非得自己写 operator new其实两者并不冲突。标准库的std::allocator_traits::construct以及 C17 的std::pmr::polymorphic_allocator::construct内部实现最终基本都会落到::new ((void*)p) U(std::forwardArgs(args)...)这行。也就是说placement new 是标准分配器的底层原语自定义operator new则是在更底层的地方定制内存来源。所以我的建议是业务层尽量用 allocator、PMR 这类标准抽象当你需要把分配行为附着在某个具体类型上或者对象本身生命周期和某个 arena 严格绑定时再上自定义 placement 重载。它不是用来替代 allocator 的而是用来补 allocator 覆盖不到的那些硬场景。3. 对齐、数组与异常扩展语法绕不开的三个硬骨头3.1 对齐placement new 不对齐任何东西这是最容易被新手踩爆的坑。标准库的void*placement new 对传入地址没有任何检查原样返回。你传一个未对齐的char数组它照样在那个地址上构造对象但构造行为本身已经是未定义行为。比如char buf[sizeof(double)]; // 完全可能只对齐到 1 double* p new (buf) double(3.14); // 未定义行为更普遍的情况是自定义内存池返回的地址只保证char对齐但你要构造的是long long或含 SIMD 成员的类型。正确做法是构造对象前先拿到满足对齐要求的地址。C17 之前常见写法是#include cstddef #include memory void f() { alignas(std::max_align_t) unsigned char storage[sizeof(MyObject)]; MyObject* obj new (storage) MyObject(); obj-~MyObject(); }alignas(std::max_align_t)保证默认对齐类型的安全但对alignas(64)的类型仍不够得用alignas(64)或alignas(MyObject)。C17 之后也可以手动用std::align在一大块缓冲区里寻找满足对齐的子区间void f() { std::size_t space sizeof(MyObject) alignof(MyObject) - 1; alignas(std::max_align_t) unsigned char buffer[ sizeof(MyObject) alignof(MyObject) - 1 ]; void* p buffer; if (std::align(alignof(MyObject), sizeof(MyObject), p, space)) { MyObject* obj new (p) MyObject(); // ... } }这里要理解一点std::align返回的是满足对齐的地址它会向前偏移零到alignof-1个字节。所以 buffer 必须预留足够余量否则可能会把对象构造到越界位置。3.2 数组构造与析构循环的完整责任数组版本的 placement new 比单对象更容易失控。先看正确写法#include new constexpr std::size_t N 8; alignas(Widget) unsigned char storage[sizeof(Widget) * N]; Widget* widgets new (storage) Widget[N]; // 调 operator new[](size, storage) // 使用 widgets[0..N-1] // 必须逆序析构 for (std::size_t i N; i 0; --i) { widgets[i - 1].~Widget(); }为什么逆序因为构造函数是按 0 到 N-1 的顺序执行的析构理应按相反顺序这和普通 C 对象作用域结束的顺序一致。但这不是最关键的坑。很多人以为new (storage) Widget[N]会像普通new Widget[N]一样在数据前面多存一个数组长度有些编译器实现会这样于是给storage多预留了几个字节。实际上标准库提供的operator new[](std::size_t, void*)是原样返回传入地址不做额外记录因为内存不是你分配的编译器无法在delete[]时做对称处理。这直接意味着placement new 构造的数组永远不能用delete[]释放连想都不要想。如果数组中某些元素在构造时抛异常标准会保证已经构造完成的元素按逆序析构这部分由编译器兜底。但如果你自己用循环new (ptr i) T(...)来逐个构造一旦中途抛异常就得自己手动逆序清理前面已经构造的元素编译器不会帮你。3.3 构造函数抛异常为什么必须配套 placement delete这是自定义扩展语法时最隐蔽的一个问题。假设你定义了struct Risky { static void* operator new(std::size_t size, Arena arena) { return arena.alloc(size); } // 注意没有配套的 placement delete Risky() { throw std::runtime_error(boom); } };调用new (arena) Risky()时构造函数抛了异常会发生什么标准会查找与operator new形式对应的operator delete。如果找不到这个从arena分配出来的内存块就永远没人归还了。光是一个泄漏还算好更麻烦的是如果你这个 arena 是固定块池泄漏的块会一直占用池子容量反复创建失败几次之后整个池子就满了。排查时你可能完全想不到是“构造函数抛异常导致归还没被调用”。正确的配套写法struct Risky { static void* operator new(std::size_t size, Arena arena) { return arena.alloc(size); } static void operator delete(void* p, Arena arena) noexcept { arena.dealloc(p); } Risky() { throw std::runtime_error(boom); } };C14 开始还可以提供带大小的版本static void operator delete(void* p, Arena arena, std::size_t) noexcept { arena.dealloc(p); }带不带std::size_t参数会影响编译器在构造异常时选择哪个释放函数。我的经验是如果重载了一个新的 placement new就立刻在同一个类里写好配套的 placement delete哪怕函数体只有一行也不要省。这是写扩展语法前必须养成的肌肉记忆。4. 实战把扩展语法接进一个固定块内存池4.1 最小实现固定块池 类成员重载聊了这么多理论看一个能直接跑起来的完整例子。我写一个固定块大小的内存池专门用来分配Packet对象。#include cstddef #include new #include stdexcept #include cstdint class FixedPool { public: FixedPool(std::size_t blockSize, std::size_t capacity) : blockSize_(blockSize), capacity_(capacity), memory_(static_castunsigned char*(::operator new(blockSize * capacity))), head_(nullptr) { // 空闲链表初始构建把每个块串起来 unsigned char* p memory_; for (std::size_t i 0; i capacity_; i, p blockSize_) { free(p); } } ~FixedPool() { ::operator delete(memory_); } FixedPool(const FixedPool) delete; FixedPool operator(const FixedPool) delete; void* alloc() { if (!head_) { throw std::bad_alloc(); } void* p head_; // 块内存被作为空闲链表节点时存的就是下一个空闲块地址 head_ *static_castvoid**(p); return p; } void free(void* p) noexcept { if (!p) return; void** next static_castvoid**(p); *next head_; head_ p; } private: std::size_t blockSize_; std::size_t capacity_; unsigned char* memory_; void* head_; }; struct alignas(std::max_align_t) Packet { std::uint64_t payload[4]; static void* operator new(std::size_t size, FixedPool pool) { // 拒绝支持派生类 if (size ! sizeof(Packet)) { throw std::bad_alloc(); } return pool.alloc(); } static void operator delete(void* p, FixedPool pool) noexcept { pool.free(p); } }; int main() { FixedPool pool(sizeof(Packet), 1024); Packet* p1 new (pool) Packet{}; Packet* p2 new (pool) Packet{}; p1-~Packet(); p2-~Packet(); return 0; }注意几个设计选择。块大小blockSize_是按传入的sizeof(Packet)来的初始化时如果小于指针大小空闲链表根本构建不出来所以调用方必须保证。我在Packet上加alignas(std::max_align_t)是为了让池内块的起始地址能满足常见类型的对齐要求。你如果要做alignas(64)的类型就得把池起始地址和对齐一起处理。和前面讲的异常语义对应Packet构造函数如果抛异常编译器看到类里有operator delete(void*, FixedPool)会自动归还这块内存池子状态不会被破坏。这就是配套 delete 的价值。4.2 几个在选择时就会踩进去的坑第一个坑在operator new里size ! sizeof(Packet)时我用的是抛异常而不是fallback到::operator new。因为一旦 fallback配套的operator delete无法区分这个指针到底来自pool.alloc()还是来自全局分配器归还到 pool 里就是灾难。如果你确实想支持派生类请把派生对象的大小和池块大小统一或者重新设计一个带元信息的内存池而不是在分配函数里做不安全的分流。第二个坑池对象的生命周期必须覆盖所有从池里构造出来的对象。如果池先析构了对象后析构operator delete会访问一块已经释放的内存现场通常很难看。你可以用静态局部池来保证初始化顺序也可以用引用计数 RAII 把池和对象绑定在同一个作用域。第三个坑这个池不是线程安全的。多线程环境下要么在alloc/free里加锁要么给每个线程准备一个thread_local 池。加锁会让性能优势缩水thread_local 是更常见的选择。4.3 从性能到跨模块实际调优经验这个池在实际项目里到底能快多少如果底层::operator new走的是常规malloc在高并发场景下锁竞争反而会成为瓶颈。固定块池减少了系统调用和元数据读写但对于长期运行的服务器进程真正明显的变化往往是分配延迟的抖动变小了而不是平均耗时一定降低一个数量级。更值得关注的是跨模块问题。假如你的Packet是在一个动态库里通过new (pool) Packet构造的而析构代码写在主程序里一旦后续版本把类的 operator new 从库里导出方式改了析构函数和释放函数可能来自两个不同模块的堆管理状态崩溃很难查。我的习惯是所有从自定义池构造的对象也必须在同一个模块里完成析构和归还最好封装成只有工厂函数不允许外部直接操作裸指针。5. 编译器行为与排错记录5.1 MSVC 的 C4291 和 GCC/Clang 的 -Wplacement-new先聊编译器的“热心肠”。在 MSVC 下如果类里声明了带额外参数的operator new而没有配套的operator delete会得到警告 C4291大意是“声明了 operator new 但未声明匹配的 operator delete”。我遇到不少同事收到这个警告后直接 ignore其实它在提醒的就是 3.3 节说的构造异常内存泄漏。GCC 和 Clang 不会因为缺 placement delete 报警但它们有另一个很有用的警告开关-Wplacement-new。它能在编译期发现new (buf) T(...)时buf缓冲区明显小于sizeof(T)的情况比如void f() { char buf[4]; new (buf) double; // -Wplacement-new 会报警 }这个警告对动态计算出来的地址无能为力所以它更像是一个低成本体检不能当作完整保障。我一般会开着-Wplacement-new2跑单元测试至少能提前筛掉低级失误。5.2 高频错误的症状对照表根据我自己的踩坑记录下面这几种问题出现频率最高症状根因排查方式程序偶尔崩在析构函数里构造对象前缓冲区未对齐在new前打印地址检查低 4~6 位内存占用缓慢上涨构造函数抛异常但没有配套 placement delete代码审计 统计池内空闲块数释放时指针被篡改delete用了 placement new 出来的指针全局搜索delete表达式确认是否存在对应数组只析构了一个元素对new (buf) T[N]的结果直接delete改用手动循环逆序析构多线程下池表损坏alloc/free没有加锁或没有线程隔离压测 ASan 检查数据竞争动态库卸载时崩溃跨模块new/delete边界不统一封装工厂函数限制销毁入口这里面最危险的其实是第二行。它不一定会立刻崩溃只会让你在某次压测时发现池容量耗尽而代码逻辑看起来毫无问题。排查时唯一的捷径就是在自己的operator new和operator delete里加计数器看分配次数和归还次数是否对称。5.3 C17 之后的存储重用与 std::launder最后一个相对冷门但很重要的点和对象的存储重用有关。当你对同一块内存反复做 placement new 时旧对象的生命周期已经结束新对象在同一地址重新开始。这时候指向旧对象的指针在语义上是否还指向新对象C17 之前的对象模型没有把这个问题讲得足够严格C17 之后如果你需要继续使用旧指针读取新对象在满足“透明替换”条件之外标准会认为这个指针可能还引用着旧对象直接解引用属于未定义行为。解决方案是std::launderstruct X { int n; }; alignas(X) unsigned char buf[sizeof(X)]; X* p new (buf) X{1}; p-~X(); new (buf) X{2}; // 严格标准里p 这时可能不被认为指向新对象 X* q std::launder(p); // 现在 q 才是明确指向新对象的指针为什么需要这个因为编译器可以假定没有发生存储重用或者缓存旧对象的状态std::launder就是告诉编译器“别自作聪明这个地址上已经换了新对象请重新看待它。”实际项目中如果你每次 placement new 之后都用返回值来持有新指针比如X* q new (buf) X{2};一般不会触发这个风险。只有当你复用旧指针时才有必要考虑它。到这里placement new 的扩展语法从标准形态、重载机制、硬骨头细节到实战和排错基本串完了。我自己的体会是这套东西看着冷门但一旦你能熟练地在自定义内存源上构造对象很多内存分配器的设计就突然变得顺手了。如果你打算在实际代码里用起来建议先从最小 arena 开始不要一上来就设计复杂的池结构先把“对象生命周期完全落在一个内存区域”这件事跑顺再逐步加对齐、异常安全和跨模块约束。 
长河君 · 2026/9/16 2:54:14 · 阅读 1.2k C++ placement new扩展语法：从内存池到自定义内存管理
C 的 placement new 是一个容易被低估的特性。很多人第一次见到它是在内存池、嵌入式代码或者某些高性能库的源码里new (ptr) T(...)这种写法看起来只是把参数换了个位置实则把new的两步语义——分配内存和构造对象——彻底拆开了。不过市面上多数资料讲到void*这个标准版本就收尾了很少提到标题里说的“扩展语法”通过重载operator new你可以让new表达式带上自己的参数在任意指定的内存来源上构造对象。这篇文章就专门聊这份扩展语法从标准形态讲到自定义重载再落到内存池实战和排错经验适合已经在写 C、想更进一步控制对象生命周期和内存布局的人。1. placement new 的标准形态它拆开的究竟是哪两步1.1 两个入门的标准版本void* 与 nothrow先看第一个标准版本也是大家最熟悉的形式#include new #include iostream struct Point { int x, y; }; int main() { // 在已有缓冲区中构造 Point返回指向新构造对象的指针 alignas(Point) unsigned char buf[sizeof(Point)]; Point* p new (buf) Point{1, 2}; std::cout p-x , p-y \n; // placement new 没有对应的 placement delete必须手动析构 p-~Point(); }这段代码背后发生了什么new (buf) Point{1,2}这个表达式的处理可以拆成两步调用operator new(sizeof(Point), buf)。在返回的地址上调用Point的构造函数。标准库在new头文件里提供了void* operator new(std::size_t, void*) noexcept; void* operator new[](std::size_t, void*) noexcept;void*版本只是原样返回第二个参数不做任何内存分配也不对齐、不检查容量。所以它本质上不是“分配器”而是“构造器”。第二个标准版本是nothrowint* q new (std::nothrow) int(42); if (!q) { // 内存分配失败时返回 nullptr而不是抛 std::bad_alloc }从语法结构上看std::nothrow也是作为一个额外参数传入operator new(std::size_t, const std::nothrow_t)。它和void*版本一样共同点是都对应着标准库预置的operator new重载编译器在解析new表达式时会自动匹配到这些版本。1.2 拆开“分配”和“构造”意味着什么普通new表达式看起来是一步实际上也是两步1. 分配内存调用 operator new( sizeof(T) )可能抛 std::bad_alloc 2. 构造对象在分配好的内存上调用 T 的构造函数对应的delete表达式则是1. 析构对象调用 T 的析构函数 2. 释放内存调用 operator delete( void* )placement new 的作用就是把步骤 1 里的“分配内存”换成了你准备好的地址。这个拆开带来的直接控制力是对象需要的存储空间可以来自任意来源。栈上的数组、静态区、共享内存、mmap 映射的区域、DMA 缓冲区甚至是你自己维护的一个固定块池统统可以。但很多人会忽略一个反直觉的事实new (buf) T(...)不能用delete p来回收。因为编译器无法知道你传入的buf是从哪里来的自然也谈不上该用什么方式释放。你只能手动调用析构函数再交给原来的存储所有者处理。这一条是整个扩展语法的基础后面讲重载时也绕不开它。2. 扩展语法的核心机制operator new 重载才是真正的入口2.1 new 表达式中的参数是怎么被解析的标题里的“扩展语法”指的不只是标准库提供的两个operator new重载而是 C 允许你自己定义带任意额外参数的operator new。这个能力经常被忽略却非常强大。看一个简单的例子。假设你在开发一个游戏服务端需要频繁创建和销毁小型玩家对象不希望每次都走malloc/free所以准备了一个 arena。你可以在类里定义自己的 placement 重载#include cstddef #include new #include stdexcept class Arena { public: void* alloc(std::size_t size) { // 这里简单示例实际会从一块大内存里偏移分配 if (size capacity_) { throw std::bad_alloc(); } void* p reinterpret_castvoid*(memory_ offset_); offset_ size; return p; } void dealloc(void*) noexcept { // arena 的释放通常是一次性全部回收这里不做事 } private: alignas(std::max_align_t) unsigned char memory_[4096]; std::size_t offset_ 0; std::size_t capacity_ 4096; }; struct Actor { int hp 100; int x 0; int y 0; // 两个关键重载 static void* operator new(std::size_t size, Arena arena) { return arena.alloc(size); } static void operator delete(void* p, Arena arena) noexcept { arena.dealloc(p); } }; int main() { Arena arena; Actor* a new (arena) Actor(); // 用完手动析构 a-~Actor(); }注意到new (arena) Actor()这个表达式了吗编译器会在这个类的作用域里查找operator new找到匹配的operator new(std::size_t, Arena)于是自动完成调用void* raw Actor::operator new(sizeof(Actor), arena); Actor* a new (raw) Actor();重载的规则其实很明确第一个参数必须是std::size_t编译器会传入sizeof(要构造的类型)。后面的参数可以任意用户把new (...)括号里写什么就按类型匹配什么。如果定义在类里它默认是静态成员函数即使你不写static也如此。全局重载也可以但影响面大一般不建议随便污染全局命名空间。2.2 常见扩展形态栈上、对齐、调试信息基于这个机制可以扩展出来的形态非常多。我实际用过的有三种。第一种栈上对象。标准new (buf) T(...)其实已经能实现栈上构造但如果你希望在栈上分配一个可变大小的临时对象写法可以组合alloca或者栈缓冲区。某些嵌入式环境会封装一个StackArena然后把new (stackArena) Task()用在中断上下文里因为那里不能安全调用malloc。第二种带对齐要求的内存。当类型有扩展对齐要求比如alignas(64)普通缓冲区根本不够用。你可以在重载里做对齐处理让调用方无感知struct alignas(64) CacheLineValue { int data; static void* operator new(std::size_t size, Arena arena) { return arena.allocAligned(size, 64); } static void operator delete(void*, Arena) noexcept {} };第三种调试信息。我维护过一段无人敢动的老代码里面有很多从自定义池里new出来的对象一旦池泄漏根本不知道是谁没归还。后来加了一个带源码位置的重载struct LeakChecked { static void* operator new(std::size_t size, const char* file, int line) { void* p ::operator new(size); std::cout alloc size at file : line \n; return p; } static void operator delete(void* p, const char*, int) noexcept { ::operator delete(p); } }; // 用法 auto* obj new (__FILE__, __LINE__) LeakChecked();这里__FILE__和__LINE__直接作为额外参数传进重载分配信息就自动带上了。如果要避免每次写这两个宏可以用宏把new包装一下不过宏里的逗号处理要小心我建议宁可多写几个字符也别滥用宏替换至少调试起来少一层魔法。2.3 和 allocator_traits、PMR 的关系看到这里你可能会问如果很多地方都要用自定义分配为什么不直接用标准分配器非得自己写 operator new其实两者并不冲突。标准库的std::allocator_traits::construct以及 C17 的std::pmr::polymorphic_allocator::construct内部实现最终基本都会落到::new ((void*)p) U(std::forwardArgs(args)...)这行。也就是说placement new 是标准分配器的底层原语自定义operator new则是在更底层的地方定制内存来源。所以我的建议是业务层尽量用 allocator、PMR 这类标准抽象当你需要把分配行为附着在某个具体类型上或者对象本身生命周期和某个 arena 严格绑定时再上自定义 placement 重载。它不是用来替代 allocator 的而是用来补 allocator 覆盖不到的那些硬场景。3. 对齐、数组与异常扩展语法绕不开的三个硬骨头3.1 对齐placement new 不对齐任何东西这是最容易被新手踩爆的坑。标准库的void*placement new 对传入地址没有任何检查原样返回。你传一个未对齐的char数组它照样在那个地址上构造对象但构造行为本身已经是未定义行为。比如char buf[sizeof(double)]; // 完全可能只对齐到 1 double* p new (buf) double(3.14); // 未定义行为更普遍的情况是自定义内存池返回的地址只保证char对齐但你要构造的是long long或含 SIMD 成员的类型。正确做法是构造对象前先拿到满足对齐要求的地址。C17 之前常见写法是#include cstddef #include memory void f() { alignas(std::max_align_t) unsigned char storage[sizeof(MyObject)]; MyObject* obj new (storage) MyObject(); obj-~MyObject(); }alignas(std::max_align_t)保证默认对齐类型的安全但对alignas(64)的类型仍不够得用alignas(64)或alignas(MyObject)。C17 之后也可以手动用std::align在一大块缓冲区里寻找满足对齐的子区间void f() { std::size_t space sizeof(MyObject) alignof(MyObject) - 1; alignas(std::max_align_t) unsigned char buffer[ sizeof(MyObject) alignof(MyObject) - 1 ]; void* p buffer; if (std::align(alignof(MyObject), sizeof(MyObject), p, space)) { MyObject* obj new (p) MyObject(); // ... } }这里要理解一点std::align返回的是满足对齐的地址它会向前偏移零到alignof-1个字节。所以 buffer 必须预留足够余量否则可能会把对象构造到越界位置。3.2 数组构造与析构循环的完整责任数组版本的 placement new 比单对象更容易失控。先看正确写法#include new constexpr std::size_t N 8; alignas(Widget) unsigned char storage[sizeof(Widget) * N]; Widget* widgets new (storage) Widget[N]; // 调 operator new[](size, storage) // 使用 widgets[0..N-1] // 必须逆序析构 for (std::size_t i N; i 0; --i) { widgets[i - 1].~Widget(); }为什么逆序因为构造函数是按 0 到 N-1 的顺序执行的析构理应按相反顺序这和普通 C 对象作用域结束的顺序一致。但这不是最关键的坑。很多人以为new (storage) Widget[N]会像普通new Widget[N]一样在数据前面多存一个数组长度有些编译器实现会这样于是给storage多预留了几个字节。实际上标准库提供的operator new[](std::size_t, void*)是原样返回传入地址不做额外记录因为内存不是你分配的编译器无法在delete[]时做对称处理。这直接意味着placement new 构造的数组永远不能用delete[]释放连想都不要想。如果数组中某些元素在构造时抛异常标准会保证已经构造完成的元素按逆序析构这部分由编译器兜底。但如果你自己用循环new (ptr i) T(...)来逐个构造一旦中途抛异常就得自己手动逆序清理前面已经构造的元素编译器不会帮你。3.3 构造函数抛异常为什么必须配套 placement delete这是自定义扩展语法时最隐蔽的一个问题。假设你定义了struct Risky { static void* operator new(std::size_t size, Arena arena) { return arena.alloc(size); } // 注意没有配套的 placement delete Risky() { throw std::runtime_error(boom); } };调用new (arena) Risky()时构造函数抛了异常会发生什么标准会查找与operator new形式对应的operator delete。如果找不到这个从arena分配出来的内存块就永远没人归还了。光是一个泄漏还算好更麻烦的是如果你这个 arena 是固定块池泄漏的块会一直占用池子容量反复创建失败几次之后整个池子就满了。排查时你可能完全想不到是“构造函数抛异常导致归还没被调用”。正确的配套写法struct Risky { static void* operator new(std::size_t size, Arena arena) { return arena.alloc(size); } static void operator delete(void* p, Arena arena) noexcept { arena.dealloc(p); } Risky() { throw std::runtime_error(boom); } };C14 开始还可以提供带大小的版本static void operator delete(void* p, Arena arena, std::size_t) noexcept { arena.dealloc(p); }带不带std::size_t参数会影响编译器在构造异常时选择哪个释放函数。我的经验是如果重载了一个新的 placement new就立刻在同一个类里写好配套的 placement delete哪怕函数体只有一行也不要省。这是写扩展语法前必须养成的肌肉记忆。4. 实战把扩展语法接进一个固定块内存池4.1 最小实现固定块池 类成员重载聊了这么多理论看一个能直接跑起来的完整例子。我写一个固定块大小的内存池专门用来分配Packet对象。#include cstddef #include new #include stdexcept #include cstdint class FixedPool { public: FixedPool(std::size_t blockSize, std::size_t capacity) : blockSize_(blockSize), capacity_(capacity), memory_(static_castunsigned char*(::operator new(blockSize * capacity))), head_(nullptr) { // 空闲链表初始构建把每个块串起来 unsigned char* p memory_; for (std::size_t i 0; i capacity_; i, p blockSize_) { free(p); } } ~FixedPool() { ::operator delete(memory_); } FixedPool(const FixedPool) delete; FixedPool operator(const FixedPool) delete; void* alloc() { if (!head_) { throw std::bad_alloc(); } void* p head_; // 块内存被作为空闲链表节点时存的就是下一个空闲块地址 head_ *static_castvoid**(p); return p; } void free(void* p) noexcept { if (!p) return; void** next static_castvoid**(p); *next head_; head_ p; } private: std::size_t blockSize_; std::size_t capacity_; unsigned char* memory_; void* head_; }; struct alignas(std::max_align_t) Packet { std::uint64_t payload[4]; static void* operator new(std::size_t size, FixedPool pool) { // 拒绝支持派生类 if (size ! sizeof(Packet)) { throw std::bad_alloc(); } return pool.alloc(); } static void operator delete(void* p, FixedPool pool) noexcept { pool.free(p); } }; int main() { FixedPool pool(sizeof(Packet), 1024); Packet* p1 new (pool) Packet{}; Packet* p2 new (pool) Packet{}; p1-~Packet(); p2-~Packet(); return 0; }注意几个设计选择。块大小blockSize_是按传入的sizeof(Packet)来的初始化时如果小于指针大小空闲链表根本构建不出来所以调用方必须保证。我在Packet上加alignas(std::max_align_t)是为了让池内块的起始地址能满足常见类型的对齐要求。你如果要做alignas(64)的类型就得把池起始地址和对齐一起处理。和前面讲的异常语义对应Packet构造函数如果抛异常编译器看到类里有operator delete(void*, FixedPool)会自动归还这块内存池子状态不会被破坏。这就是配套 delete 的价值。4.2 几个在选择时就会踩进去的坑第一个坑在operator new里size ! sizeof(Packet)时我用的是抛异常而不是fallback到::operator new。因为一旦 fallback配套的operator delete无法区分这个指针到底来自pool.alloc()还是来自全局分配器归还到 pool 里就是灾难。如果你确实想支持派生类请把派生对象的大小和池块大小统一或者重新设计一个带元信息的内存池而不是在分配函数里做不安全的分流。第二个坑池对象的生命周期必须覆盖所有从池里构造出来的对象。如果池先析构了对象后析构operator delete会访问一块已经释放的内存现场通常很难看。你可以用静态局部池来保证初始化顺序也可以用引用计数 RAII 把池和对象绑定在同一个作用域。第三个坑这个池不是线程安全的。多线程环境下要么在alloc/free里加锁要么给每个线程准备一个thread_local 池。加锁会让性能优势缩水thread_local 是更常见的选择。4.3 从性能到跨模块实际调优经验这个池在实际项目里到底能快多少如果底层::operator new走的是常规malloc在高并发场景下锁竞争反而会成为瓶颈。固定块池减少了系统调用和元数据读写但对于长期运行的服务器进程真正明显的变化往往是分配延迟的抖动变小了而不是平均耗时一定降低一个数量级。更值得关注的是跨模块问题。假如你的Packet是在一个动态库里通过new (pool) Packet构造的而析构代码写在主程序里一旦后续版本把类的 operator new 从库里导出方式改了析构函数和释放函数可能来自两个不同模块的堆管理状态崩溃很难查。我的习惯是所有从自定义池构造的对象也必须在同一个模块里完成析构和归还最好封装成只有工厂函数不允许外部直接操作裸指针。5. 编译器行为与排错记录5.1 MSVC 的 C4291 和 GCC/Clang 的 -Wplacement-new先聊编译器的“热心肠”。在 MSVC 下如果类里声明了带额外参数的operator new而没有配套的operator delete会得到警告 C4291大意是“声明了 operator new 但未声明匹配的 operator delete”。我遇到不少同事收到这个警告后直接 ignore其实它在提醒的就是 3.3 节说的构造异常内存泄漏。GCC 和 Clang 不会因为缺 placement delete 报警但它们有另一个很有用的警告开关-Wplacement-new。它能在编译期发现new (buf) T(...)时buf缓冲区明显小于sizeof(T)的情况比如void f() { char buf[4]; new (buf) double; // -Wplacement-new 会报警 }这个警告对动态计算出来的地址无能为力所以它更像是一个低成本体检不能当作完整保障。我一般会开着-Wplacement-new2跑单元测试至少能提前筛掉低级失误。5.2 高频错误的症状对照表根据我自己的踩坑记录下面这几种问题出现频率最高症状根因排查方式程序偶尔崩在析构函数里构造对象前缓冲区未对齐在new前打印地址检查低 4~6 位内存占用缓慢上涨构造函数抛异常但没有配套 placement delete代码审计 统计池内空闲块数释放时指针被篡改delete用了 placement new 出来的指针全局搜索delete表达式确认是否存在对应数组只析构了一个元素对new (buf) T[N]的结果直接delete改用手动循环逆序析构多线程下池表损坏alloc/free没有加锁或没有线程隔离压测 ASan 检查数据竞争动态库卸载时崩溃跨模块new/delete边界不统一封装工厂函数限制销毁入口这里面最危险的其实是第二行。它不一定会立刻崩溃只会让你在某次压测时发现池容量耗尽而代码逻辑看起来毫无问题。排查时唯一的捷径就是在自己的operator new和operator delete里加计数器看分配次数和归还次数是否对称。5.3 C17 之后的存储重用与 std::launder最后一个相对冷门但很重要的点和对象的存储重用有关。当你对同一块内存反复做 placement new 时旧对象的生命周期已经结束新对象在同一地址重新开始。这时候指向旧对象的指针在语义上是否还指向新对象C17 之前的对象模型没有把这个问题讲得足够严格C17 之后如果你需要继续使用旧指针读取新对象在满足“透明替换”条件之外标准会认为这个指针可能还引用着旧对象直接解引用属于未定义行为。解决方案是std::launderstruct X { int n; }; alignas(X) unsigned char buf[sizeof(X)]; X* p new (buf) X{1}; p-~X(); new (buf) X{2}; // 严格标准里p 这时可能不被认为指向新对象 X* q std::launder(p); // 现在 q 才是明确指向新对象的指针为什么需要这个因为编译器可以假定没有发生存储重用或者缓存旧对象的状态std::launder就是告诉编译器“别自作聪明这个地址上已经换了新对象请重新看待它。”实际项目中如果你每次 placement new 之后都用返回值来持有新指针比如X* q new (buf) X{2};一般不会触发这个风险。只有当你复用旧指针时才有必要考虑它。到这里placement new 的扩展语法从标准形态、重载机制、硬骨头细节到实战和排错基本串完了。我自己的体会是这套东西看着冷门但一旦你能熟练地在自定义内存源上构造对象很多内存分配器的设计就突然变得顺手了。如果你打算在实际代码里用起来建议先从最小 arena 开始不要一上来就设计复杂的池结构先把“对象生命周期完全落在一个内存区域”这件事跑顺再逐步加对齐、异常安全和跨模块约束。