第14章内存泄漏与野指针

课程目录第14章内存泄漏与野指针

第14章内存泄漏与野指针：常见内存错误、如何避免内存泄漏、调试技巧

内存管理，说白了就是C语言里最容易翻车的地方。我做了十几年嵌入式开发，见过太多系统莫名其妙死机、重启，最后查下来都是内存问题。今天咱们就把内存泄漏和野指针这两个“头号杀手”彻底讲透。

14.1 内存泄漏：你借了东西不还

内存泄漏是什么？就是你用malloc申请了一块内存，用完之后忘了free。一次两次没事，但程序跑上几天几夜，内存一点点被吃掉，最后系统崩溃。

核心观点：每次malloc都必须有对应的free，就像借了钱必须还。

14.1.1 典型的内存泄漏场景

我在项目中遇到过最典型的情况——函数里申请了内存，但提前return了：

void process_data(int *input, int size) {
    int *buffer = (int *)malloc(size * sizeof(int));
    if (!buffer) return;
    
    // 做一些处理...
    if (some_error_condition) {
        return;  // 糟糕！忘记free(buffer)了
    }
    
    // 正常处理...
    free(buffer);
}

你看，只要some_error_condition为真，buffer就永远没人还了。这种错误特别隐蔽，因为正常路径下内存是释放的，只有异常路径才会泄漏。

14.1.2 循环中的泄漏

还有一种我经常在代码审查里抓到的：

for (int i = 0; i < 1000; i++) {
    char *msg = (char *)malloc(64);
    sprintf(msg, "Message %d", i);
    // 用完了，但忘了free
}

每次循环泄漏64字节，1000次就是64KB。如果这个循环每秒执行一次，一小时就是225MB。嗯，嵌入式设备那点内存，撑不了多久。

14.2 野指针：你拿着过期的地址乱跑

野指针比内存泄漏更危险。内存泄漏是慢慢死，野指针是瞬间崩。野指针指向的内存已经被释放了，或者根本就没申请过。

警告：野指针是C语言中最难调试的错误之一。它不会每次都崩溃，有时候能正常运行，有时候就崩，完全看运气。

14.2.1 常见的野指针成因

情况一：free之后没有置空

int *p = (int *)malloc(sizeof(int));
*p = 42;
free(p);
// p现在成了野指针
*p = 100;  // 危险！写入已释放的内存

我建议你养成一个习惯：free之后立刻把指针置为NULL。

free(p);
p = NULL;  // 这样即使误用，也会立刻崩溃，而不是随机崩溃

情况二：返回局部变量的地址

int *get_value() {
    int x = 10;
    return &x;  // x是局部变量，函数返回后就被销毁了
}

int *p = get_value();
*p = 20;  // 野指针！访问了栈上已释放的空间

这个错误我刚开始学C时犯过，调试了一整天。后来我总结了一条铁律：永远不要返回局部变量的地址。要么用static，要么用malloc。

14.3 如何避免内存泄漏

避免内存泄漏，说白了就是建立一套规矩，然后严格执行。我个人习惯用下面几个方法：

14.3.1 编码规范：谁申请谁释放

这是最基本的原则。如果函数A调用了malloc，那函数A或者它的调用者必须负责free。我在团队里定了一条规矩：每个malloc旁边必须写清楚谁来free。

// 这个函数申请内存，调用者负责释放
char *create_message(int id) {
    char *msg = (char *)malloc(64);
    if (msg) {
        sprintf(msg, "ID: %d", id);
    }
    return msg;  // 调用者记得free
}

14.3.2 使用资源获取即初始化（RAII）思想

C语言没有C++的RAII，但我们可以模拟。比如在函数开头申请资源，在函数结尾统一释放：

void safe_process() {
    int *data = NULL;
    char *log = NULL;
    
    data = (int *)malloc(100 * sizeof(int));
    if (!data) goto cleanup;
    
    log = (char *)malloc(256);
    if (!log) goto cleanup;
    
    // 正常处理...
    
cleanup:
    free(data);
    free(log);
}

用goto做统一清理，虽然有些人觉得不好看，但嵌入式领域这招很实用。我用了十几年，没出过问题。

14.3.3 内存池技术

对于频繁申请释放的小内存块，我建议用内存池。一次性申请一大块，然后自己管理分配和回收。这样既避免了碎片，也杜绝了泄漏。

// 简单的内存池示例
typedef struct {
    char pool[1024];
    size_t offset;
} MemoryPool;

void *pool_alloc(MemoryPool *mp, size_t size) {
    if (mp->offset + size > 1024) return NULL;
    void *ptr = mp->pool + mp->offset;
    mp->offset += size;
    return ptr;
}

// 使用：不需要free，整个池子一次性释放
MemoryPool mp = {0};
int *p = (int *)pool_alloc(&mp, sizeof(int));

14.4 调试技巧：抓内存错误的利器

内存错误调试起来很痛苦，但有一些工具和技巧能帮你省下大量时间。

14.4.1 使用Valgrind

Valgrind是Linux下检测内存问题的神器。我每次写完代码都会跑一遍：

valgrind --leak-check=full ./my_program

它会告诉你：哪里泄漏了、泄漏了多少字节、是哪次malloc导致的。对于野指针访问，它也能精准定位。

14.4.2 地址消毒剂（AddressSanitizer）

GCC和Clang都支持AddressSanitizer，编译时加上-fsanitize=address：

gcc -fsanitize=address -g my_program.c -o my_program

运行时如果发生内存错误，程序会立刻崩溃并打印详细的调用栈。我在项目中用过，效果非常好，比Valgrind快很多。

14.4.3 手动调试技巧

如果手头没有工具，可以用一些土办法。我曾经在调试一个野指针问题时，用了“哨兵值”技巧：

#define FREED_MARKER 0xDEADBEEF

void safe_free(void **ptr) {
    if (ptr && *ptr) {
        free(*ptr);
        *(int *)*ptr = FREED_MARKER;  // 标记已释放
        *ptr = NULL;
    }
}

这样如果误访问了已释放的内存，看到0xDEADBEEF就知道问题出在哪了。

14.5 本章知识体系

下面这张图总结了内存泄漏和野指针的核心知识点，以及它们之间的关系：

我的经验之谈：调试内存错误，最怕的就是“凭感觉”。我见过太多人花几天时间盯着代码看，最后发现是free了两次。用工具吧，Valgrind或AddressSanitizer，几分钟就能定位问题。

最后说一句：内存管理没有捷径。你写的每一行malloc，都要问自己一句——这个内存什么时候还？养成这个习惯，内存错误至少能减少80%。

公众号:蓝海资料掘金营，微信deep3321

📚 课程目录