monotonic_buffer_resource 通过指针加法实现O(1)分配，不查链表、不加锁、不处理碎片，但不调用析构函数且deallocate无效；需栈上对齐缓冲、resource生命周期长于容器、单线程使用。
monotonic_buffer_resource 为什么能加速小对象分配
因为它把每次 allocate() 降级为指针加法：内部只维护一个当前偏移量，分配时直接推进指针，不查空闲链表、不加锁、不合并碎片。只要缓冲区够用，就是纯 CPU 指令，比 new 快一个数量级。
但代价也很明确：它不调用析构函数，也不响应 deallocate()；所有对象的生命周期必须严格对齐资源作用域——即“全部一起生，全部一起死”。
- 适合场景：解析器临时节点、AST 构建、一次性的批量计算中间结果
- 不适合场景：需要单独释放某个对象、对象有非平凡析构逻辑（如文件句柄、锁）、生命周期跨多个函数调用
- 初始缓冲建议用栈内存（
alignas对齐的char数组），避免首次分配还走堆
怎么正确构造 monotonic_buffer_resource 避免隐式堆分配
如果构造时不传初始缓冲，std::pmr::monotonic_buffer_resource 会退化为“用上游分配器（默认是 std::pmr::new_delete_resource()）申请第一块缓冲”，等于又绕回了 new，起不到加速效果。
正确做法是显式提供栈或静态缓冲：
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
alignas(std::max_align_t) char buffer[4096]; std::pmr::monotonic_buffer_resource mr(buffer, sizeof(buffer));
- 缓冲大小建议 ≥ 预估峰值内存用量，但不必过大（比如 4KB–64KB 常见）
- 必须用
alignas对齐（通常std::max_align_t），否则allocate()可能返回未对齐指针，触发 UB - 不要把
buffer声明在函数内却返回&mr——缓冲生命周期必须覆盖 resource 使用期
和 pmr 容器配合时，析构顺序容易踩的坑
std::pmr::vector、std::pmr::string 等容器在析构时会先调用元素析构函数，再通过 resource 的 deallocate() 归还内存。但 monotonic_buffer_resource::do_deallocate() 是空操作 —— 所以关键点在于：元素析构函数必须在 resource 销毁前完成。
这意味着你不能依赖“resource 后定义、先销毁”来保证析构顺序：
std::pmr::monotonic_buffer_resource mr{buffer, size};
std::pmr::vector<int> v{&mr}; // OK
// ... use v
// 此时 v 的析构会触发 int 的析构（trivial，无事发生）
// 但若 vector 存的是 std::pmr::string，则 string 析构需访问 mr —— mr 必须还活着
- resource 对象必须比所有使用它的 pmr 容器活得更久
- 最安全写法：resource 定义在作用域开头，容器定义在其后
- 切勿把 resource 包进
std::unique_ptr或提前release()，否则容器析构时可能访问已释放资源
多线程下不加锁就用会出什么问题
std::pmr::monotonic_buffer_resource 明确不是线程安全的：内部偏移量是裸指针或普通整型，没有原子操作封装。多线程并发调用 allocate() 会导致指针撕裂、越界写入、甚至静默数据损坏。
- 绝对不要让多个线程共享同一个
monotonic_buffer_resource实例 - 线程局部方案可行：
thread_local std::pmr::monotonic_buffer_resource mr{...} - 若需跨线程传递数据，只能在单一线程内完成全部分配 + 构造 + 使用，最后整体移交（如通过消息队列传 ownership）
真正棘手的地方往往不在分配本身，而在于对象析构时机与 resource 生命周期的耦合——这没法靠编译器检查，只能靠设计约束和代码审查守住。
