什么是 ‘Allocator’ (分配器)？利用 `std::pmr` (多态内存资源) 在栈上自定义内存池

在C++编程中，内存管理是一个核心且复杂的话题。作为一名编程专家，我们深知高效、可控的内存管理对于系统性能、资源利用率以及程序稳定性至关重要。标准库容器默认依赖于全局的 operator new 和 operator delete，这在许多情况下是足够的，但对于高性能计算、嵌入式系统、游戏开发或任何需要精细控制内存分配策略的场景，这种默认行为就显得力不从心。

这就是“分配器”（Allocator）概念登场的原因。它提供了一种机制，允许我们自定义内存分配和回收的策略，从而超越标准库的默认行为，实现对内存资源的精细化管理。

什么是 Allocator (分配器)？

从本质上讲，C++中的分配器是一个封装了内存分配和回收逻辑的对象。它充当了容器（如 std::vector, std::list, std::map 等）与底层内存系统之间的桥梁。当一个容器需要存储元素时，它不是直接调用 new 来获取内存，而是通过其内部持有的分配器对象来请求内存。同样，当元素被销毁或容器收缩时，它会通过分配器来释放内存。

std::allocator：默认的选择

C++标准库为所有容器提供了默认的分配器模板类 std::allocator。它的行为非常简单：

• 分配内存：通过 operator new 或 malloc 从堆上获取原始内存。
• 回收内存：通过 operator delete 或 free 将内存返回给堆。
• 构造对象：在已分配的原始内存上调用对象的构造函数（Placement New）。
• 销毁对象：调用对象的析构函数。

例如，当我们声明 std::vector<int> myVec; 时，实际上等价于 std::vector<int, std::allocator<int>> myVec;。

为什么需要自定义分配器？

尽管 std::allocator 易于使用，但它继承了全局 new/delete 的所有优缺点。在许多高级应用场景中，这可能导致以下问题：

1. 性能开销：频繁地进行小对象的堆分配和释放，可能会导致系统调用开销大、内存碎片化严重，从而影响程序性能。全局分配器通常需要进行锁操作以保证线程安全，这在多线程环境下会成为性能瓶颈。
2. 内存碎片化：随着程序的运行，内存可能会变得支离破碎，导致即使有足够的总空闲内存，也无法分配一个连续的大块内存。
3. 资源控制：无法限制特定模块或容器使用的内存总量，难以实现内存池、内存配额等高级资源管理策略。
4. 错误处理：new 操作失败会抛出 std::bad_alloc 异常。自定义分配器可以提供更灵活的错误处理机制，例如返回 nullptr 或使用自定义的错误报告方式。
5. 特殊内存需求：在某些场景下，可能需要从特定的内存区域分配内存，例如共享内存、NUMA架构下的本地内存、或者特定硬件（如GPU）上的内存。std::allocator 无法满足这些需求。
6. 调试与监控：自定义分配器可以集成内存泄漏检测、内存使用统计等调试和监控功能，帮助开发者更好地理解和优化内存行为。

为了解决这些问题，C++标准提供了自定义分配器的能力。在C++17之前，自定义分配器模型相对复杂且不灵活。而C++17引入的 std::pmr (Polymorphic Memory Resources) 极大地简化了这一过程，并提供了更强大、更通用的内存管理框架。

C++11/14 分配器模型：一个历史视角

在C++17 std::pmr 出现之前，自定义分配器需要遵循一套严格的模板接口。一个典型的C++11/14分配器需要：

• 定义 value_type, pointer, const_pointer, reference, const_reference, size_type, difference_type 等类型别名。
• 实现 allocate(size_type n) 方法来分配 n 个 value_type 大小的内存。
• 实现 deallocate(pointer p, size_type n) 方法来释放 p 指向的 n 个 value_type 大小的内存。
• 实现 construct(pointer p, Args&&... args) 和 destroy(pointer p) 方法来在给定内存上构造和销毁对象。
• 实现 max_size() 方法。
• 提供 rebind 模板别名，以便分配器可以为不同类型分配内存。
• 实现 operator== 和 operator!= 进行相等性比较。
• 处理传播特性（propagate_on_container_copy_assignment, propagate_on_container_move_assignment, propagate_on_container_swap）。

这是一个非常冗长且容易出错的模型，最大的痛点在于类型擦除的缺乏。分配器的类型是容器类型的一部分，例如 std::vector<int, MyAllocator<int>>。这意味着如果你有两个 std::vector 对象，即使它们使用相同的底层内存池逻辑，但如果它们的分配器类型不同（例如 MyAllocator<int> 和 MyOtherAllocator<int>），它们也无法直接互操作，甚至无法通过基类指针或引用来统一管理。这限制了多态内存管理的灵活性。

std::pmr (Polymorphic Memory Resources)：C++17 的革新

C++17 引入了 std::pmr 命名空间，提供了一套全新的、基于类型擦除的内存资源管理框架。它通过引入 std::pmr::memory_resource 抽象基类，实现了内存资源的运行时多态性。

核心组件

std::pmr 框架主要由以下几个核心组件构成：

1. std::pmr::memory_resource：
   这是一个抽象基类，定义了内存资源的基本接口。所有自定义的内存资源都必须继承自它并实现其纯虚方法。

   • void* do_allocate(std::size_t bytes, std::size_t alignment)：分配指定字节数和对齐要求的内存。
   • void do_deallocate(void* p, std::size_t bytes, std::size_t alignment)：释放之前由 do_allocate 分配的内存。
   • bool do_is_equal(const memory_resource& other) const noexcept：比较两个内存资源是否相等。

   memory_resource 不知道它要分配什么类型的对象，它只关心原始字节块的分配和释放。这正是类型擦除的关键所在。

2. std::pmr::polymorphic_allocator<T>：
   这是一个模板类，它实现了C++标准分配器的所有要求，但其底层内存分配工作委托给一个 std::pmr::memory_resource 对象。polymorphic_allocator<T> 的类型不再依赖于具体的内存资源实现，而是统一的。这意味着 std::vector<int, std::pmr::polymorphic_allocator<int>> 可以使用任何 std::pmr::memory_resource 实例。

   它的构造函数可以接受一个 memory_resource* 指针。如果没有提供，它会默认使用 std::pmr::get_default_resource() 返回的全局默认内存资源。

3. PMR 感知容器：
   标准库提供了 std::pmr::vector, std::pmr::string, std::pmr::map, std::pmr::unordered_map 等别名，它们是使用 std::pmr::polymorphic_allocator 作为默认分配器模板参数的标准容器。
   例如，std::pmr::vector<int> 实际上是 std::vector<int, std::pmr::polymorphic_allocator<int>>。

4. 预定义内存资源：
   std::pmr 提供了几种开箱即用的内存资源实现：

   • std::pmr::new_delete_resource()：这是默认的内存资源，它使用全局的 operator new 和 operator delete。
   • std::pmr::null_memory_resource()：一个特殊的内存资源，任何分配请求都会抛出 std::pmr::bad_alloc。
   • std::pmr::monotonic_buffer_resource：一种单调增长的缓冲区资源。它从一个更大的上游资源获取内存块，并从这些块中以“bump-pointer”的方式分配内存。它不提供独立的内存释放，所有分配的内存会在资源销毁或 release() 时一起释放。非常适合生命周期一致的临时对象。
   • std::pmr::synchronized_pool_resource 和 std::pmr::unsynchronized_pool_resource：这两种是内存池资源。它们从上游资源获取内存块，并将其组织成不同大小的池，以高效地满足小对象的分配请求。synchronized_pool_resource 是线程安全的，而 unsynchronized_pool_resource 则不是。

5. 默认内存资源管理：

   • std::pmr::set_default_resource(memory_resource* r)：设置全局默认的内存资源。
   • std::pmr::get_default_resource()：获取当前全局默认的内存资源。

std::pmr 的优势

• 运行时多态：std::pmr::polymorphic_allocator 可以在运行时绑定到任何 memory_resource 实现，无需改变容器的类型。这使得内存管理策略可以动态切换。
• 简化自定义分配器：开发者只需继承 memory_resource 并实现三个 do_ 方法，而无需处理C++11/14模型中繁琐的类型别名和 rebind 逻辑。
• 更高层次的抽象：memory_resource 专注于原始内存块的管理，而 polymorphic_allocator 专注于对象构造/销毁，职责分离更清晰。
• 与标准库容器无缝集成：通过 std::pmr::vector 等别名，可以轻松地将自定义内存资源应用于标准库容器。

设计和实现一个自定义栈上内存池 (Stack-Based Memory Pool)

现在，让我们利用 std::pmr 框架来设计并实现一个自定义的栈上内存池。这种内存池通常被称为“栈分配器”或“碰头分配器”（bump allocator），因为它只是简单地“碰”一下内部指针来分配内存。

栈分配器的概念

原理：栈分配器从一个预先分配好的固定大小的缓冲区（通常是在栈上或全局静态存储区）中顺序分配内存。它内部维护一个“当前指针”，每次分配时，指针向前移动相应的字节数并返回当前指针的旧值。

优点：

• 极快：分配操作通常只是一个简单的指针加法和边界检查，没有复杂的搜索或锁。
• 无碎片：内存总是从缓冲区的起始处连续分配，不会产生外部碎片。
• 适用于短生命周期对象：非常适合在特定作用域内（如函数调用栈帧）分配大量临时对象，这些对象在作用域结束时可以一次性全部释放。

缺点：

• 无法单独释放：通常不支持释放缓冲区中间的某个特定内存块。所有分配的内存通常在分配器被销毁或显式 reset() 时一次性释放。
• 固定大小：缓冲区大小在创建时确定，无法动态增长。如果请求的内存超出缓冲区容量，分配会失败。
• LIFO/全部释放模式：最常见的模式是所有分配的内存一起释放（通过 reset() 或销毁对象）。如果需要LIFO（后进先出）的单个释放，实现会复杂得多，且通常不作为通用的 pmr::memory_resource 实现。

我们的 StackMemoryResource 设计

我们将实现一个简单的栈分配器，它将从一个预先提供的 char 数组中分配内存。由于 std::pmr::memory_resource 要求 do_deallocate 存在，但我们的栈分配器不支持中间的单独释放，所以 do_deallocate 将会是一个空操作，并假定内存会在资源生命周期结束时自动回收，或者通过显式的 reset() 方法来“释放”所有内存。这种行为类似于 std::pmr::monotonic_buffer_resource。

StackMemoryResource 类的结构

#include <iostream>
#include <vector>
#include <string>
#include <map>
#include <array>
#include <memory> // For std::align
#include <cstdint> // For uintptr_t
#include <stdexcept> // For std::bad_alloc
#include <numeric> // For std::iota

// C++17 PMR 命名空间
namespace pmr = std::pmr;

// 辅助函数：将指针向上对齐到最近的倍数
// params:
//   ptr: 原始指针
//   alignment: 对齐字节数 (必须是2的幂)
// returns: 对齐后的指针
void* align_ptr(void* ptr, std::size_t alignment) noexcept {
    // 将指针转换为整数类型，便于位操作
    auto iptr = reinterpret_cast<uintptr_t>(ptr);
    // 计算需要填充多少字节才能达到对齐要求
    // (alignment - (iptr % alignment)) % alignment
    // 等价于 (alignment - (iptr & (alignment - 1))) & (alignment - 1)
    // 这是更高效的位操作版本，因为 alignment 总是2的幂
    auto aligned_iptr = (iptr + alignment - 1) & ~(alignment - 1);
    return reinterpret_cast<void*>(aligned_iptr);
}

// 获取两个内存地址之间的字节差
std::size_t ptr_diff(const void* p1, const void* p2) noexcept {
    return static_cast<std::size_t>(reinterpret_cast<const char*>(p1) - reinterpret_cast<const char*>(p2));
}

// 自定义栈内存资源
class StackMemoryResource : public pmr::memory_resource {
public:
    // 构造函数：接受一个预分配的缓冲区及其大小
    // buffer: 指向缓冲区的起始地址
    // buffer_size: 缓冲区的总大小（字节）
    explicit StackMemoryResource(void* buffer, std::size_t buffer_size) noexcept
        : _buffer_start(static_cast<char*>(buffer)),
          _buffer_end(_buffer_start + buffer_size),
          _current_ptr(_buffer_start) {
        std::cout << "[StackMemoryResource] Initialized with buffer size: " << buffer_size << " bytes.n";
    }

    // 禁用拷贝构造和赋值，因为内存资源通常不应该被拷贝
    StackMemoryResource(const StackMemoryResource&) = delete;
    StackMemoryResource& operator=(const StackMemoryResource&) = delete;

    // 获取当前已分配的字节数
    std::size_t bytes_allocated() const noexcept {
        return ptr_diff(_current_ptr, _buffer_start);
    }

    // 获取缓冲区剩余的字节数
    std::size_t bytes_remaining() const noexcept {
        return ptr_diff(_buffer_end, _current_ptr);
    }

    // 重置分配器，将当前指针重置到缓冲区起始，从而“释放”所有已分配的内存
    void reset() noexcept {
        _current_ptr = _buffer_start;
        std::cout << "[StackMemoryResource] Reset. All allocated memory is now available.n";
    }

protected:
    // 核心分配逻辑
    // bytes: 请求分配的字节数
    // alignment: 请求的内存对齐字节数
    void* do_allocate(std::size_t bytes, std::size_t alignment) override {
        // 1. 计算对齐后的起始地址
        void* aligned_start = align_ptr(_current_ptr, alignment);

        // 2. 检查是否有足够的空间
        // 计算从 _current_ptr 到 aligned_start 需要填充的字节数
        std::size_t padding = ptr_diff(aligned_start, _current_ptr);
        std::size_t total_needed = padding + bytes;

        if (total_needed > bytes_remaining()) {
            std::cerr << "[StackMemoryResource] Allocation failed: Not enough memory."
                      << " Requested: " << bytes << " bytes (aligned to " << alignment << "), "
                      << " but only " << bytes_remaining() << " bytes remaining.n";
            throw pmr::bad_alloc(); // 抛出 bad_alloc 异常表示内存不足
        }

        // 3. 更新 _current_ptr
        _current_ptr = static_cast<char*>(aligned_start) + bytes;

        std::cout << "[StackMemoryResource] Allocated " << bytes << " bytes (aligned to " << alignment
                  << ") at address " << aligned_start << ". Current usage: " << bytes_allocated()
                  << " bytes.n";
        return aligned_start;
    }

    // 核心释放逻辑
    // 对于一个简单的栈分配器，我们不支持中间的单个释放。
    // 内存将在 StackMemoryResource 对象被销毁或调用 reset() 时一次性回收。
    // 因此，do_deallocate 在这里是一个空操作。
    void do_deallocate(void* p, std::size_t bytes, std::size_t alignment) override {
        // 在实际应用中，如果需要验证 deallocate 的调用，可以在这里添加日志或断言
        // 但对于一个简单的 bump allocator，它通常是 no-op
        std::cout << "[StackMemoryResource] Deallocate called for " << bytes << " bytes at " << p
                  << ". (No-op for stack allocator).n";
        // 注意：这里没有将 _current_ptr 倒退，因为这会破坏后续的分配。
        // 只有 reset() 才能完全清空。
    }

    // 比较两个内存资源是否相等
    // 对于 StackMemoryResource，只有当它们是同一个对象时才相等
    bool do_is_equal(const pmr::memory_resource& other) const noexcept override {
        return this == &other;
    }

private:
    char* _buffer_start;  // 缓冲区的起始地址
    char* _buffer_end;    // 缓冲区的结束地址（_buffer_start + buffer_size）
    char* _current_ptr;   // 当前分配指针，指向下一个可用的内存位置
};

代码解释

1. align_ptr 辅助函数：这是一个非常关键的函数，用于确保返回的内存地址满足请求的对齐要求。例如，如果请求一个 int（通常是4字节对齐），而 _current_ptr 指向的地址是奇数，它会向前移动直到找到一个4的倍数的地址。

   • uintptr_t：将 void* 转换为整数类型，方便进行算术和位操作。
   • aligned_iptr = (iptr + alignment - 1) & ~(alignment - 1);：这是一个经典的位操作技巧，用于将任何整数向上对齐到 alignment 的倍数（alignment 必须是2的幂）。

2. ptr_diff 辅助函数：计算两个指针之间的字节差异。

3. StackMemoryResource 构造函数：

   • 接收 void* buffer 和 std::size_t buffer_size。这允许我们传入任何预分配的内存块，包括栈上的 char 数组。
   • 初始化 _buffer_start, _buffer_end, _current_ptr。

4. bytes_allocated() 和 bytes_remaining()：提供当前内存使用情况的查询接口。

5. reset() 方法：

   • 这是栈分配器特有的方法。它通过将 _current_ptr 重置回 _buffer_start 来“释放”所有已分配的内存。请注意，这只是逻辑上的释放，实际数据可能仍然存在于缓冲区中，直到被新数据覆盖。

6. do_allocate(std::size_t bytes, std::size_t alignment)：

   • 首先调用 align_ptr 来计算满足对齐要求的起始地址。
   • 计算从 _current_ptr 到 aligned_start 需要填充的字节数（padding）。
   • 计算总共需要的内存（padding + bytes）。
   • 边界检查：检查剩余空间是否足够。如果不足，则抛出 std::pmr::bad_alloc 异常。这是 pmr::memory_resource 报告分配失败的标准方式。
   • 如果空间足够，更新 _current_ptr 到新的分配结束位置。
   • 返回 aligned_start。

7. *`do_deallocate(void p, std::size_t bytes, std::size_t alignment)`**：

   • 如前所述，对于一个简单的栈分配器，此方法是一个空操作（no-op）。它不实际释放内存，也不回退 _current_ptr。这使得它适用于那些生命周期与资源本身绑定的对象，或者那些在资源 reset() 时一次性清理的场景。我们添加了日志输出以明确其被调用但无实际操作的行为。

8. do_is_equal(const pmr::memory_resource& other) const noexcept：

   • 对于大多数自定义内存资源，当且仅当 *this 和 other 指向同一个对象时，它们才被认为是相等的。这是 pmr::memory_resource 的常见实现。

示例用法

现在，我们将演示如何使用 StackMemoryResource 与 std::pmr 感知容器。

// 主函数示例
int main() {
    std::cout << "--- StackMemoryResource Example ---nn";

    // 1. 在栈上创建一个固定大小的缓冲区
    constexpr std::size_t BUFFER_SIZE = 1024 * 4; // 4KB
    alignas(std::max_align_t) std::array<char, BUFFER_SIZE> buffer_array; // 使用 std::array 确保内存连续且在栈上

    // 2. 实例化我们的自定义内存资源
    StackMemoryResource stack_mr(buffer_array.data(), buffer_array.size());

    // 3. 创建一个 std::pmr::polymorphic_allocator 实例，并将其绑定到我们的栈内存资源
    // polymorphic_allocator<T> 是类型无关的，它只是 memory_resource 的一个代理
    pmr::polymorphic_allocator<int> int_allocator(&stack_mr);
    pmr::polymorphic_allocator<char> char_allocator(&stack_mr);
    pmr::polymorphic_allocator<std::string> string_allocator(&stack_mr);

    std::cout << "n--- Using pmr::vector<int> ---n";
    {
        // 4. 使用 PMR 感知容器
        // pmr::vector 接受一个 polymorphic_allocator 作为构造函数参数
        pmr::vector<int> vec_int(int_allocator);

        std::cout << "Pushing 100 ints into pmr::vector...n";
        for (int i = 0; i < 100; ++i) {
            vec_int.push_back(i);
        }
        std::cout << "Vector size: " << vec_int.size() << ", capacity: " << vec_int.capacity() << "n";
        std::cout << "StackMemoryResource usage after vec_int: " << stack_mr.bytes_allocated() << " bytes.n";

        // vec_int 离开作用域时，其析构函数会通过 int_allocator 释放内存
        // int_allocator 会调用 stack_mr.do_deallocate，但我们的 do_deallocate 是 no-op
    } // vec_int 析构，do_deallocate 被调用

    std::cout << "n--- Using pmr::string ---n";
    {
        pmr::string pmr_str("Hello, PMR World! This string uses our custom stack allocator.", char_allocator);
        std::cout << "PMR String: " << pmr_str << ", length: " << pmr_str.length() << "n";
        std::cout << "StackMemoryResource usage after pmr_str: " << stack_mr.bytes_allocated() << " bytes.n";

        pmr_str += " Appending more text to trigger reallocation.";
        std::cout << "PMR String (appended): " << pmr_str << ", length: " << pmr_str.length() << "n";
        std::cout << "StackMemoryResource usage after pmr_str (reallocated): " << stack_mr.bytes_allocated() << " bytes.n";
    } // pmr_str 析构，do_deallocate 被调用

    std::cout << "n--- Demonstrating reset() and reuse ---n";
    // 此时 stack_mr 的 bytes_allocated() 仍然显示之前分配的内存量，
    // 因为 do_deallocate 是 no-op。
    // 只有 reset() 才能真正“清空”逻辑使用。
    std::cout << "Current StackMemoryResource usage before reset: " << stack_mr.bytes_allocated() << " bytes.n";
    stack_mr.reset(); // 重置栈分配器，使其可以重新使用整个缓冲区
    std::cout << "StackMemoryResource usage after reset: " << stack_mr.bytes_allocated() << " bytes.n";

    {
        // 重新使用分配器分配新的对象
        pmr::vector<double> vec_double(string_allocator); // 注意：这里使用了 string_allocator，但 polymorphic_allocator 是类型擦除的，底层都指向 stack_mr
        std::cout << "Pushing 50 doubles into pmr::vector (after reset)...n";
        for (int i = 0; i < 50; ++i) {
            vec_double.push_back(static_cast<double>(i) / 2.0);
        }
        std::cout << "Vector size: " << vec_double.size() << ", capacity: " << vec_double.capacity() << "n";
        std::cout << "StackMemoryResource usage after vec_double: " << stack_mr.bytes_allocated() << " bytes.n";
    } // vec_double 析构，do_deallocate 被调用

    std::cout << "n--- Demonstrating allocation failure ---n";
    std::cout << "Remaining buffer space: " << stack_mr.bytes_remaining() << " bytes.n";
    try {
        // 尝试分配一个超出当前剩余空间的巨大内存块
        std::size_t large_request = stack_mr.bytes_remaining() + 100;
        std::cout << "Attempting to allocate " << large_request << " bytes...n";
        // 注意，即使是 pmr::vector，当它需要内存时，最终也是调用 memory_resource 的 do_allocate
        pmr::vector<char> big_vec(large_request, char_allocator); // 尝试构造一个大的vector
        std::cout << "Successfully allocated " << big_vec.size() << " chars. (Should not happen)n";
    } catch (const pmr::bad_alloc& e) {
        std::cerr << "Caught expected exception: " << e.what() << "n";
    }
    std::cout << "StackMemoryResource usage after failed allocation attempt: " << stack_mr.bytes_allocated() << " bytes.n";

    std::cout << "n--- Final StackMemoryResource usage: " << stack_mr.bytes_allocated() << " bytes ---n";
    // stack_mr 对象在 main 函数结束时销毁，其底层的 buffer_array 也会随之销毁
    return 0;
}

示例输出分析 (部分)

--- StackMemoryResource Example ---

[StackMemoryResource] Initialized with buffer size: 4096 bytes.

--- Using pmr::vector<int> ---
Pushing 100 ints into pmr::vector...
[StackMemoryResource] Allocated 24 bytes (aligned to 8) at address 0x...00. Current usage: 24 bytes. // Initial capacity, often small, e.g., 3 ints
[StackMemoryResource] Allocated 40 bytes (aligned to 8) at address 0x...18. Current usage: 64 bytes. // Reallocation
[StackMemoryResource] Allocated 80 bytes (aligned to 8) at address 0x...40. Current usage: 144 bytes. // Reallocation
[StackMemoryResource] Allocated 160 bytes (aligned to 8) at address 0x...90. Current usage: 304 bytes. // Reallocation
[StackMemoryResource] Allocated 320 bytes (aligned to 8) at address 0x...130. Current usage: 624 bytes. // Reallocation
Vector size: 100, capacity: 100
StackMemoryResource usage after vec_int: 624 bytes.
[StackMemoryResource] Deallocate called for 320 bytes at 0x...130. (No-op for stack allocator).
[StackMemoryResource] Deallocate called for 160 bytes at 0x...90. (No-op for stack allocator).
[StackMemoryResource] Deallocate called for 80 bytes at 0x...40. (No-op for stack allocator).
[StackMemoryResource] Deallocate called for 40 bytes at 0x...18. (No-op for stack allocator).
[StackMemoryResource] Deallocate called for 24 bytes at 0x...00. (No-op for stack allocator).

--- Using pmr::string ---
[StackMemoryResource] Allocated 64 bytes (aligned to 1) at address 0x...270. Current usage: 688 bytes.
PMR String: Hello, PMR World! This string uses our custom stack allocator., length: 61
StackMemoryResource usage after pmr_str: 688 bytes.
[StackMemoryResource] Allocated 128 bytes (aligned to 1) at address 0x...2b0. Current usage: 816 bytes.
[StackMemoryResource] Deallocate called for 64 bytes at 0x...270. (No-op for stack allocator).
PMR String (appended): Hello, PMR World! This string uses our custom stack allocator. Appending more text to trigger reallocation., length: 110
StackMemoryResource usage after pmr_str (reallocated): 816 bytes.
[StackMemoryResource] Deallocate called for 128 bytes at 0x...2b0. (No-op for stack allocator).

--- Demonstrating reset() and reuse ---
Current StackMemoryResource usage before reset: 816 bytes.
[StackMemoryResource] Reset. All allocated memory is now available.
StackMemoryResource usage after reset: 0 bytes.
Pushing 50 doubles into pmr::vector (after reset)...
[StackMemoryResource] Allocated 40 bytes (aligned to 8) at address 0x...00. Current usage: 40 bytes.
[StackMemoryResource] Allocated 80 bytes (aligned to 8) at address 0x...28. Current usage: 120 bytes.
[StackMemoryResource] Allocated 400 bytes (aligned to 8) at address 0x...78. Current usage: 520 bytes.
Vector size: 50, capacity: 50
StackMemoryResource usage after vec_double: 520 bytes.
[StackMemoryResource] Deallocate called for 400 bytes at 0x...78. (No-op for stack allocator).
[StackMemoryResource] Deallocate called for 80 bytes at 0x...28. (No-op for stack allocator).
[StackMemoryResource] Deallocate called for 40 bytes at 0x...00. (No-op for stack allocator).

--- Demonstrating allocation failure ---
Remaining buffer space: 3576 bytes.
Attempting to allocate 3676 bytes...
[StackMemoryResource] Allocation failed: Not enough memory. Requested: 3676 bytes (aligned to 1), but only 3576 bytes remaining.
Caught expected exception: std::pmr::bad_alloc
StackMemoryResource usage after failed allocation attempt: 520 bytes.

--- Final StackMemoryResource usage: 520 bytes ---

从输出中我们可以清楚地看到：

• 内存资源初始化时报告了总大小。
• 每次 pmr::vector 或 pmr::string 内部需要内存时，都会调用 StackMemoryResource::do_allocate，并且日志会显示分配的字节数、对齐要求和当前使用量。
• 当容器析构时，它们会调用 StackMemoryResource::do_deallocate，但我们的实现打印了“No-op”信息，表明它没有实际释放单个内存块。因此 bytes_allocated() 的值在 deallocate 调用后保持不变。
• stack_mr.reset() 方法将 bytes_allocated() 重置为0，允许我们从头开始重新使用整个缓冲区，这对于管理临时作用域内存非常有用。
• 当请求的内存超过 StackMemoryResource 的容量时，do_allocate 会抛出 std::pmr::bad_alloc 异常，并被 try-catch 块捕获。

高级话题与考虑

对齐要求的重要性

在 do_allocate 中处理 alignment 参数至关重要。不同的数据类型有不同的对齐要求（例如，int 可能需要4字节对齐，double 可能需要8字节对齐，某些结构体可能需要更大的对齐）。如果分配的内存地址没有正确对齐，可能会导致：

• 性能下降：CPU访问未对齐的数据通常比访问对齐数据慢。
• 程序崩溃：在某些处理器架构上，访问未对齐的数据会直接导致硬件异常。
  std::pmr::memory_resource 的 do_allocate 接口明确要求我们处理对齐，这强制了正确的内存管理实践。

线程安全

我们实现的 StackMemoryResource 是非线程安全的。如果多个线程同时尝试从同一个 StackMemoryResource 实例分配内存，它们可能会同时修改 _current_ptr，导致数据竞争和未定义行为。

要使其线程安全，我们需要在 do_allocate 和 reset 方法中添加同步机制，例如使用 std::mutex：

#include <mutex> // For std::mutex

class ThreadSafeStackMemoryResource : public pmr::memory_resource {
    // ... (其他成员与 StackMemoryResource 相同)

protected:
    void* do_allocate(std::size_t bytes, std::size_t alignment) override {
        std::lock_guard<std::mutex> lock(_mtx); // 保护 _current_ptr 的访问
        // ... (与 StackMemoryResource::do_allocate 相同的逻辑)
    }

    void do_deallocate(void* p, std::size_t bytes, std::size_t alignment) override {
        // 对于 no-op 的 deallocate，通常不需要锁
        // 但如果 deallocate 有实际逻辑，也需要考虑线程安全
    }

    void reset() noexcept {
        std::lock_guard<std::mutex> lock(_mtx); // 保护 _current_ptr 的访问
        _current_ptr = _buffer_start;
        // ...
    }

private:
    std::mutex _mtx; // 互斥锁
    // ... (其他私有成员与 StackMemoryResource 相同)
};

或者，我们可以利用 std::pmr::synchronized_pool_resource 和 std::pmr::unsynchronized_pool_resource，它们提供了内置的线程安全选项。

错误处理

当内存分配失败时，std::pmr::memory_resource::do_allocate 必须抛出 std::pmr::bad_alloc 异常。这是 std::pmr 框架的标准行为，允许上层容器和应用程序以统一的方式处理内存不足的情况。

memory_resource 对象的生命周期管理

std::pmr::memory_resource 实例必须在其所服务的任何容器和对象之前创建，并在此容器和对象销毁之后才能销毁。在我们的示例中，stack_mr 对象在 main 函数的栈上创建，其生命周期覆盖了所有使用它的 pmr::vector 和 pmr::string 实例，因此这是正确的。

选择合适的 std::pmr 资源

选择合适的内存资源对于性能至关重要：

• std::pmr::new_delete_resource()：作为默认资源，适用于大多数通用场景，无需特殊优化。
• std::pmr::monotonic_buffer_resource：与我们自定义的 StackMemoryResource 类似，适用于大量临时对象，这些对象在某个作用域结束后可以一起释放。它从上游资源获取内存块，因此可以动态增长（虽然每个块的大小是固定的）。
• std::pmr::synchronized_pool_resource / std::pmr::unsynchronized_pool_resource：适用于频繁分配和释放大小相似的小对象，能有效减少内存碎片和提高分配速度。 synchronized 版本提供线程安全，但有锁开销。
• 自定义资源：当上述标准资源无法满足特定需求时（如特定硬件内存、复杂策略），才需要自定义。

性能考量

自定义分配器的主要驱动力之一是性能。为了评估其效果，需要进行严格的性能测试和分析。这通常涉及：

• 基准测试：比较使用 std::allocator 和自定义分配器在相同工作负载下的执行时间。
• 内存使用分析：监控内存池的填充率、碎片化程度。
• 缓存行为：考虑分配器对CPU缓存的影响，例如，局部性更好的分配器可以提高缓存命中率。

例如，对于我们实现的 StackMemoryResource，其 do_allocate 操作是 O(1) 的，非常快。但 do_deallocate 的无操作特性意味着内存不会立即返回给系统或池，这限制了它的适用场景。

最佳实践

1. 优先使用 std::pmr 容器：当需要自定义内存管理时，尽可能使用 std::pmr::vector、std::pmr::string 等 PMR 感知容器，它们能与 std::pmr 框架无缝集成。
2. 明确资源所有权：确保 std::pmr::memory_resource 对象的生命周期正确管理，它必须在所有使用它的容器和对象之前存在，并在它们之后销毁。
3. 合理选择上游资源：如果自定义资源需要从更大的内存源获取内存（如 monotonic_buffer_resource），请仔细选择其上游资源。
4. 避免过度工程：只有当 std::allocator 或现有的 std::pmr 资源不能满足性能、控制或特殊硬件要求时，才考虑自定义内存资源。
5. 彻底测试：自定义内存资源是底层基础设施，必须经过全面的单元测试和集成测试，以确保其正确性、健壮性和性能。

std::pmr 框架是C++17在内存管理方面的一项重大改进，它通过引入类型擦除的 memory_resource 和 polymorphic_allocator，为开发者提供了强大而灵活的工具，以实现高效、可控的内存管理策略。理解并熟练运用这一框架，是成为一名 C++ 专家的重要一环。