C/C++中的内存泄漏像个隐形杀手，悄无声息地侵蚀系统资源，尤其在长时间运行的设备上，比如物联网终端或工业控制器，后果可能不堪设想。内存泄漏本质上是程序员忘了释放动态分配的内存，导致可用内存逐渐减少，最终可能让系统瘫痪。今天我们就来深入剖析一下C/C++中内存泄漏的成因，并结合实际开发场景提供一些解决方法。
内存泄漏是什么？
在C/C++开发中，内存泄漏指的是动态分配的内存（比如通过 malloc 或 new 分配）未被正确释放，导致这块内存无法被系统回收。举个简单的例子：
int main() {
char *buffer = malloc(sizeof(char) * 100);
// 干了点活儿
return 0; // 忘了调用 free(buffer)，内存泄漏！
}
这段代码就像在CPU里开了一家餐馆，点了一堆食材（内存），用完后却忘了清理，久而久之，厨房（系统内存）就塞满了没人用的东西。尤其在嵌入式系统中，内存资源通常非常有限，泄漏一点可能无感，但如果程序长期运行（比如一个运行数月的智能电表），内存耗尽可能导致系统死机，重启，甚至引发设备故障。
内存泄漏的危害在服务器或嵌入式设备上尤其明显，因为这些系统需要7x24小时稳定运行，哪怕每次循环只泄漏几个字节，累积起来也足以拖垮整个系统。
内存泄漏的常见成因
C/C++编程中，内存泄漏的根源通常和指针管理失误有关。以下是几个常见的罪魁祸首：
1. 指针被重新赋值，原始地址丢失
开发中常会遇到这样的场景：你用 malloc 或 new 分配了一块内存，但不小心把指针赋值为其他值，比如 NULL，导致原内存地址丢失，无法释放。
int *ptr = malloc(sizeof(int));
ptr = NULL; // 糟糕，原始内存地址丢了，泄漏！
再比如C++中：
int *ptr = new int(6);
ptr = nullptr; // 又一个内存泄漏的坑！
这就像在开发板上调试时，你把一个关键寄存器地址覆盖成了0，结果整个硬件资源都“失联”了。
2. 异常抛出导致释放被跳过
在C++中，如果代码在释放内存前抛出异常，delete 可能永远不会执行。
void func() {
int *ptr = new int(27);
someRiskyOperation(); // 如果这里抛异常
delete ptr; // 这一行可能永远不会执行
}
这种情况可能出现在中断处理或复杂的状态机逻辑中，异常（或类似错误）让释放逻辑被跳过，内存就“悬浮”在系统里了。
3. 指针离开作用域
局部指针在函数退出后自动销毁，但它指向的动态内存还在，变成了孤魂野鬼。
void func() {
int *ptr = malloc(sizeof(int));
} // ptr没了，内存还在，泄漏！
比如在某个回调函数里分配了内存，但忘了在全局管理器中记录地址，函数一结束，内存就人间蒸发了。
4. 原始指针操作过于随意
直接操作裸指针（raw pointer）容易出错，尤其在复杂项目中，指针被多次传递或修改后，谁还记得它的“归宿”？
5. 释放内存顺序错误
如果有嵌套结构，比如一个结构体包含另一个动态分配的指针，释放时顺序不对可能导致子节点的内存成为“孤儿”。
typedef struct {
void *data;
} Context;
Context *ctx = malloc(sizeof(Context));
ctx->data = malloc(100);
free(ctx); // 错误！ctx->data 没释放，变孤儿了
这就像在开发一个多级菜单系统，你把主菜单（父节点）删了，但子菜单（子节点）的内存还在，系统资源白白浪费。
如何在C语言中避免内存泄漏？
在嵌入式开发中，尤其是用C开发MCU，内存管理全靠程序员的手艺。我们在这里分享一些常见的经验总结
1. malloc后立刻写free，养成好习惯
每次调用 malloc 或 calloc 后，第一时间写上对应的 free，就像在调试时先把日志打印函数写好一样。假设你在开发一个温湿度传感器驱动，需要动态分配一个缓冲区来存数据：
int processData(int size) {
char *buffer = malloc(size * sizeof(char));
free(buffer); // 先写好释放，防止忘记
return 0;
}
然后在 malloc 和 free 之间填充你的业务逻辑：
int processData(int size) {
char *buffer = malloc(size * sizeof(char));
// 处理传感器数据
free(buffer);
return 0;
}
如果这块内存需要全局使用（比如在整个固件生命周期中），就把 free 放到系统的退出处理函数中，比如 DeinitHandler，并在分配时紧接着写上释放逻辑，降低忘记的概率。
2. 从子节点到父节点依次释放
释放内存时，总是从最底层的子节点开始，逐步向上释放，避免“孤儿内存”。比如在开发一个协议栈时，结构体可能嵌套多层：
typedef struct {
char *payload;
} Packet;
Packet *pkt = malloc(sizeof(Packet));
pkt->payload = malloc(128);
free(pkt->payload); // 先释放子节点
free(pkt); // 再释放父节点
这就像拆房子，先把家具搬走，再拆主体结构，不然家具就成了“无人认领”的垃圾。
3. 用计数器监控内存分配
嵌入式系统中资源宝贵，监控内存分配是个好习惯。可以用两个全局计数器，一个记录分配次数（AllocCounter），一个记录释放次数（FreeCounter）。程序结束时，两个计数器应该相等，否则说明有泄漏。
static unsignedint AllocCounter = 0;
staticunsignedint FreeCounter = 0;
void *SafeMalloc(size_t size) {
void *ptr = malloc(size);
if (ptr) AllocCounter++;
return ptr;
}
void SafeFree(void *ptr) {
if (ptr) {
free(ptr);
FreeCounter++;
}
}
int CheckLeak() {
return AllocCounter == FreeCounter ? 0 : -1;
}
这个方法在调试复杂固件时特别有用，比如在调试一个多任务的RTOS系统时，可以快速定位哪个任务忘了释放内存。
4. 操作指针副本，保护原始地址
直接操作原始指针风险太大，稍不注意就可能改了地址，导致无法释放。更好的做法是创建一个副本操作：
char *buffer = malloc(100 * sizeof(char));
char *tmp = buffer; // 副本操作
// 用tmp干活
free(buffer); // 用原始指针释放
这就像在调试硬件时，你不会直接改核心寄存器，而是用临时变量操作，保护关键资源。
5. 写好注释
一个实际的公司项目，代码可能要维护好几年，写清晰的注释能帮你快速回忆当初的逻辑。比如：
char *buffer = malloc(100 * sizeof(char)); // 分配缓冲区，存储传感器数据
// 处理数据
free(buffer); // 释放缓冲区
很多中小团队人手有限，代码可能由不同工程师接手，注释就像给未来的自己或同事留下系统、完整的备忘录。
