23、移动语义与自定义分配器：移动感知分配器、有状态分配器的移动、分配器与移动操作的交互

分配器这东西，说实话在C++里一直是个「隐形人」。平时写业务代码，你几乎感觉不到它的存在——std::vector帮你管好了内存，你只管往里塞数据就行。但一旦你开始写自己的容器，或者要跟内存池、共享内存、对齐分配这些底层设施打交道，分配器就会突然跳出来，给你上一课。

我个人习惯把分配器分成两类：无状态的和有状态的。无状态分配器就像std::allocator，它不持有任何成员变量，所有实例都是等价的。有状态分配器则不同——它可能持有一个内存池的指针、一个对齐参数、甚至一个线程ID。嗯，问题就出在这里：当你的容器发生移动时，分配器怎么办？

移动感知分配器：为什么需要它？

先看一个最简单的场景。你有一个std::vector<int, MyAlloc>，这个MyAlloc是个有状态分配器，它绑定了某个特定的内存池。现在你要把这个vector移动给另一个对象——分配器也跟着走吗？

C++11之前，标准规定分配器必须是无状态的，或者说所有实例必须「等价」。移动时直接按位拷贝分配器就行，反正都一样。但C++11引入了有状态分配器，事情就复杂了。

标准委员会给出的规则是这样的：

• 如果两个分配器==比较为true，说明它们可以互相释放对方分配的内存。这时候移动操作可以「偷」内存——直接把指针拿过来，不用重新分配。
• 如果!=为true，那就不能偷了。移动会退化为拷贝，因为源分配器分配的内存，目标分配器没法释放。

我在项目中遇到过这样一个坑：写了一个自定义分配器，绑定了线程局部存储的内存池。两个不同线程的分配器实例==返回false。结果一个std::list移动构造时，居然把每个节点都拷贝了一遍。性能直接崩了。

有状态分配器的移动：谁拥有谁？

有状态分配器的移动，其实涉及两个层面：

1. 分配器对象本身的移动——比如你有一个MyAlloc对象，它内部有个shared_ptr<MemoryPool>。移动这个分配器时，指针的所有权转移了。
2. 容器持有分配器的移动——容器移动时，它内部的分配器成员怎么处理？

标准库容器的做法是：移动构造时，分配器从源容器按移动方式获取。也就是说，如果源分配器是可移动的，目标容器会移动构造它的分配器成员。如果不可移动，就拷贝。

你想想看，这会导致什么后果？

假设你的分配器内部有个裸指针指向内存池。移动构造分配器时，你把指针从A移给了B。然后A的指针变成了nullptr。这时候源容器析构——它调用分配器的deallocate——嗯，A的分配器已经是空指针了，deallocate可能什么都不做，或者直接崩掉。

分配器与移动操作的交互：一张图说清楚

下面这张图展示了容器移动时，分配器如何参与决策：

这张图其实揭示了一个关键点：分配器的「等价比对」决定了移动的代价。如果你的分配器设计成所有实例都相等（比如无状态分配器），移动就是O(1)的指针交换。如果不等，移动就变成了O(n)的逐元素拷贝。

代码实战：一个简单的有状态分配器

光说不练假把式。我们写一个简单的有状态分配器，看看移动时到底发生了什么：

template<typename T>
class MyPoolAllocator {
public:
    using value_type = T;
    
    // 有状态：持有一个内存池ID
    explicit MyPoolAllocator(int pool_id) : pool_id_(pool_id) {}
    
    // 移动构造
    MyPoolAllocator(MyPoolAllocator&& other) noexcept
        : pool_id_(other.pool_id_) {
        other.pool_id_ = -1;  // 源分配器失效
    }
    
    // 拷贝构造
    MyPoolAllocator(const MyPoolAllocator& other) noexcept
        : pool_id_(other.pool_id_) {}
    
    T* allocate(std::size_t n) {
        // 从 pool_id_ 对应的内存池分配
        return static_cast<T*>(get_pool(pool_id_)->alloc(n * sizeof(T)));
    }
    
    void deallocate(T* p, std::size_t n) {
        get_pool(pool_id_)->free(p, n * sizeof(T));
    }
    
    // 等价比对：只有相同pool_id才相等
    friend bool operator==(const MyPoolAllocator& a, const MyPoolAllocator& b) {
        return a.pool_id_ == b.pool_id_;
    }
    friend bool operator!=(const MyPoolAllocator& a, const MyPoolAllocator& b) {
        return !(a == b);
    }
    
private:
    int pool_id_ = -1;
};

这段代码里有个细节：移动构造时我把源分配器的pool_id_设成了-1。为什么？因为源容器析构时会调用deallocate，如果它还用原来的pool_id，就会去释放已经被目标容器接管的内存——double free！

分配器traits：控制移动行为的开关

标准库提供了std::allocator_traits，里面有几个静态常量，专门控制分配器在容器移动时的行为：

traits 常量	作用	默认值
propagate_on_container_move_assignment	移动赋值时，是否把源容器的分配器传播给目标	false
propagate_on_container_copy_assignment	拷贝赋值时，是否传播分配器	false
propagate_on_container_swap	swap时，是否交换分配器	false
is_always_equal	所有分配器实例是否总是相等（无状态）	false（有状态分配器应设为false）

这些常量怎么用？在你的分配器类里定义对应的嵌套类型就行：

template<typename T>
class MyAlloc {
public:
    using value_type = T;
    
    // 告诉标准库：移动赋值时传播分配器
    using propagate_on_container_move_assignment = std::true_type;
    
    // 告诉标准库：所有实例不一定相等
    using is_always_equal = std::false_type;
    
    // ... 其他实现
};

我曾经踩过一个坑：写了一个有状态分配器，但忘了定义propagate_on_container_move_assignment。默认是false，结果移动赋值时，目标容器保留了自己的分配器，源容器的内存被「遗弃」了——内存泄漏。嗯，从那以后我每次写分配器，第一件事就是把这几个traits列出来，逐个确认。

移动操作与分配器的交互细节

最后，我们总结一下容器移动时，分配器到底怎么参与：

• 移动构造：目标容器从源容器移动构造分配器。如果is_always_equal为true，直接偷内存。否则，按分配器==结果决定。
• 移动赋值：先释放目标容器原有的内存。如果propagate_on_container_move_assignment为true，把源容器的分配器赋值给目标。然后按分配器等价比对决定偷还是拷贝。
• swap：如果propagate_on_container_swap为true，交换分配器。否则，只交换元素指针——但前提是两个分配器==为true，否则行为未定义。

说实话，分配器这块是C++里比较「硬核」的部分。平时你可能用不到，但一旦用到，就是那种「不出问题还好，一出问题就是内存泄漏、double free、性能崩盘」的级别。我建议你写自定义分配器时，先把标准库容器的移动行为画清楚——就像我上面那张图一样——然后再动手写代码。这样能省下不少调试时间。

---