第16章内存管理

课程目录第16章内存管理

16、内存管理：堆与栈、malloc/free最佳实践、内存泄漏检测（Valgrind）

内存管理，说白了就是C语言里最容易翻车的地方。我见过太多项目，功能跑得挺好，一上线就崩，查到最后全是内存问题。今天咱们就把这块彻底聊透。

16.1 堆与栈：两个不同的世界

先说说栈。栈是编译器自动管理的，你定义一个局部变量，函数一调用就分配，函数一返回就回收。速度快，但容量小——一般就几MB。我早期做嵌入式开发时，有个同事在栈上声明了一个大数组，结果程序一跑就死机。查了半天，栈溢出了。

堆就不一样了。堆是你手动管理的，用malloc申请，用free释放。容量大，但速度慢，而且容易出问题。你想想看，堆就像一个大仓库，你往里放东西容易，但要记得什么时候该清走。

特性	栈	堆
管理方式	编译器自动管理	程序员手动管理
分配速度	快（一条指令）	慢（需要查找空闲块）
容量	小（通常几MB）	大（可达GB级别）
生命周期	函数执行期间	从malloc到free
典型问题	栈溢出	内存泄漏、野指针

核心原则：能用栈就别用堆。栈安全、高效、省心。只有数据需要跨函数存活，或者数据量太大时，才考虑堆。

16.2 malloc/free 最佳实践

malloc和free，看着简单，用起来全是坑。我这些年踩过的雷，总结成几条铁律。

16.2.1 永远检查malloc返回值

malloc可能失败。尤其是在嵌入式环境里，内存紧张，分配失败是常有的事。我见过太多代码直接拿返回值就用，也不检查是不是NULL。

// 错误写法
char *buf = malloc(1024);
strcpy(buf, "hello");  // 如果malloc失败，这里直接崩

// 正确写法
char *buf = (char *)malloc(1024);
if (buf == NULL) {
    // 处理错误，比如返回错误码或记录日志
    fprintf(stderr, "malloc failed!\n");
    return -1;
}
strcpy(buf, "hello");

警告：malloc返回NULL后，不要直接访问指针。我曾经在一个项目中，因为没检查返回值，导致程序在低内存条件下随机崩溃，查了整整两天。

16.2.2 谁分配谁释放

这是个约定，但很多人不遵守。函数A里malloc，函数B里free，代码一复杂，根本搞不清谁该负责释放。我建议：分配和释放放在同一层。

// 不好的设计：分配和释放分离
void process_data() {
    char *data = (char *)malloc(100);
    helper(data);  // helper里可能free，也可能不free
    // 这里data状态不确定
}

// 好的设计：谁分配谁释放
void process_data() {
    char *data = (char *)malloc(100);
    if (data == NULL) return;
    
    helper(data);  // helper只使用，不释放
    
    free(data);    // 明确在这里释放
    data = NULL;
}

16.2.3 free后立即置NULL

free只是释放内存，但指针的值还在。如果你不小心再次使用这个指针，就是野指针访问，后果不可预测。

char *p = (char *)malloc(10);
free(p);
// p现在成了野指针
// 如果后面不小心用了它：
// strcpy(p, "hello");  // 灾难！

// 正确做法：
free(p);
p = NULL;  // 置空后，再使用p就会立即崩溃，而不是随机崩溃

小技巧：我习惯写一个宏，把free和置NULL打包在一起：

#define SAFE_FREE(p) do { free(p); (p) = NULL; } while(0)

16.3 内存泄漏：看不见的杀手

内存泄漏是什么？就是你malloc了一块内存，但忘了free。程序跑得越久，泄漏越多，最后内存耗尽，程序崩溃。服务器程序尤其怕这个——跑几天就崩，用户受不了。

我参与过一个物联网项目，设备运行一周后必死机。查到最后，是一个循环里每次malloc都不free，一周下来内存全被吃光了。

16.3.1 常见泄漏场景

忘记free：最直接的泄漏，分配了但没释放。
丢失指针：把指针重新赋值了，原来的内存再也找不回来。
异常路径：函数中间return了，后面的free没执行到。

// 异常路径泄漏示例
int read_file(const char *path) {
    char *buf = (char *)malloc(1024);
    if (buf == NULL) return -1;
    
    FILE *fp = fopen(path, "r");
    if (fp == NULL) {
        // 这里直接return了，忘记free(buf)
        return -1;  // 泄漏！
    }
    
    // ... 读取文件 ...
    
    fclose(fp);
    free(buf);
    return 0;
}

// 正确写法：在return前释放
int read_file(const char *path) {
    char *buf = (char *)malloc(1024);
    if (buf == NULL) return -1;
    
    FILE *fp = fopen(path, "r");
    if (fp == NULL) {
        free(buf);  // 先释放再返回
        return -1;
    }
    
    // ... 读取文件 ...
    
    fclose(fp);
    free(buf);
    return 0;
}

16.4 Valgrind：内存问题的照妖镜

手动找内存泄漏太痛苦了。好在有Valgrind这个神器。它能检测内存泄漏、非法访问、未初始化变量等问题。说白了，就是给你的程序装了个监控摄像头。

16.4.1 基本用法

// 编译时加上-g，保留调试信息
gcc -g -o myprogram myprogram.c

// 用Valgrind运行
valgrind --leak-check=full ./myprogram

Valgrind会输出详细的报告，告诉你哪里泄漏了、泄漏了多少字节。我每次提交代码前，都会跑一遍Valgrind，确保没有内存问题。

16.4.2 解读Valgrind输出

假设你有这样一段代码：

#include <stdlib.h>

int main() {
    char *p = (char *)malloc(100);
    // 忘记free
    return 0;
}

Valgrind会输出类似这样的信息：

==12345== HEAP SUMMARY:
==12345==     in use at exit: 100 bytes in 1 blocks
==12345==   total heap usage: 1 allocs, 0 frees, 100 bytes allocated
==12345== 
==12345== 100 bytes in 1 blocks are definitely lost in loss record 1 of 1
==12345==    at 0x4C2B800: malloc (vg_replace_malloc.c:299)
==12345==    by 0x40052E: main (test.c:4)
==12345== 
==12345== LEAK SUMMARY:
==12345==    definitely lost: 100 bytes in 1 blocks

看到"definitely lost"了吗？这就是泄漏。它告诉你泄漏发生在test.c的第4行，是malloc分配的。你直接去那里加个free就行。

我的习惯：每次写完代码，先编译通过，然后跑Valgrind。如果报告里有任何"definitely lost"，坚决不提交代码。这个习惯帮我避免了很多线上事故。

16.4.3 更多Valgrind选项

选项	作用
--leak-check=full	显示每个泄漏的详细信息
--show-leak-kinds=all	显示所有类型的泄漏（包括间接泄漏）
--track-origins=yes	追踪未初始化变量的来源
--log-file=val.log	将输出保存到文件

16.5 知识体系总览

下面这张图，把本章的核心内容串起来了。你对照着看，心里就有谱了。

嗯，内存管理这块，说白了就是三个字：守规矩。malloc了就要free，分配了就要检查，释放了就要置空。再加上Valgrind这个好帮手，基本就能把内存问题控制在可控范围内。

我最后再啰嗦一句：别嫌麻烦。内存问题在开发阶段发现，改起来就几分钟。要是上了线才发现，那就是灾难。每次提交代码前跑一遍Valgrind，这个习惯值得养成。

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