std::pmr::synchronized_pool_resource 本身线程安全，allocate/deallocate 自动串行化，但 release() 非线程安全；fallback resource 必须可重入；pool_options 控制块分配粒度而非总内存上限；不可与 monotonic_buffer_resource 混用；跨线程 deallocate 要求使用同一 resource 实例。
std::pmr::synchronized_pool_resource 本身已线程安全，无需额外加锁
它内部封装了 std::pmr::pool_options 和一个带互斥保护的内存池结构，所有 allocate() / deallocate() 调用自动串行化。你直接在多线程中使用同一个实例即可，不用 wrap 成 std::shared_ptr 或手动加 std::mutex —— 那反而会引入不必要开销或死锁风险。
常见错误是误以为“同步”只指 pool 内部块分配同步，而忽略其对上游 memory resource（如 fallback resource）的调用仍需线程安全。如果设置了非线程安全的 fallback（比如裸 std::pmr::new_delete_resource()），那 fallback 分支仍是安全的（因为 new/delete 本身线程安全），但若换成自定义 fallback，就必须确保它自己可重入。
- 默认 fallback 是
std::pmr::new_delete_resource()，线程安全 - 构造时传入的
upstreamresource 必须支持多线程并发调用allocate/deallocate - 不要在多个线程里同时调用
release()—— 它不是线程安全的，会清空内部所有缓存块
如何控制 pool 的大小与增长策略（pool_options）
std::pmr::synchronized_pool_resource 构造时可传入 std::pmr::pool_options，它有两个关键字段：max_blocks_per_chunk 和 largest_required_pool_block。它们不控制总内存上限，而是影响 chunk 划分粒度和小对象复用效率。
例如：设置 largest_required_pool_block = 128，意味着所有 ≤128 字节的分配请求走 pool 内部块管理；更大的请求直接转发给 upstream。这个值设太小会导致大量小 chunk 碎片，设太大则浪费空间或降低复用率。
立即学习“C++免费学习笔记（深入）”；
std::pmr::pool_options opts{
.max_blocks_per_chunk = 32, // 每次向 upstream 申请的 chunk 最多切出 32 块
.largest_required_pool_block = 256 // ≥256 字节的分配直接 bypass pool
};
- 默认
largest_required_pool_block是 0，表示“由实现决定”，通常为 512 左右，不可移植 -
max_blocks_per_chunk影响内存局部性：值越大，单个 chunk 寿命越长，但可能长期占用不释放 - 这两个参数不影响线程安全性，只影响性能与内存驻留行为
与 std::pmr::monotonic_buffer_resource 的关键区别
别混淆二者：前者是可回收、多线程安全、带块复用的池；后者是仅追加、单线程友好、不可回收的缓冲区。如果你在线程内反复创建/销毁临时容器（如 std::pmr::vector），synchronized_pool_resource 能复用内存；而 monotonic_buffer_resource 在生命周期结束前无法释放任何块，即使中间 clear() 了 vector。
典型误用场景：把 synchronized_pool_resource 当作栈式资源用，在函数退出时期望自动清理——它不会自动释放，必须显式调用 release()（且只能由单一线程调用）或靠析构（析构是线程安全的，但会阻塞其他线程直到完成）。
-
synchronized_pool_resource的析构函数会等待所有当前 pending 操作完成，再释放所有 chunk -
monotonic_buffer_resource析构时才一次性归还全部内存，无同步开销 - 没有“线程局部 pool”的标准封装，如需 TLV 效果，得配合
thread_local变量手动管理
实际使用时最容易被忽略的陷阱
最隐蔽的问题是：**跨线程传递由该 resource 分配的对象（如 std::pmr::string）后，在另一线程调用 deallocate —— 这是允许的，但必须确保那个线程使用的 resource 实例是同一个对象（而非副本）**。因为 deallocate 需要定位原始 chunk，依赖 resource 实例的内部状态。
另一个坑是混用不同 resource 实例初始化的容器：比如用 A 分配的 std::pmr::vector，却用 B 的 allocator 调用 shrink_to_fit()，这会导致 undefined behavior —— 所有分配器操作必须严格绑定到同一个 std::pmr::polymorphic_allocator 实例（即同一 resource 地址）。
- 永远用
std::pmr::polymorphic_allocator构造容器，而不是保存 resource 指针再动态构造 allocator{&resource} - 避免将
synchronized_pool_resource对象放在栈上并传给异步任务——它可能在任务启动前就析构了 - 调试时注意：ASan/TSan 对 PMR 分配器的支持有限，内存泄漏报告可能指向
upstream而非 pool 本身
