C++ 内存泄漏全解析：常见场景、成因与规避实践

一、什么是内存泄漏

内存泄漏（Memory Leak）指程序在堆上申请的内存，在不再使用之后没有被释放，导致这部分内存既无法被程序再次使用，也无法归还给操作系统。对于长期运行的服务端程序，内存泄漏会随着时间不断累积，最终表现为内存占用持续上涨、响应变慢，甚至被 OOM Killer 杀掉进程。

在 C++ 中，内存管理是手动的（虽然有智能指针等工具辅助），因此内存泄漏的成因往往集中在「谁申请、谁释放」这条责任链断裂上。下面按场景分类，逐一分析常见的泄漏来源。

二、场景一：new 之后忘记 delete

最直接的一类泄漏。使用 new 或 new[] 分配内存后，没有对应的 delete 或 delete[]。

cpp 复制代码

void leak() {
    int* p = new int(42);
    // 忘记 delete p;
    // 函数返回后，p 这个指针本身销毁了，但它指向的堆内存永远丢失
}

更隐蔽的情况是提前 return 或抛出异常，导致释放语句被跳过：

cpp 复制代码

bool process() {
    char* buf = new char[1024];
    if (!init()) {
        return false;   // 泄漏：buf 未释放
    }
    if (!run()) {
        throw std::runtime_error("run failed"); // 泄漏：buf 未释放
    }
    delete[] buf;
    return true;
}

规避方式 ：优先使用栈对象或 std::vector、std::string 等容器；必须用堆时，用 std::unique_ptr 管理，让 RAII 保证任何退出路径都会释放。

三、场景二：new\[\] 与 delete 不匹配

数组用 new[] 分配，却用 delete 释放，属于未定义行为。对于有析构函数的类型，通常只析构第一个元素，其余元素占用的内存不会被正确回收，表现为泄漏或崩溃。

cpp 复制代码

struct Item {
    std::string name;
};

void mismatch() {
    Item* arr = new Item[10];
    delete arr;      // 错误：应为 delete[] arr;
}

规避方式 ：成对使用 new[] / delete[]；更好的做法是直接用 std::vector<Item>。

四、场景三：基类析构函数未声明为 virtual

通过基类指针删除派生类对象时，如果基类析构函数不是虚函数，则只会调用基类析构函数，派生类新增的成员所持有的资源不会被释放。

cpp 复制代码

class Base {
public:
    ~Base() {}          // 非虚析构
};

class Derived : public Base {
public:
    Derived() : data(new int[100]) {}
    ~Derived() { delete[] data; }
private:
    int* data;
};

void destroy() {
    Base* p = new Derived();
    delete p;           // 只调用 ~Base()，data 泄漏
}

规避方式 ：作为多态基类的类，析构函数必须声明为 virtual；或者把析构函数设为 protected 且非虚，禁止通过基类指针删除。

五、场景四：容器中存放裸指针

容器销毁时只会销毁元素本身，不会释放元素指向的堆内存。

cpp 复制代码

void containerLeak() {
    std::vector<Widget*> widgets;
    for (int i = 0; i < 10; ++i) {
        widgets.push_back(new Widget());
    }
    // vector 析构，但 10 个 Widget 对象全部泄漏
}

如果中途 erase 元素，同样需要手动 delete 被移除的元素，否则也会泄漏。

规避方式 ：容器中存放 std::unique_ptr<Widget> 或 std::shared_ptr<Widget>；C++11 起 emplace_back(std::make_unique<Widget>()) 是推荐写法。

六、场景五：异常安全缺失

在资源获取与释放之间发生异常，释放代码不会执行。典型如手动加锁、手动打开文件、手动分配内存后调用可能抛异常的代码。

cpp 复制代码

void unsafe() {
    Resource* r = new Resource();
    doSomething();      // 若抛出异常，r 泄漏
    delete r;
}

规避方式 ：使用 RAII 封装（std::lock_guard、std::unique_ptr、std::fstream），让析构函数在栈展开时自动释放资源。

七、场景六：循环引用导致 shared_ptr 无法释放

std::shared_ptr 通过引用计数管理生命周期。当两个对象互相持有对方的 shared_ptr 时，引用计数永远不为 0，对象永远不会被销毁。

cpp 复制代码

struct Node {
    std::shared_ptr<Node> next;
    std::shared_ptr<Node> prev;
};

void cycle() {
    auto a = std::make_shared<Node>();
    auto b = std::make_shared<Node>();
    a->next = b;
    b->prev = a;        // 循环引用，a 和 b 都不会被释放
}

规避方式 ：环形或父子结构中，反向指针使用 std::weak_ptr；用 weak_ptr::lock() 在使用时临时提升为 shared_ptr。

八、场景七：单例与全局对象持有资源

单例对象通常生命周期与进程相同，其内部持有的堆内存直到进程退出才释放。严格来说这不算「泄漏」，但在长生命周期对象中不断累积数据（如缓存只增不减、注册表只注册不注销）会造成事实上的内存持续增长。

cpp 复制代码

class Registry {
public:
    static Registry& instance() {
        static Registry inst;
        return inst;
    }
    void add(Handler* h) { handlers_.push_back(h); }
    // 没有 remove，handlers_ 只增不减
private:
    std::vector<Handler*> handlers_;
};

规避方式：为长生命周期容器提供明确的移除接口；缓存设置容量上限或过期策略；注册与注销成对设计。

九、场景八：placement new 未显式调用析构

使用 placement new 在已有内存上构造对象时，必须显式调用析构函数，否则对象内部持有的资源不会释放。

cpp 复制代码

void placement() {
    alignas(std::string) unsigned char buf[sizeof(std::string)];
    auto* s = new (buf) std::string("hello");
    // 忘记 s->~basic_string();
}

规避方式 ：封装成 RAII 类型，在析构函数中调用 std::destroy_at；或使用 std::optional、std::variant 等标准设施。

十、场景九：回调、事件监听未注销

对象把自己注册到某个全局事件总线或观察者列表后，在销毁时没有注销。事件总线持有该对象的指针或 shared_ptr，导致对象无法释放，回调触发时还可能访问已销毁对象。

cpp 复制代码

class Listener {
public:
    Listener() { EventBus::instance().subscribe(this); }
    ~Listener() {
        // 忘记 EventBus::instance().unsubscribe(this);
    }
};

规避方式 ：在析构函数中成对注销；事件总线使用 weak_ptr 或令牌（token）机制，订阅时返回可自动失效的句柄。

十一、场景十：第三方库与 API 使用不当

不少 C 风格 API 采用「谁申请谁释放」或「由调用方释放」的约定，容易遗漏：

strdup 返回的内存需要用 free 释放。
getline 分配的缓冲区需要 free。
OpenSSL 的 BIO_new、EVP_*_CTX_new 需要对应的 _free。
Windows 的 FormatMessage 使用 LocalAlloc，需要 LocalFree。
数据库、网络库返回的结果集、连接句柄需要显式关闭。

规避方式 ：阅读 API 文档中的所有权说明；用 RAII 包装器（自定义 deleter 的 unique_ptr）统一管理。

十二、如何检测内存泄漏

定位泄漏比避免泄漏更依赖工具，常见手段如下：

工具	平台	说明
Valgrind Memcheck	Linux	无需重新编译，能给出泄漏点调用栈，适合开发与测试阶段
AddressSanitizer（ASan）	跨平台	编译期插桩，`-fsanitize=address`，运行时开销较小，可配合 LeakSanitizer
Visual Studio 诊断工具	Windows	内置内存快照对比，可查看分配调用栈
CRT 调试堆	Windows	`_CrtSetDbgFlag(_CRTDBG_LEAK_CHECK_DF)` 在退出时报告泄漏
heaptrack / massif	Linux	分析堆分配热点与增长趋势

实践建议：在 CI 中开启 ASan 跑单元测试；对长稳服务定期采集堆快照并对比增量。

十三、总结与最佳实践

优先使用值语义 ：栈对象、std::string、std::vector 能覆盖绝大多数场景。
必须用堆时用智能指针 ：unique_ptr 表达独占所有权，shared_ptr 表达共享所有权，weak_ptr 打破循环。
遵循 RAII：资源在构造函数中获取，在析构函数中释放，让异常安全自然成立。
多态基类析构函数加 virtual，或禁止通过基类指针删除。
成对设计接口：注册与注销、打开与关闭、订阅与退订。
用工具兜底：ASan、Valgrind 常态化运行，把泄漏挡在合入之前。

内存泄漏的本质是所有权不清晰。把「谁负责释放」这件事在类型层面表达出来，绝大多数泄漏场景都可以在编译期或设计阶段被消除。