指针用不好，内存悄悄跑光——几个实用招数帮你守住内存

写C/C++程序时，最让人头疼的不是编译不过，而是程序跑着跑着就变慢、卡死，甚至直接崩掉。查来查去，发现内存占用一路狂涨——八成是内存泄漏了。而泄漏的“罪魁祸首”，常常就是指针没管好。

指针为啥容易惹出内存泄漏？

指针本身不占多少内存，但它像一把钥匙，能打开堆上（heap）那扇大门。malloc/new 分配的内存，得靠你亲手用 free/delete 关门。钥匙一丢、门一忘关，那块内存就再也找不回来了，系统不会自动回收——这就是典型的内存泄漏。

常见翻车现场

比如这段代码：

void process_data() {
    int* buf = (int*)malloc(1024 * sizeof(int));
    if (some_error_happens()) {
        return; // 忘了 free(buf)！
    }
    // 正常处理...
    free(buf);
}

一旦出错提前返回，buf 指向的那片内存就永远留在那儿了。小项目可能一时看不出问题，但服务跑几天，泄漏积累起来，内存就“吃紧”了。

几招实打实的防漏技巧

1. 申请和释放写在一块儿，别分开太远
把 malloc 和 free 尽量放在同一个函数里，而且最好靠近些。别让 new 出现在 A 函数，delete 跑到 Z 函数去——人脑记不住，代码也难维护。

2. 指针释放后立刻置空
free 或 delete 后马上把指针设成 NULL 或 nullptr：

int* p = new int[100];
// ...
delete[] p;
p = nullptr; // 防止后续误用或重复 delete

这样下次再 if(p) 判断，或者不小心又 delete 一次，至少不会崩得莫名其妙。

3. 用智能指针代替裸指针（C++11 起）
不用自己操心释放时机，交给 unique_ptr 或 shared_ptr：

#include <memory>
void safe_process() {
    auto ptr = std::make_unique<int[]>(100); // 自动管理
    // 不用手动 delete，函数结束自动释放
}

对 C 程序员来说，可以封装一个带日志的 malloc/free 宏，在调试阶段记录每次分配和释放，快速定位漏点。

一个小工具建议

Windows 下可以用 Visual Studio 的 CRT 调试堆（_CrtDumpMemoryLeaks），Linux 下推荐 valgrind —— 运行完它会直接告诉你哪行 new 没配对 delete，比肉眼扫代码靠谱多了。

内存不是无限的，尤其在嵌入式、服务器长期运行场景下，指针管得好不好，直接决定程序能不能挺过三天三夜。