memory_resource 是 C++17 引入的类型无关内存分配抽象接口，与 std::allocator 分层协作而非替代；必须通过 std::pmr::polymorphic_allocator 和 std::pmr 容器（如 pmr::vector）使用，不可直接用于传统模板 allocator。
memory_resource 是什么，和 allocator 有什么区别
memory_resource 是 C++17 引入的抽象接口（纯虚类），定义了 allocate / deallocate / is_equal 三个核心函数，不绑定具体类型，也不参与模板实例化。它和传统 std::allocator 不是替代关系，而是分层协作：STL 容器可通过 std::pmr::polymorphic_allocator 包装一个 memory_resource*，把类型无关的内存请求转发过去。
关键点在于：你不能直接把自定义 memory_resource 塞给 std::vector<int, MyAllocator> 这种模板 allocator；必须走 std::pmr 路线，比如 std::pmr::vector<int></int>。
写一个最简可用的派生类（比如 arena_resource）
继承 std::memory_resource，实现三个虚函数即可。常见错误是忽略 is_equal —— 如果两个 resource 实例逻辑上等价（比如指向同一块预分配 buffer），必须返回 true，否则 std::pmr::polymorphic_allocator 可能绕过缓存或误判资源归属。
class arena_resource : public std::memory_resource {
std::vector<std::byte> storage_;
size_t offset_ = 0;
<p>protected:
void<em> do_allocate(size_t bytes, size_t alignment) override {
const auto aligned_offset = align<em>offset(offset</em>, alignment);
if (aligned<em>offset + bytes > storage</em>.size()) throw std::bad_alloc{};
void</em> ptr = storage_.data() + aligned<em>offset;
offset</em> = aligned_offset + bytes;
return ptr;
}</p><pre class='brush:php;toolbar:false;'>void do_deallocate(void* p, size_t, size_t) override {
// arena 不支持 individual deallocation
}
bool do_is_equal(const std::memory_resource& other) const noexcept override {
return this == &other; // 或按语义判断（如 shared_ptr 指向同一 arena）
}public: explicit arena_resource(sizet cap) : storage(cap) {} };
注意：do_deallocate 空实现是合法的（arena 语义），但若容器在析构时调用 deallocate，而你的实现抛异常或崩溃，就会 UB。务必匹配资源语义。
立即学习“C++免费学习笔记（深入）”；
怎么让 vector/string 等容器真正用上它
必须显式使用 std::pmr 版本，并传入对应 allocator：
-
std::pmr::vector<int></int>默认用std::pmr::get_default_resource() - 要换资源，得构造时传
std::pmr::polymorphic_allocator：arena_resource ar(1024 * 1024); std::pmr::vector<int> v{std::pmr::polymorphic_allocator<int>{&ar}}; v.push_back(42); // 内存来自 ar
常见坑：
- 忘记
std::pmr::前缀，写了std::vector就还是走全局 new - 把
polymorphic_allocator当成普通 allocator 传给非pmr容器，编译失败 - 在函数里临时创建
arena_resource，但容器生命周期更长，导致 use-after-free
和 set_default_resource 的配合与风险
std::pmr::set_default_resource(&my_res) 会影响所有未显式指定 allocator 的 std::pmr::* 对象。这看似方便，实则危险：
- 全局状态，多线程下需加锁（
set_default_resource本身线程安全，但切换时机难控） - 第三方库若也用
pmr，可能意外被你的 resource 影响 - 单元测试中容易污染后续用例
更稳妥的做法是局部显式传参，或者用 RAII 封装：
struct scoped_default {
std::memory_resource* old_;
scoped_default(std::memory_resource* r) : old_{std::pmr::get_default_resource()} {
std::pmr::set_default_resource(r);
}
~scoped_default() { std::pmr::set_default_resource(old_); }
};
memory_resource 的核心价值不在“替换 malloc”，而在控制内存生命周期和布局——比如 arena、pool、mmap 区域。一旦离开 pmr 生态链（比如混用 raw new 或 legacy allocator），整个设计就断掉了。
