C++17 PMR内存管理：运行时多态分配器原理与实战应用

1. 项目概述如果你在C项目里被内存分配问题折磨过——比如性能瓶颈、内存碎片或者想在特定场景比如嵌入式、游戏、高频交易里搞点自定义的内存管理——那你肯定对标准库里的std::allocator又爱又恨。爱的是它通用恨的是它太死板想换个分配策略就得大动干戈给容器模板参数换个类型代码耦合度一下就上去了。C17 带来的std::pmr命名空间以及其中的std::pmr::memory_resource和std::polymorphic_allocator就是为了解决这个痛点。简单说它引入了一套基于运行时多态的、可插拔的内存分配器框架。memory_resource是抽象基类定义了分配、释放、比较的接口polymorphic_allocator则是适配器它内部持有一个memory_resource的指针把容器的内存请求转发给它。这套机制的核心价值在于你可以在运行时动态地切换容器的内存分配策略而无需改变容器的类型。这意味着同一段代码、同一种std::pmr::vectorint在启动时可以用堆分配在某个处理阶段可以切换到线程局部的内存池在处理完一批数据后又能切回另一个专用的缓冲区整个过程类型不变但底层行为天差地别。这对于追求极致性能、需要精细控制内存生命周期、或者资源受限的环境如嵌入式系统、游戏引擎、服务器中间件的开发者来说是一个游戏规则改变者。它把内存管理从编译时绑定中解放出来赋予了运行时极大的灵活性。接下来我们就深入这套机制的里里外外看看它怎么用为什么这么设计以及在实际项目中如何避开那些常见的“坑”。2. 核心设计思路与架构解析2.1 从传统分配器的困境到PMR的解决方案在C98/11的时代标准库容器已经支持自定义分配器通过模板的最后一个参数传入。比如std::vectorT, Alloc。这带来了两个主要问题类型污染分配器是容器类型的一部分。这意味着一个使用MyPoolAllocator的vectorint和另一个使用std::allocator的vectorint是不同的类型。它们不能直接赋值不能互相传递std::vectorint, MyAlloc和std::vectorint, StdAlloc的实例也无法放入同一个类型擦除的容器如std::vectorstd::vectorint这里内层vector的分配器类型必须一致。这严重限制了代码的通用性和模块化。编译时绑定分配策略在编译时就必须确定无法在运行时根据配置、数据量或系统状态动态切换。如果你想在程序启动时使用一个大的全局内存池而在处理某个特定任务时使用一个快速但非线程安全的栈缓冲区传统的模板分配器机制会让你非常头疼。std::pmr的解决方案非常巧妙它引入了一个间接层。polymorphic_allocator本身是一个轻量级的包装器它内部不实现任何分配逻辑而是持有一个指向memory_resource基类对象的指针。所有分配/释放请求都通过这个指针虚函数调用转发给具体的memory_resource派生类对象去执行。这样设计的好处立竿见影类型擦除所有使用std::pmr::polymorphic_allocatorT的容器无论其底层真正的memory_resource是哪种都具有相同的类型。例如std::pmr::vectorint就是一个固定的类型别名指向std::vectorint, std::pmr::polymorphic_allocatorint。你可以安全地将一个使用池分配器的pmr::vector赋值给另一个使用单调缓冲区的pmr::vector。运行时多态你可以在运行时通过改变polymorphic_allocator内部指针所指向的memory_resource对象来动态改变容器的分配行为。这是整个体系的核心能力。2.2 memory_resource抽象接口与契约std::pmr::memory_resource是一个抽象类它定义了内存资源必须实现的三个纯虚函数构成了整个多态分配器体系的基石class memory_resource { // ... public: void* allocate(size_t bytes, size_t alignment alignof(max_align_t)); void deallocate(void* p, size_t bytes, size_t alignment alignof(max_align_t)); bool is_equal(const memory_resource other) const noexcept; private: virtual void* do_allocate(size_t bytes, size_t alignment) 0; virtual void do_deallocate(void* p, size_t bytes, size_t alignment) 0; virtual bool do_is_equal(const memory_resource other) const noexcept 0; };do_allocate/do_deallocate这是资源实现者需要重写的核心。bytes是请求的字节数alignment是对齐要求C17起支持。实现者可以在这里实现任何策略从堆分配、从预分配的池中分配、从线程局部存储分配甚至是从一个永不释放的单调缓冲区分配。do_is_equal这个函数用于判断两个memory_resource对象是否“相等”。这里的“相等”并非指是否是同一个对象this other而是指它们是否属于同一类资源并且可以互相释放对方分配的内存。这是一个关键且容易误解的点。例如两个不同的monotonic_buffer_resource对象即使它们管理不同的内存块只要它们的分配/释放语义兼容通常意味着它们有相同的“上游资源”is_equal就可能返回true。而一个new_delete_resource和一个pool_resource的is_equal几乎总是false。polymorphic_allocator在拷贝赋值时会调用这个函数来检查兼容性。公共的allocate/deallocate函数是非虚的它们内部调用对应的虚函数并可能添加一些额外的逻辑比如参数校验。这种“非虚接口NVI”模式提供了更好的控制。2.3 polymorphic_allocator轻量级转发器std::pmr::polymorphic_allocator是一个模板类非常轻量。它的典型实现只有一个数据成员一个memory_resource*。template class T class polymorphic_allocator { private: memory_resource* m_resource; public: // 使用默认资源通常是 new_delete_resource构造 polymorphic_allocator() noexcept : m_resource(get_default_resource()) {} // 使用指定资源构造 polymorphic_allocator(memory_resource* r) noexcept : m_resource(r) {} // 拷贝构造函数共享资源指针不拷贝资源本身 polymorphic_allocator(const polymorphic_allocator other) default; // 模板化的拷贝构造函数允许从 allocatorU 构造 allocatorT只要共享同一个 resource template class U polymorphic_allocator(const polymorphic_allocatorU other) noexcept : m_resource(other.resource()) {} // 关键的分配/释放函数直接转发给 m_resource T* allocate(size_t n) { return static_castT*(m_resource-allocate(n * sizeof(T), alignof(T))); } void deallocate(T* p, size_t n) { m_resource-deallocate(p, n * sizeof(T), alignof(T)); } // 返回持有的资源指针 memory_resource* resource() const { return m_resource; } };它的工作纯粹是“转发”将元素个数n转换为字节数n * sizeof(T)。将类型T的对齐要求alignof(T)作为参数。调用其持有的memory_resource*的对应方法。由于它不包含任何状态除了那个指针所以它的拷贝成本极低并且满足“始终相等”的分配器概念即同一个资源派生的所有polymorphic_allocator实例都视为相等这使得std::pmr容器在移动元素时可以直接进行指针交换而无需重分配提升了效率。2.4 标准库的集成pmr别名模板为了便于使用C17为标准库容器提供了在std::pmr命名空间下的别名模板。例如namespace std::pmr { template class T using vector std::vectorT, polymorphic_allocatorT; template class T using string std::basic_stringchar, std::char_traitschar, polymorphic_allocatorchar; // 类似地还有 list, deque, map, unordered_map 等 }这意味着当你写下std::pmr::vectorint vec(myPoolResource);时你得到的vec其内部所有内存分配包括元素存储和可能的内部控制结构都将通过myPoolResource进行。这种集成是无缝且全面的。3. 预定义memory_resource详解与实战C17标准库贴心地提供了几个开箱即用的memory_resource实现。理解它们是正确使用PMR的基础。3.1 new_delete_resource默认的保底选择这是最基础的资源也是整个链条的默认终点。它直接调用全局的::operator new和::operator delete。std::pmr::memory_resource* default_res std::pmr::new_delete_resource();何时使用当你没有特殊需求或者作为其他资源的“上游资源upstream resource”时。它是系统默认资源std::pmr::get_default_resource()的初始返回值。注意事项它的行为就是普通的堆分配具有操作系统堆分配器的所有特性可能慢、可能产生碎片。在性能关键路径中它通常不是最佳选择。3.2 null_memory_resource分配即崩溃这是一个特殊的资源它的allocate()方法总是抛出std::bad_alloc异常。std::pmr::memory_resource* null_res std::pmr::null_memory_resource();何时使用测试与调试强制让某些代码路径在分配内存时失败以测试异常处理逻辑。资源限制在某些安全或嵌入式场景中明确禁止某部分代码进行动态内存分配。作为“终止符”在某些链式资源结构中将其设置为最后一环确保内存不会意外泄漏到更上游。实操心得不要将它设为全局默认资源除非你想让程序一启动就崩溃。通常它作为特定分配器的构造参数进行局部控制。3.3 monotonic_buffer_resource单向火箭只增不减这是我个人最常用也认为最能体现PMR价值的资源之一。它从一块给定的缓冲区或从上游资源获取分配内存并且只分配不释放直到整个资源对象被销毁。#include array #include memory_resource #include vector int main() { // 在栈上开辟一个固定大小的缓冲区 std::arraystd::byte, 1024 stack_buffer; // 用这个缓冲区初始化一个单调缓冲区资源 std::pmr::monotonic_buffer_resource pool{ stack_buffer.data(), stack_buffer.size(), std::pmr::new_delete_resource() // 上游资源当栈缓冲区用尽时使用 }; // 创建一个使用该资源的vector std::pmr::vectorint numbers(pool); for(int i 0; i 100; i) { numbers.push_back(i); // 前期的push_back非常快直接在栈缓冲区分配 } // 当栈缓冲区耗尽后后续的分配会通过上游资源这里是new_delete在堆上分配 // pool对象析构时会一次性释放所有从上游资源分配的内存。栈缓冲区自动回收。 }工作原理它维护一个内部指针指向缓冲区中下一个可用的地址。分配时简单地移动这个指针并考虑对齐。没有空闲内存块的管理没有合并操作。核心优势极速分配/释放分配是O(1)的指针移动释放是空操作no-op。资源对象析构时一次性释放所有从上游获取的内存。无碎片内存是连续使用的不存在外部碎片。缓存友好如果使用栈或静态缓冲区数据很可能在缓存热区。适用场景临时性、批处理操作比如解析一个文件、处理一个网络请求、渲染一帧画面。在这个操作的生命周期内创建大量临时对象操作结束后整体销毁。对象池用于分配大量生命周期相同的小对象。性能关键路径需要避免常规堆分配开销的地方。重大限制与坑点内存只增不减这是设计使然但也是最大的陷阱。如果你在一个长生命周期资源中不断分配它会持续向上游索要内存直到耗尽。绝对不要将monotonic_buffer_resource用于可能频繁分配释放的长期容器。非线程安全标准实现不是线程安全的。如果多个线程同时向同一个monotonic_buffer_resource分配内存需要外部加锁。释放顺序由于不执行析构时的释放指向池内内存的指针在池销毁后全部失效。确保池的生命周期覆盖所有使用其内存的对象。3.4 synchronized_pool_resource 与 unsynchronized_pool_resource通用内存池这两个是更通用的内存池资源用于减少内存碎片和提高小内存块的分配效率。它们管理一系列不同大小的内存块“池”。synchronized_pool_resource线程安全版本。内部有锁允许多线程并发分配/释放。unsynchronized_pool_resource非线程安全版本性能更高但只能用于单线程。// 创建一个线程安全的池资源使用默认的上游资源 std::pmr::synchronized_pool_resource pool; std::pmr::vectorstd::pmr::string thread_safe_vec(pool); // 在另一个线程中也可以安全使用 std::thread t([pool]{ std::pmr::listint local_list(pool); // ... 操作 local_list }); t.join();工作原理它们会根据请求的大小将内存请求路由到最适合的“池”pool中。每个池负责管理特定大小范围的内存块。这大大减少了频繁分配释放不同大小内存带来的碎片问题。适用场景多线程服务如Web服务器、游戏服务器需要为大量并发请求分配小内存对象如HTTP头、游戏状态更新。长期运行的程序需要缓解长时间运行后堆内存碎片化的问题。替代全局的new/delete可以通过std::pmr::set_default_resource将其设为全局默认让程序中所有未显式指定资源的PMR容器都使用这个池。配置选项它们的构造函数允许你传入一个pool_options结构用来调整池的行为例如最大块大小、每个池的初始块数等。合理调整这些参数可以优化特定工作负载下的性能。std::pmr::pool_options opts; opts.max_blocks_per_chunk 1024; // 每个块最多包含1024个元素 opts.largest_required_pool_block 4096; // 池管理的最大内存块为4096字节 std::pmr::unsynchronized_pool_resource pool(opts);4. 自定义memory_resource开发指南预定义的资源虽然强大但PMR的真正威力在于你可以轻松打造属于自己的内存管理策略。实现一个自定义的memory_resource通常只需要重写三个虚函数。4.1 基础实现框架下面是一个最简单的“跟踪资源”示例它不改变分配行为只是记录所有分配和释放调用用于调试或性能分析。#include memory_resource #include iostream #include unordered_map class tracking_memory_resource : public std::pmr::memory_resource { private: std::pmr::memory_resource* upstream_; // 上游资源实际干活的人 std::size_t total_allocated_ 0; std::size_t total_deallocated_ 0; std::unordered_mapvoid*, std::size_t live_allocations_; // 记录存活分配 void* do_allocate(std::size_t bytes, std::size_t alignment) override { void* p upstream_-allocate(bytes, alignment); total_allocated_ bytes; live_allocations_[p] bytes; std::cout [ALLOC] bytes bytes, aligned to alignment , addr: p , total: total_allocated_ \n; return p; } void do_deallocate(void* p, std::size_t bytes, std::size_t alignment) override { auto it live_allocations_.find(p); if (it ! live_allocations_.end()) { live_allocations_.erase(it); } else { std::cout [WARN] Deallocating unknown pointer: p \n; } total_deallocated_ bytes; std::cout [DEALLOC] bytes bytes, addr: p , total dealloc: total_deallocated_ \n; upstream_-deallocate(p, bytes, alignment); } bool do_is_equal(const std::pmr::memory_resource other) const noexcept override { // 只有当 other 也是 tracking_memory_resource 且指向同一个上游资源时 // 才认为相等。这里简化处理仅比较对象地址。 // 更严谨的实现需要比较 upstream_ 的 is_equal。 return this other; } public: explicit tracking_memory_resource(std::pmr::memory_resource* upstream std::pmr::get_default_resource()) : upstream_(upstream) {} ~tracking_memory_resource() { if (!live_allocations_.empty()) { std::cout [LEAK] live_allocations_.size() allocations not freed, total bytes: ; std::size_t leak_bytes 0; for (const auto [ptr, sz] : live_allocations_) { leak_bytes sz; } std::cout leak_bytes \n; } std::cout [SUMMARY] Net bytes: (total_allocated_ - total_deallocated_) \n; } };使用示例int main() { tracking_memory_resource tracker; std::pmr::vectorint vec(tracker); vec.reserve(10); // 触发一次分配 vec.push_back(1); vec.push_back(2); // vector 扩容时会分配新内存释放旧内存 for(int i0; i100; i) vec.push_back(i); // tracker 析构时会打印泄漏摘要 }4.2 设计更复杂的资源一个线程局部缓存资源假设我们有一个场景主线程有一个大的内存池每个工作线程需要频繁分配释放小对象。为了减少对主池的锁竞争我们可以为每个线程设计一个带本地缓存的资源。class thread_local_caching_resource : public std::pmr::memory_resource { struct thread_cache { std::vectorvoid* free_list_[64]; // 假设缓存64种大小 // ... 其他缓存管理数据 }; static thread_local thread_cache t_cache_; std::pmr::synchronized_pool_resource* global_pool_; // 全局共享池 void* do_allocate(std::size_t bytes, std::size_t alignment) override { // 1. 根据bytes找到对应的free_list索引 size_t index size_to_index(bytes); // 2. 检查线程本地缓存是否有可用块 if (!t_cache_.free_list_[index].empty()) { void* p t_cache_.free_list_[index].back(); t_cache_.free_list_[index].pop_back(); return p; } // 3. 缓存为空从全局池批量获取一批内存放入缓存再返回一个 size_t batch_size 16; for (size_t i 0; i batch_size; i) { void* block global_pool_-allocate(bytes, alignment); t_cache_.free_list_[index].push_back(block); } void* p t_cache_.free_list_[index].back(); t_cache_.free_list_[index].pop_back(); return p; } void do_deallocate(void* p, std::size_t bytes, std::size_t alignment) override { // 不直接还给全局池先放入线程本地缓存 size_t index size_to_index(bytes); t_cache_.free_list_[index].push_back(p); // 如果缓存过大可以归还一部分给全局池 if (t_cache_.free_list_[index].size() 128) { // ... 清理逻辑 } } bool do_is_equal(const memory_resource other) const noexcept override { // 通常每个线程的缓存资源是独立的不相等。 // 但这里我们设计为如果指向同一个全局池则视为“兼容”。 // 这需要更复杂的逻辑来判断上游资源是否相等。 // 简化起见返回 false 是安全的意味着分配器不能互相释放内存。 return false; } public: explicit thread_local_caching_resource(std::pmr::synchronized_pool_resource* global_pool) : global_pool_(global_pool) {} };这个例子展示了如何利用PMR框架构建复杂的、符合特定应用模式的内存管理策略。关键在于do_allocate和do_deallocate的实现完全由你掌控。4.3 实现do_is_equal的注意事项do_is_equal的实现是自定义资源中最微妙的部分。它的返回值决定了两个polymorphic_allocator是否“相等”。标准要求如果a.resource()-is_equal(*b.resource())返回true那么用a分配的内存可以用b释放反之亦然。简单策略保守只在与*this是同一个对象时才返回true。这最安全但限制了灵活性。意味着从一个资源创建的分配器不能用于释放另一个相同类型资源分配的内存即使它们在逻辑上兼容。bool do_is_equal(const memory_resource other) const noexcept override { return this other; }基于上游资源的策略如果你的资源内部包装了另一个上游资源如tracking_memory_resource你可以定义“相等”为两个资源是同一类型且它们包装的上游资源是is_equal的。bool do_is_equal(const memory_resource other) const noexcept override { if (const auto* p dynamic_castconst tracking_memory_resource*(other)) { return upstream_-is_equal(*p-upstream_); } return false; }语义相等策略对于像monotonic_buffer_resource这样的资源即使管理不同的缓冲区只要它们有相同的分配语义比如都从不释放库的实现可能会让它们is_equal返回true这样从一个缓冲区分配的polymorphic_allocator可以“移动”到另一个缓冲区通过赋值而容器可能不需要重分配取决于实现。在实现自定义资源时务必仔细思考你的资源在什么情况下可以安全地互相释放内存。5. 深入polymorphic_allocator与容器交互的细节5.1 分配器的传播与状态std::pmr::polymorphic_allocator满足C11引入的“无状态分配器”和“传播分配器”的概念。具体来说始终相等Always Equal如果两个polymorphic_allocator实例的resource()返回的指针通过is_equal比较为true那么这两个分配器被认为是相等的。对于默认构造的分配器使用get_default_resource()它们总是相等的。这使得容器在移动元素时可以进行指针交换等优化。传播当容器发生拷贝构造、移动构造或交换时分配器会根据其特性进行传播。polymorphic_allocator被定义为“选择性地传播”propagate_on_container_copy_assignment,propagate_on_container_move_assignment,propagate_on_container_swap等类型特征。对于PMR容器通常分配器在拷贝时会被拷贝即新容器使用相同的资源而在移动时分配器也会被移动目标容器获得源容器的资源。这意味着移动一个PMR容器是高效的并且移动后源容器处于有效但未指定的状态通常使用默认资源。5.2 字符串与容器的嵌套使用PMR的一个强大特性是支持嵌套容器的内存统一管理。例如一个std::pmr::vectorstd::pmr::string其内部的string所持有的字符缓冲区也会使用外层vector的分配器通过分配器的传播机制从而所有内存都来自同一个memory_resource。#include memory_resource #include vector #include string int main() { // 创建一个大的单调缓冲区 std::arraystd::byte, 64*1024 huge_buffer; std::pmr::monotonic_buffer_resource pool(huge_buffer.data(), huge_buffer.size()); // 创建一个vector其元素是pmr::string std::pmr::vectorstd::pmr::string string_vec(pool); // 添加字符串这些字符串的内部缓冲区也从 pool 分配 string_vec.push_back(A very long string that needs dynamic allocation...); string_vec.push_back(Another string); string_vec.emplace_back(100, X); // 构造一个包含100个X的字符串 // 此时vector的控制块、存储string对象的空间、以及每个string内部的字符数组 // 全部来自于 pool 管理的栈缓冲区或在其耗尽后来自上游。 // 当 pool 析构时所有这些内存被一次性、高效地释放。 }这种能力对于构建复杂的数据结构如树、图尤其有用可以确保整个结构的内存来自同一个区域提高局部性并简化内存释放。5.3 资源管理与生命周期这是PMR使用中最容易出错的地方。polymorphic_allocator只持有memory_resource的指针不拥有其所有权。你必须确保memory_resource对象的生命周期长于所有使用它的分配器和容器。// 危险代码示例 std::pmr::vectorint* create_vector() { char buffer[1000]; std::pmr::monotonic_buffer_resource pool(buffer, sizeof(buffer)); // 错误返回的vector内部的allocator指向即将销毁的局部变量 pool return new std::pmr::vectorint(pool); } // 调用 create_vector() 后pool 被销毁返回的vector持有一个悬垂指针。 // 正确做法1使用动态分配的、生命周期更长的资源 std::pmr::vectorint* create_vector_safe(std::pmr::memory_resource* resource) { return new std::pmr::vectorint(resource); // 资源由调用者管理 } // 正确做法2使用全局或静态资源 std::pmr::unsynchronized_pool_resource global_pool; // 静态或全局生命周期 std::pmr::vectorint get_vector() { return std::pmr::vectorint(global_pool); }黄金法则谁创建memory_resource谁负责管理其生命周期。通常将资源对象放在更高层的作用域如类成员、静态变量、主函数栈帧或者使用std::shared_ptr包装自定义资源来共享所有权。6. 性能考量、陷阱与最佳实践6.1 性能开销分析PMR引入了虚函数调用和间接寻址的开销。每次分配/释放都需要通过polymorphic_allocator的指针调用memory_resource的虚函数。开销与直接调用new/delete或使用编译时特化的分配器相比每次分配多一次指针解引用和一次虚函数调用。在分配极其频繁的微操作中这可能成为可测量的开销。如何权衡收益通常远大于开销如果自定义资源如单调缓冲区、内存池带来的分配速度提升、碎片减少或缓存局部性改善是显著的那么这点虚函数开销完全可以忽略。例如从堆分配切换到栈缓冲区性能提升可能是几个数量级。热点路径优化在绝对性能敏感的代码段如内层循环可以考虑使用编译时确定的分配策略或者确保使用的PMR资源本身极其高效如monotonic_buffer_resource。使用std::pmr::polymorphic_allocator的resource()方法进行直接调用如果你在自定义代码中需要频繁分配可以获取资源指针并直接调用其allocate方法避免通过polymorphic_allocator的模板转发层。6.2 常见陷阱与解决方案陷阱资源生命周期短于容器现象程序崩溃访问违例错误释放内存。解决方案严格遵守生命周期管理。使用RAII包装资源或将其存储在生命周期足够长的上下文中如全局对象、应用单例、请求上下文。陷阱误用monotonic_buffer_resource于长期容器现象内存使用量只增不减最终耗尽。解决方案明确monotonic_buffer_resource的适用场景是“临时工作区”。对于需要长期存在并动态调整大小的容器使用pool_resource或自定义的、支持释放的资源。陷阱线程安全问题现象多线程同时使用非线程安全的资源如monotonic_buffer_resource,unsynchronized_pool_resource导致数据竞争。解决方案为每个线程创建独立的资源实例。使用synchronized_pool_resource。在资源外部加锁但要注意锁粒度。陷阱polymorphic_allocator的类型转换现象模板代码中polymorphic_allocatorT和polymorphic_allocatorU是不同类型但可以相互构造前提是它们共享同一个resource()。这有时会导致令人困惑的编译错误或运行时错误。解决方案理解分配器的传播规则。在编写通用模板时使用std::allocator_traits来正确处理分配器的拷贝、移动和类型转换。陷阱与标准库非PMR类型混用现象std::vectorint和std::pmr::vectorint是不同类型不能直接赋值或比较。将std::string放入std::pmr::vectorstd::pmr::string会导致std::string使用默认的std::allocator破坏内存统一性。解决方案在决定使用PMR的模块或组件中全线使用PMR类型std::pmr::string,std::pmr::map等。如果需要与外部接口交互在边界处进行数据拷贝转换。6.3 最佳实践总结明确场景不要为了用而用。在需要特定内存策略性能优化、碎片控制、特定内存区域分配或需要运行时灵活切换策略时才引入PMR。统一内存域对于一个逻辑模块或数据处理流程尽量使用同一个memory_resource让其中所有PMR容器和对象都从该资源分配便于管理和释放。善用预定义资源monotonic_buffer_resource用于临时批量操作(un)synchronized_pool_resource用于通用、长期的内存池管理new_delete_resource作为保底的上游。生命周期管理是重中之重用智能指针、类成员变量或作用域规则清晰地管理memory_resource的生命周期。性能剖析在关键应用中使用PMR前后进行性能剖析Profiling确认其带来的收益确实大于虚函数调用等开销。自定义资源用于复杂策略当预定义资源不满足需求时继承memory_resource实现自己的策略是直截了当的。确保正确实现do_is_equal。注意头文件PMR相关组件定义在memory_resource头文件中C17部分编译器的实现可能仍在experimental/memory_resource中并位于std::experimental::pmr命名空间直到完全支持C17。