优先用 std::vector，但必须配合 reserve() 预分配；std::deque 因分段存储破坏内存局部性，导致 tlb miss 上升，回收更慢。
对象池该用 std::vector 还是 std::deque 存储空闲对象？
直接说结论：优先用 std::vector，但必须配合 reserve() 预分配；std::deque 表面“自动扩容友好”，实际会破坏内存局部性，反而拖慢回收速度。
常见错误是只管 push/pop，不控制内存布局。对象池的核心价值之一就是缓存行友好——新分配的实例大概率和刚释放的在相邻地址。而 std::deque 的分段式存储会让 pop 出来的对象分散在不同内存页，下一次 construct 时 TLB miss 明显上升。
-
std::vector+reserve(N)后，所有空闲对象连续存放，back()/pop_back()是纯指针偏移，无分支、无锁（单线程场景） - 如果预估容量波动大，改用
std::vector<:unique_ptr>></:unique_ptr>，但注意多一层解引用开销 - 绝对不要用
std::list：每个节点单独new，池的意义直接归零
如何避免构造/析构逻辑被编译器优化掉？
对象池里反复复用对象，意味着不能依赖构造函数初始化，也不能靠析构函数清理——但 c++17 起，如果 T 有非平凡析构函数，编译器可能把 placement new 后的默认构造当成冗余操作给干掉。
典型现象：对象字段残留上次使用时的脏值，调试时发现 obj->x 居然不是 0。
立即学习“C++免费学习笔记（深入）”；
- 必须显式调用
T::T()构造函数（即 placement new 后立即构造），且禁止给T加[[no_unique_address]]或trivial标签误导编译器 - 析构函数不能省：每次归还前必须显式调用
obj->~T()，哪怕它啥也不做——这是告诉编译器“此处生命周期结束”，否则后续 placement new 可能被重排或跳过 - 若
T有std::String成员，别指望 move 构造自动清空；得在reset()方法里手动.clear()或.shrink_to_fit()
多线程下 std::stack + std::mutex 性能崩在哪？
单个互斥量保护整个空闲链表，高并发时所有线程排队等锁，吞吐量随核数增加反而下降。
这不是锁粒度问题，而是设计误判：对象池的典型模式是“一借一还”，极少出现借光了等新对象的情况。所以更适合用无锁结构。
- 真要手写无锁栈，用
std::atomic<t></t>+ CAS 实现 LIFO，但注意 ABA 问题——推荐直接用boost::lockfree::stack（若允许第三方依赖） - 更轻量的折中：按线程 ID 分桶，每个线程独占一个
std::stack<t></t>，跨线程借用时才走全局池，用std::shared_mutex控制全局访问 - 别信“
std::mutex很快”的说法：在 32 核机器上，单 mutex 池的 QPS 常比分桶方案低 5–8 倍
new T[100] 分配大块内存后怎么安全切分成对象？
直接 reinterpret_cast<t>(ptr)</t> 然后循环 placement new 是错的——没考虑对齐要求，尤其当 T 含 std::max_align_t 成员（如 std::optional<double></double>）时，地址可能未对齐，触发 std::bad_alloc 或 UB。
正确做法是用 std::align() 手动对齐：
- 先
operator new(size * sizeof(T) + alignof(T))分配原始内存 - 再用
std::align(alignof(T), sizeof(T), ptr, space)对每个位置校准 - 每次对齐后检查返回值是否非空，失败则跳过该 slot（说明剩余空间不够对齐）
容易忽略的是：即使你用 alignof(T) 对齐了首地址，后续每个 sizeof(T) 步进仍可能越界——因为 sizeof(T) 不一定等于 alignof(T)，中间会有填充。所以必须用 std::aligned_storage_t 或 C++23 的 std::assume_aligned 辅助验证。
对象池最难的从来不是怎么分配，而是怎么让编译器相信“这个内存确实属于 T 的生命周期”，又不让它自作聪明优化掉关键步骤。