为什么 Arena 分配器能避免 GC？
因为 Arena 不做单对象释放，只支持批量归还——所有 malloc 来的内存块在生命周期结束时一次性 free，中间不调用 delete 或析构单个对象。C++ 本身没有 GC，所谓“Zero-GC”其实是规避了频繁 new/delete 带来的堆管理开销和碎片，不是绕过语言机制，而是放弃细粒度生命周期管理。
关键约束：所有分配的对象必须同生共死，或至少按 Arena 的销毁顺序分组；不能在 Arena 中存裸指针到外部堆内存并期望自动清理。
怎么写一个线程本地的 Arena 分配器？
核心是用 std::vector<:byte></:byte> 管理一块连续内存，配合指针游标 m_ptr 和上限 m_end。每次 allocate() 只做指针偏移，无锁、无系统调用。
-
alignas必须显式处理：分配前用std::align调整m_ptr，否则new (ptr) T可能崩溃 - 扩容策略别用
realloc：它可能移动内存，导致已有指针失效；应std::vector::reserve预留空间，或换用mmap+mprotect实现可扩展虚拟内存区 - 构造/析构要手动控制：Arena 通常不调用析构函数；若需，得额外维护对象类型和地址列表，在
reset()时反向遍历调用
class Arena {
std::vector<std::byte> m_storage;
std::byte* m_ptr = nullptr;
std::byte* m_end = nullptr;
<p>public:
void* allocate(size_t size, size_t align = alignof(std::max_align_t)) {
if (!std::align(align, size, m_ptr, m_end - m_ptr)) {
// 触发扩容或抛异常
throw std::bad_alloc{};
}
auto p = m_ptr;
m_ptr += size;
return p;
}
};</p>std::pmr::polymorphic_allocator 怎么和 Arena 配合？
直接包装 Arena 成 std::pmr::memory_resource 子类，就能让 std::pmr::vector、std::pmr::string 等容器自动走 Arena 分配路径，不用改业务逻辑。
立即学习“C++免费学习笔记（深入）”；
- 必须重载
do_allocate/do_deallocate：后者通常空实现（Arena 不支持单对象回收），但do_deallocate仍需接收参数，否则链接失败 - 注意
std::pmr::memory_resource::is_equal：两个 Arena 实例默认不等，影响容器 move 后的资源归属判断 - 别把 Arena 对象放在栈上再传给
std::pmr::polymorphic_allocator：生命周期错位会导致allocate()访问已销毁内存
哪些场景一用就崩？
Arena 是银弹的反面：它把内存管理责任从运行时推给了程序员，错误会延迟暴露。
- 跨 Arena 指针引用：A1 分配的对象内部存了指向 A2 的指针，A2 先销毁 → 悬垂指针，ASan 可能不报（没越界）
- 误用
new：写了new (arena.allocate(sizeof(T))) T{}却忘了T析构函数有副作用，且 Arena 不负责调用 → 资源泄漏（如文件句柄、GPU memory） - STL 容器迭代器失效：用
std::pmr::vector在 Arena 中，push_back触发扩容时若底层 resource 抛异常，迭代器全失效，且无法回滚 - 调试困难：AddressSanitizer 默认不检查 Arena 内部越界，需配合
__asan_poison_memory_region手动标记未用区域
最常被忽略的一点：Arena 不解决对象图生命周期嵌套问题。比如一个请求里创建子任务，子任务需要独立内存段——这时候得用嵌套 Arena，而不是一个全局大块。
