📚 课程目录第3章内存分析

内存分析：内存泄漏检测、堆栈溢出与碎片优化

内存问题，是嵌入式开发里最让人头疼的几类 bug 之一。我见过太多项目，功能逻辑全对，跑几天就崩，最后定位到内存泄漏。说实话，这类问题隐蔽性强，复现困难，靠肉眼 review 代码基本没戏。所以，这一章我们专门聊聊怎么用工具和思路，把内存问题揪出来、治下去。

内存泄漏检测：Valgrind 与 AddressSanitizer

内存泄漏，说白了就是申请了堆内存，用完后没释放。一次两次没事，跑上几个小时，堆空间被慢慢吃光，系统就挂了。我个人习惯，在开发阶段就引入自动化检测工具，而不是等到崩溃了再查。

Valgrind：Linux 下的老牌利器

Valgrind 的 memcheck 工具，能拦截每次 malloc/free，检查是否有未释放的内存。用法很简单：

# 编译时加 -g 保留调试信息
gcc -g -o my_app my_app.c

# 用 valgrind 运行
valgrind --leak-check=full --show-leak-kinds=all ./my_app

输出会告诉你：哪行代码申请的内存没释放，泄漏了多少字节。我在项目中遇到过几次，valgrind 报告泄漏，结果发现是第三方库的初始化函数没调用对应的去初始化接口。嗯，这种坑最冤枉。

小提示：Valgrind 会让程序运行速度慢 10-20 倍，不适合跑性能测试。建议在单元测试或集成测试阶段使用。

AddressSanitizer (ASan)：编译期插桩

ASan 是 GCC/Clang 内置的检测工具，编译时加几个 flag 就行，运行时开销比 Valgrind 小得多（约 2 倍慢）。我更喜欢在 CI 流水线里用 ASan，因为它快，能覆盖更多测试用例。

# 编译时启用 ASan
gcc -fsanitize=address -g -o my_app my_app.c

# 直接运行，ASan 会在检测到泄漏时自动输出报告
./my_app

ASan 不仅能检测泄漏，还能检测缓冲区溢出、use-after-free 等问题。你想想看，一个工具能覆盖这么多场景，性价比极高。

特性	Valgrind	AddressSanitizer
运行速度	慢 10-20 倍	慢约 2 倍
检测范围	泄漏、未初始化、越界	泄漏、越界、use-after-free
适用场景	开发调试、小规模测试	CI 流水线、大规模测试
平台支持	Linux/macOS	Linux/macOS/Android

堆栈溢出检测

堆栈溢出，就是局部变量太多或者递归太深，把栈空间撑爆了。嵌入式系统的栈通常只有几 KB 到几十 KB，一不小心就出事。我记得有一次调试一个 RTOS 任务，任务函数里定义了一个 4KB 的局部数组，结果栈直接溢出，系统跑飞。后来我把大数组改成动态分配，问题解决。

硬件 MPU/MMU 保护

如果芯片支持 MPU（内存保护单元）或 MMU，可以给栈区域设置访问权限。一旦栈指针越界，CPU 直接触发异常。这是最可靠的方法，但需要硬件支持。

软件栈边界检测

没有硬件保护时，可以用软件方法。常见做法是在栈底填充一个固定模式（比如 0xDEADBEEF），然后定期检查这个模式是否被覆盖。FreeRTOS 就提供了这种机制：

// 创建任务时启用栈溢出检测
xTaskCreate(
    vTaskFunction,
    "TaskName",
    STACK_SIZE,
    NULL,
    tskIDLE_PRIORITY,
    NULL
);

// 在钩子函数中处理溢出
void vApplicationStackOverflowHook(TaskHandle_t xTask, char *pcTaskName) {
    // 记录错误，重启或进入安全模式
    printf("Stack overflow in task: %s\n", pcTaskName);
}

避坑指南：我曾经在项目里只依赖软件检测，结果栈溢出破坏了检测变量本身，导致检测失效。建议：软件检测只作为辅助，关键任务还是要估算好栈深度，留足余量（通常 1.5 倍）。

内存碎片优化

内存碎片，是动态内存分配的头号杀手。频繁地 malloc/free 不同大小的块，堆空间会被切成很多小碎片，导致后续大块分配失败。你想想看，明明总空闲内存还有 50%，但就是分配不出一个 1KB 的块——这就是碎片化。

碎片产生的原因

分配模式不规律：大小交替、频繁释放
内存池设计不合理：固定大小块与可变大小块混用
长时间运行：碎片随时间累积

优化策略

使用固定大小内存池：把堆分成若干固定大小的块（如 16B、32B、64B...），每次分配只取对应大小的块。这样不会产生碎片，但会浪费一些内存。
避免频繁分配释放：能静态分配的就静态分配，能复用缓冲区的就复用。
使用伙伴算法或 slab 分配器：这些算法能有效减少外部碎片。Linux 内核用的就是 slab。

// 简单固定大小内存池示例
typedef struct {
    void *pool;          // 内存池起始地址
    size_t block_size;   // 每个块的大小
    int total_blocks;    // 总块数
    int free_blocks;     // 空闲块数
    uint8_t *bitmap;     // 分配位图
} mem_pool_t;

// 分配一个块
void *pool_alloc(mem_pool_t *pool) {
    for (int i = 0; i < pool->total_blocks; i++) {
        if (!(pool->bitmap[i / 8] & (1 << (i % 8)))) {
            pool->bitmap[i / 8] |= (1 << (i % 8));
            pool->free_blocks--;
            return (uint8_t *)pool->pool + i * pool->block_size;
        }
    }
    return NULL; // 无空闲块
}

  核心思路：碎片优化的本质是“确定性”——让每次分配的大小和时机都可预测。固定大小内存池虽然浪费一点空间，但换来的是确定性的分配时间和零碎片。在实时嵌入式系统里，这个 trade-off 非常值得。

知识体系总览

下面这张图，把本章的内存分析知识体系串起来。你可以把它当作调试时的检查清单。

这张图把内存分析分成三个核心方向。每个方向都有对应的工具和策略。我个人建议，在项目初期就把这些检测手段集成到开发流程里，而不是等出问题了再补。毕竟，内存问题越早发现，修复成本越低。