C++ PMR 里的“空气”：详解 null_memory_resource 的正确姿势

写代码读到别人项目里的智能指针时，偶尔会撞见一个名为 null_memory_resource 的怪名字。很多新人一眼以为是 C++17 或 C++20 的新标准特性，赶紧去查手册才发现文档里根本没有这一项。

这其实是很多资深开发者私下约定的一种模式。

在 C++ 的《memory_resource》体系中，虽然标准库没有预置叫这个名字的类，但它在测试和特定场景下的价值并不输给任何原生资源。所谓“空操作资源”，本质是一个伪装成分配器的桩对象。它的核心任务很简单：要么拒绝分配，要么忽略释放。

这种设计通常用来解决两类棘手问题。第一是单元测试中的内存追踪。当我们要验证某个模块是否真的发生了内存泄漏时，可以注入一个特殊的内存资源。一旦代码试图申请堆内存，它就立刻抛出异常。这样，凡是跑不通的逻辑，往往就是泄露的源头。第二是功能降级时的占位符。在某些系统资源受限的环境（如嵌入式启动阶段），我们需要一种“无状态”的资源来暂时充当默认参数，确保代码能编译通过而不触发真实的系统调用。

实现这样一个资源非常简单，只需继承 std::pmr::memory_resource 并重写两个核心接口。重点在于 do_allocate 函数的处理策略。为了安全起见，建议直接抛出 std::bad_alloc。如果仅仅返回一个空指针，上层逻辑可能会误以为成功并解引用，引发更隐蔽的崩溃。

class NullResource : public std::pmr::memory_resource {
protected:
    void* do_allocate(std::size_t bytes, std::size_t alignment) override {
        // 拒绝所有分配请求，强制程序停止
        throw std::bad_alloc();
    }
    void do_deallocate(void* p, std::size_t, std::size_t) override {
        // 什么都不做，或者根据需求记录调用日志
        (void)p; 
    }
};

有了这个类，你可以通过模板参数将其传递给 std::pmr::vector 或 std::pmr::string。这种显式的依赖注入比隐式的系统默认行为更易控。当你把实例传给多态分配器时，所有的动态内存行为就被锁定在了你的规则之内。

不过这里有个常见的坑需要注意：不要把 nullptr 直接当作内存资源使用。

很多函数接收的是 std::pmr::memory_resource*，有人图省事传了空指针。这会直接导致运行时错误，因为底层实现通常会解引用它。正确的做法是使用上面提到的自定义实例，或者在特殊情况下使用标准的 system_memory_resource 作为兜底。空资源的意义在于“受控的失败”，而不是“未定义的崩溃”。

说到底，null_memory_resource 代表的是一种防御性编程思维。它不是让你偷懒不用内存管理，而是让你在必要时拥有随时切断资源通路的能力。在排查复杂并发竞争导致的资源死锁时，这种能让内存申请“立即熔断”的工具，往往比昂贵的调试器来得更有效率。