C++内存泄漏常见陷阱：从new/delete误用到智能指针循环引用

在长期的C++开发实践中，程序员们往往会发现，最棘手的风险往往不是来自复杂的算法，而是那些看似“显而易见”、却在边界条件或异常路径上爆发的编码习惯。内存管理作为C++的核心能力，既是其强大性能的基石，也隐藏着诸多陷阱。

本文将梳理几种因“过度自信”而容易导致内存泄漏的常见场景，帮助你规避风险，尤其是在高强度开发或快速修补时保持代码的健壮性。

1. new/delete 配对错误

这是最基础也最致命的问题：错误地使用new[]搭配delete，或new搭配delete[]，均会导致未定义行为或内存泄漏。指针不应被随意对待。

错误示例：

char* p = new char[100];
// ... 使用 p
delete p; // 错误：应为 delete[] p

修正：

char* p = new char[100];
// ... 使用 p
delete[] p; // 正确

更佳实践是避免手动管理数组，优先使用标准库容器或智能指针：

std::vector<char> buf(100); // 使用容器
auto up = std::make_unique<char[]>(100); // 若确实需要动态数组

2. 异常安全：new 后遇异常导致泄漏

如果在new之后执行可能抛出异常的操作，一旦异常抛出，后续的释放代码将无法执行。

错误示例：

Widget* w = new Widget;
doSomethingThatMayThrow(); // 可能抛出异常
manager.add(w); // 若上一行抛出异常，此行不会执行，w 泄漏

修正： 利用 RAII（资源获取即初始化）思想，在创建资源时立即将其所有权交给管理对象，如使用std::make_unique。

auto w = std::make_unique<Widget>();
doSomethingThatMayThrow();
manager.add(std::move(w)); // 所有权转移

3. shared_ptr 循环引用

这是使用std::shared_ptr时最常见的自信陷阱。两个对象相互持有对方的shared_ptr，会导致引用计数永远不为零，内存无法释放。

错误示例：

struct A { std::shared_ptr<B> b; };
struct B { std::shared_ptr<A> a; };

auto a = std::make_shared<A>();
auto b = std::make_shared<B>();
a->b = b;
b->a = a; // 形成循环引用，内存泄漏

修正： 将其中一个指针改为std::weak_ptr，以打破强引用循环。

struct B { std::weak_ptr<A> a; }; // 使用 weak_ptr
b->a = a; // 弱引用，不会增加引用计数

4. 误用 enable_shared_from_this

当对象并非由shared_ptr管理时，调用shared_from_this()会抛出异常。此外，自行构造shared_ptr<T>(this)会产生新的控制块，可能导致同一内存被释放两次。

错误写法：

// 在类成员函数内
auto p = std::shared_ptr<MyClass>(this); // 危险：可能产生双控制块

正确用法： 确保对象自创建起就由std::make_shared管理，并且类公有继承自std::enable_shared_from_this。

class MyClass : public std::enable_shared_from_this<MyClass> { ... };
auto p = std::make_shared<MyClass>(); // 正确创建
// 在 MyClass 成员函数内可安全调用 shared_from_this()

5. 容器内存放裸指针导致遗忘释放

将裸指针存入容器（如std::vector<Foo*>）时，容器销毁并不会自动释放指针所指向的对象，容易导致遗忘。

修正： 使用持有所有权的智能指针容器。

std::vector<std::unique_ptr<Foo>> v;
v.emplace_back(std::make_unique<Foo>()); // 容器销毁时自动释放资源

6. 基类缺少虚析构函数

当通过基类指针删除派生类对象，而基类析构函数非虚时，这是未定义行为。派生类的析构函数可能不会被调用，造成资源泄漏。

错误示例：

struct Base { /* ~Base() 非虚 */ };
struct Derived : Base { ~Derived(){ /* 释放派生类资源 */ } };

Base* p = new Derived;
delete p; // 未定义行为：Derived::~Derived() 可能未被调用

修正： 为作为多态基类的类型定义虚析构函数。

struct Base { virtual ~Base() = default; }; // 虚析构函数

7. 遗忘释放系统资源

在C++中，“资源”不仅限于堆内存，还包括文件句柄、网络套接字、线程等。若未将其封装在RAII对象中，同样会导致资源泄露。

修正建议：

• 使用std::ifstream/std::ofstream替代fopen/fclose。
• 使用std::thread时，确保在对象销毁前调用join()或detach()，避免线程资源泄露。

8. 自定义删除器或分配器实现错误

为智能指针提供自定义删除器，或为容器使用自定义分配器时，如果其行为逻辑有误，可能导致资源无法释放或重复释放。

9. 对全局/静态对象的误解

将大型对象声明为全局或静态变量以求“省事”，在长期运行的服务进程中，这会导致内存只增不减，形成事实上的内存积压。虽然进程退出时操作系统会回收，但这并非一个安全的编程实践。

快速检查清单

1. 首选RAII：尽可能使用unique_ptr、shared_ptr、标准容器、文件流等管理资源。
2. 避免裸new：使用make_unique和make_shared。
3. 警惕循环引用：检查shared_ptr的使用，必要时引入weak_ptr。
4. 保证异常安全：确保在构造资源的同时即完成所有权绑定，这是实现异常安全代码的关键。
5. 基类虚析构：多态基类必须拥有虚析构函数。
6. 善用检测工具：在开发及测试阶段使用AddressSanitizer、Valgrind、LeakSanitizer等工具进行验证。
7. 明确所有权：编码时时刻思考“这块内存由谁负责释放？”，并将其设计意图通过类型系统清晰地表达出来。

总结而言，在C++开发中，真正的危险往往来自对简单规则的盲目自信。将资源管理的责任明确化，并交给类型系统和RAII机制，才能让我们将精力真正集中于业务逻辑的实现，从而编写出更稳健、高效的代码。