std::pmr的核心用途是实现运行时可切换的内存分配策略,避免模板重实例化;必须使用场景包括动态切换内存行为、嵌入式模拟、请求级内存池、跨模块容器传递;其allocator通过绑定memory_resource实现转发,需注意资源生命周期、线程安全、移动语义及自定义类型适配。

std::pmr 的核心用途是:让同一套容器代码(比如 std::pmr::vector)能在运行时切换底层内存分配策略,而无需模板重实例化 —— 本质是把原本编译期绑定的 Allocator 变成运行期可插拔的资源。
什么时候必须用 std::pmr 而不是普通 allocator?
当你需要在不改代码、不重新编译的前提下,动态切换内存行为时。典型场景包括:
- 单元测试中用
std::pmr::monotonic_buffer_resource模拟“只分配不释放”的嵌入式环境 - 服务端请求处理中,为每个请求预分配一块大内存池(
std::pmr::synchronized_pool_resource),避免频繁系统调用 - 跨 DLL / SO 边界传递容器时,确保双方使用同一内存资源(否则
new分配、另一模块delete会崩溃)
std::pmr::polymorphic_allocator 怎么和资源绑定?
它本身不分配内存,只是个“转发器”,所有分配/释放操作都委托给构造时传入的 std::pmr::memory_resource*。关键点:
- 默认构造的
std::pmr::polymorphic_allocator绑定的是全局默认资源(std::pmr::new_delete_resource()) - 显式传入指针才真正切换策略:
std::pmr::monotonic_buffer_resource pool{buffer, sizeof(buffer)}; std::pmr::polymorphic_allocatoralloc{&pool}; - 容器如
std::pmr::vector的构造函数接受该 allocator,但注意:它只影响该容器自身及其元素的内存,不递归控制嵌套容器(比如vector<:string>中的string需要单独指定 allocator)
常见踩坑:为什么用了 std::pmr 还在用 malloc 或崩溃?
根本原因在于资源生命周期和所有权没理清:
立即学习“C++免费学习笔记(深入)”;
-
std::pmr::monotonic_buffer_resource析构时不会自动回收内存,但若 buffer 是栈变量,而 vector 还在用它,就会访问已销毁内存 - 多个线程共用同一个
std::pmr::synchronized_pool_resource没问题,但若用std::pmr::unsynchronized_pool_resource就必须加锁,否则 UB - 从
std::pmr::vector移动构造出新对象时,allocator 是被拷贝的,但如果原 allocator 指向一个局部memory_resource,新 vector 就会持有悬空指针 - 不能混用资源:用 A 资源分配的内存,必须用 A 资源释放;
std::pmr::polymorphic_allocator不检查这个,出错时通常表现为 double-free 或 heap corruption
最易被忽略的一点:所有自定义类型如果内部有动态内存(比如含 std::string 成员),又想完全走 pmr 路径,必须显式提供 using allocator_type = std::pmr::polymorphic_allocator<...> 并重载带 allocator 的构造函数——否则成员仍走默认 new/delete。

