4. 内存分析：内存泄漏检测方法、堆栈溢出排查、内存碎片化问题定位
内存问题，说白了就是嵌入式系统的“慢性病”。
我见过太多设备，刚上电时跑得稳稳当当，运行几天、几周后突然死机、重启，或者响应越来越慢。查到最后，十有八九是内存出了问题。今天咱们就聊聊内存分析里最头疼的三个问题：泄漏、溢出、碎片化。
4.1 内存泄漏检测方法
内存泄漏，就是申请了内存，用完后没还回去。一次两次没事，日积月累，堆空间被吃光，系统就崩了。
4.1.1 静态代码审查
我个人习惯，写代码时先过一遍“配对检查”。
malloc有没有对应的free？new有没有对应的delete？- 打开的文件句柄，有没有
close？
别小看这一步。我在项目中遇到过，一个同事写了2000行的通信协议栈，malloc 了30多次，有3处忘了 free。设备跑48小时必死。后来一行一行对，才揪出来。
4.1.2 动态检测工具
光靠人眼看不够，得上工具。
| 工具/方法 | 适用平台 | 特点 |
|---|---|---|
| Valgrind (memcheck) | Linux (ARM/x86) | 检测泄漏、越界，但运行慢 |
| AddressSanitizer | GCC/Clang | 编译时插桩，运行时检测 |
| FreeRTOS + HeapTrace | MCU (RTOS) | 轻量级，记录每次malloc/free |
| 自定义内存钩子 | 裸机/RTOS | 最灵活，但需要自己写代码 |
我的小技巧： 在调试阶段，我会把
malloc 和 free 都包装一层。每次分配时记录文件名、行号、大小。释放时标记清除。最后打印出“未释放列表”。这招虽然土，但特别管用。
4.1.3 代码示例：自定义内存追踪
// 简易内存追踪宏
#define DEBUG_MALLOC(size) \
debug_malloc(size, __FILE__, __LINE__)
#define DEBUG_FREE(ptr) \
debug_free(ptr)
void* debug_malloc(size_t size, const char* file, int line) {
void* ptr = malloc(size);
// 将分配信息记录到链表或日志中
log_allocation(ptr, size, file, line);
return ptr;
}
void debug_free(void* ptr) {
free(ptr);
// 从链表中移除记录
log_deallocation(ptr);
}
// 在系统空闲时，打印所有未释放的内存块
void print_leaks(void) {
// 遍历链表，输出泄漏信息
}4.2 堆栈溢出排查
堆栈溢出，比泄漏更隐蔽。泄漏是慢慢死，溢出是瞬间崩。
为什么会这样？因为栈空间是固定的。函数调用太深、局部变量太大、中断嵌套太多，都会把栈撑爆。一旦溢出，就会踩到相邻的变量、返回地址，甚至全局数据区。
4.2.1 栈空间计算
我建议，每个任务或主循环的栈大小，先估算再实测。
- 估算： 最大调用深度 × 每层局部变量大小 + 中断上下文
- 实测： 栈填充特殊模式（如0xDEAD），运行后检查“水印”
避坑指南： 我曾经在一个项目中，把主栈设为512字节，觉得够用了。结果加了一个新的协议解析函数，里面有个512字节的临时缓冲区。一调用，栈直接溢出，程序跑飞。后来我养成了习惯：所有大缓冲区都用
malloc 分配，或者声明为 static。
4.2.2 硬件检测机制
很多MCU都支持MPU（内存保护单元）或栈溢出检测。
// Cortex-M3/M4 的栈溢出检测示例
// 设置栈底地址，当SP低于该地址时触发异常
void setup_stack_guard(uint32_t stack_bottom) {
// 将栈底所在的页设置为不可访问
MPU->RBAR = stack_bottom & 0xFFFFFFE0;
MPU->RASR = (1 << 0) // 使能
| (3 << 1) // 全权限
| (0 << 3) // 不可执行
| (4 << 4); // 4KB区域
}4.2.3 运行时栈检查
在RTOS中，每个任务都可以查看栈使用峰值。
// FreeRTOS 示例：查看任务栈剩余空间
UBaseType_t uxHighWaterMark;
TaskHandle_t xTask = ...;
uxHighWaterMark = uxTaskGetStackHighWaterMark(xTask);
printf("任务栈剩余: %d 字\n", uxHighWaterMark);
// 如果这个值接近0，说明栈快溢出了4.3 内存碎片化问题定位
碎片化，是堆内存的“癌症”。
你想想看，频繁地申请、释放不同大小的内存块，堆空间就会变得支离破碎。明明总空闲内存还有10KB，但最大连续块只有1KB。这时候你申请一个2KB的缓冲区，就会失败。
4.3.1 碎片化的典型表现
- 系统运行一段时间后，
malloc突然返回NULL - 总内存使用率不高，但分配大块内存失败
- 重启后恢复正常，运行一段时间又出问题
4.3.2 定位方法
我常用的方法，是写一个“堆状态打印”函数。
// 打印堆内存使用情况
void heap_status(void) {
struct mallinfo mi = mallinfo();
printf("总堆空间: %d\n", mi.arena);
printf("已用空间: %d\n", mi.uordblks);
printf("空闲空间: %d\n", mi.fordblks);
printf("最大连续空闲块: %d\n", mi.keepcost);
// 如果 keepcost 远小于 fordblks，说明碎片化严重
}
注意： 在裸机或小型RTOS中，标准库的
mallinfo 可能不可用。你需要自己维护堆管理器的内部数据结构，或者使用支持诊断的堆实现（如 heap_4.c 在 FreeRTOS 中）。
4.3.3 解决策略
| 策略 | 说明 | 适用场景 |
|---|---|---|
| 固定大小内存池 | 预先分配固定大小的块，避免碎片 | 网络缓冲区、消息队列 |
| 伙伴算法 | 按2的幂次分配，合并时容易 | Linux内核、部分RTOS |
| 避免频繁分配/释放 | 用静态数组或对象池替代 | 所有嵌入式系统 |
| 定期整理（压缩） | 移动已分配块，合并空闲区域 | 有MMU或支持重定位的系统 |
我的经验： 对于实时性要求高的系统，我强烈建议使用“固定大小内存池”。虽然会浪费一点空间，但分配时间确定，不会碎片化。我在一个工业控制器项目中，把所有通信帧都限制在64、128、256字节三种大小，从此再没出现过分配失败。
4.4 本章知识体系
下面这张图，是我自己总结的内存分析核心逻辑。你可以把它当作排查时的“路线图”。
嗯，内存分析这块，说白了就是“防患于未然”。
不要等到设备在现场出问题了再排查。在开发阶段就把这些检测机制加进去，能省下大把的调试时间。我个人现在写代码，第一件事就是加上内存追踪和栈保护——这已经成了我的肌肉记忆。