unsynchronized_pool_resource 是 C++17 std::pmr 中的非线程安全内存池实现，专为单线程高频小对象分配优化，不加锁、性能高于同步版本，但禁止跨线程共享；适用于生命周期可控、分配尺寸相对固定的场景。
unsynchronized_pool_resource 是什么，适合什么场景
unsynchronized_pool_resource 是 C++17 引入的 std::pmr::memory_resource 实现之一，专为单线程、高吞吐、低延迟内存分配设计。它不加锁，因此比 synchronized_pool_resource 更快，但不能在多线程间共享使用——哪怕只读访问也不行（内部 pool 状态非原子）。
常见误用场景包括：
- 在多个线程中各自 new 一个
unsynchronized_pool_resource对象，然后传给各自的std::pmr::vector—— 这没问题 - 把同一个
unsynchronized_pool_resource实例指针传给多个线程调用allocate()—— 会崩溃或静默损坏内存
怎么创建并绑定到容器
直接构造即可，无需额外初始化。关键在于让容器（如 std::pmr::vector）通过 std::pmr::polymorphic_allocator 使用它：
std::pmr::unsynchronized_pool_resource pool; std::pmr::polymorphic_allocator<int> alloc(&pool); std::pmr::vector<int> vec(alloc); // 所有内存从此 pool 分配 vec.reserve(1024); // 触发一次大块分配，进入 pool 管理
注意：
立即学习“C++免费学习笔记（深入）”；
-
pool生命周期必须长于所有使用它的容器 - 不要对
unsynchronized_pool_resource对象做拷贝（它不可拷贝），只传地址或引用 - 如果你用的是局部
pool，而容器生命周期超出作用域（比如返回了 vector），就会 dangling allocator —— 行为未定义
为什么有时没看到性能提升，甚至更慢
unsynchronized_pool_resource 的加速前提是：分配模式匹配其池结构（固定大小 chunk + 多次小对象分配）。否则可能反而更差：
- 分配大小差异大（比如混用 16B 和 2KB 对象）→ 落入上游 fallback resource（通常是
new_delete_resource），完全绕过池 - 单次分配量极大（> 4KB 默认阈值）→ 直接走系统分配，不进池
- 频繁
deallocate()后又立刻allocate()同尺寸 → 理论上复用快，但若对象生命周期错乱（如容器 resize 导致反复析构/构造），实际缓存局部性差
可检查是否真走池逻辑：
// 重载 allocate，加日志或断点
struct logging_resource : std::pmr::unsynchronized_pool_resource {
void* allocate(std::size_t bytes, std::size_t align) override {
std::cout << "alloc " << bytes << "B\n";
return unsynchronized_pool_resource::allocate(bytes, align);
}
};
和 malloc/new 比，要注意哪些兼容性细节
unsynchronized_pool_resource 不保证满足所有 malloc 行为：
- 它不保证零初始化（
allocate()返回的内存未清零，类似malloc，不同于new T[]的 value-initialization） - 不支持
realloc语义；std::pmr::vector::reserve()内部是先allocate新块、再deallocate旧块，不是就地扩展 - 若自定义类型含非 trivial 析构函数，容器销毁时仍会正确调用析构，但内存本身不会自动归还给池——直到
unsynchronized_pool_resource析构或显式调用release()
release() 会释放所有已分配但未归还的内存（即清空整个池），但已交给用户使用的内存块仍需由用户 deallocate()；否则下次 allocate() 可能失败或行为异常。
真正容易被忽略的一点：池的“无锁”只针对单线程内并发调用安全，不等于内存安全。如果忘了 deallocate()，或者 deallocate() 时 size/align 和 allocate() 不一致，依然会破坏池内部结构——这种错误通常不会立即 crash，但会在后续某次分配中爆发。
