📚 课程目录第4章内存分析与诊断

4、内存分析与诊断：内存泄漏检测、栈溢出分析、堆碎片化问题、内存映射查看

内存问题，是嵌入式开发里最让人头疼的几类Bug之一。说实话，我见过太多项目因为内存泄漏或者栈溢出，在产线上批量出问题，最后查出来原因其实很简单——就是当初写代码时少了个free，或者中断里定义了个大数组。

这一章，咱们就把内存相关的几个硬骨头啃下来。我会结合自己踩过的坑，把内存泄漏、栈溢出、堆碎片化和内存映射这几个话题讲透。

  核心观点：嵌入式系统的内存是有限的，而且往往是静态分配的。动态内存用不好，系统迟早会崩。你想想看，一个跑了几百个小时的设备突然死机，多半就是内存出了问题。

4.1 内存泄漏检测

内存泄漏，说白了就是申请了内存，用完之后没还回去。一次两次没事，但日积月累，堆空间就被吃光了。

我在项目中遇到过最典型的一个案例：一个数据采集设备，运行三天后死机。查了两天，最后发现是一个回调函数里每次调用都malloc了128字节，但只在特定条件下才free。条件不满足时，内存就漏了。

4.1.1 常见泄漏场景

异常路径未释放：函数中有多个return点，部分路径忘了free
容器元素删除时未释放：链表、队列中移除节点时只删了指针
重赋值导致指针丢失：同一个指针被重新malloc，旧地址没人管了
回调函数中的隐式分配：库函数内部malloc了内存，使用者不知道要释放

4.1.2 手动检测方法

在资源受限的MCU上，不一定能跑valgrind。我个人的习惯是写一个简单的内存跟踪模块：

// 简易内存跟踪器
#define MAX_ALLOC_RECORDS 256

typedef struct {
    void *addr;
    size_t size;
    const char *file;
    int line;
} alloc_record_t;

static alloc_record_t records[MAX_ALLOC_RECORDS];
static int record_count = 0;

void *track_malloc(size_t size, const char *file, int line) {
    void *ptr = malloc(size);
    if (ptr && record_count < MAX_ALLOC_RECORDS) {
        records[record_count].addr = ptr;
        records[record_count].size = size;
        records[record_count].file = file;
        records[record_count].line = line;
        record_count++;
    }
    return ptr;
}

void track_free(void *ptr) {
    for (int i = 0; i < record_count; i++) {
        if (records[i].addr == ptr) {
            // 标记为已释放
            records[i].addr = NULL;
            break;
        }
    }
    free(ptr);
}

void dump_leaks(void) {
    for (int i = 0; i < record_count; i++) {
        if (records[i].addr != NULL) {
            printf("LEAK: %p size=%u at %s:%d\n",
                   records[i].addr, records[i].size,
                   records[i].file, records[i].line);
        }
    }
}

我的习惯：在开发阶段，我会把malloc和free都宏定义成带文件名和行号的版本。这样一旦发现泄漏，直接就能定位到代码位置，不用猜。

4.1.3 静态分析工具

除了运行时跟踪，静态分析也能发现不少问题。我个人常用的是PC-Lint和Cppcheck。它们能检测出一些明显的路径泄漏：

// Cppcheck能发现这种问题
char *get_buffer(void) {
    char *buf = malloc(256);
    if (!buf) return NULL;
    // 如果条件不满足，buf就泄漏了
    if (some_condition) {
        return buf;  // 正常路径
    }
    // 这里缺少free(buf);
    return NULL;  // 泄漏！
}

4.2 栈溢出分析

栈溢出比内存泄漏更隐蔽。泄漏是慢慢耗光内存，栈溢出是瞬间崩掉。我记得有一次调试一个电机控制程序，现象是跑着跑着就进HardFault，查了半天才发现是中断里定义了一个512字节的局部数组。

4.2.1 栈溢出的典型表现

现象	可能原因
函数返回后PC指针异常	栈空间被覆盖，返回地址损坏
局部变量值莫名其妙变化	栈溢出踩到了相邻函数的栈帧
递归调用深度过大	每层递归都消耗栈空间
中断嵌套过深	多个中断共享同一个栈区域

4.2.2 栈使用量估算方法

我一般用两种方法来估算栈使用量：

静态分析：查看反汇编，统计每个函数的栈帧大小，然后分析调用链的最大深度
栈填充法：初始化时用固定模式填充栈空间（比如0xDEADBEEF），运行一段时间后检查有多少被覆盖了

// 栈填充检测示例
#define STACK_FILL_PATTERN 0xDEADBEEF
#define STACK_SIZE 1024

static uint32_t stack_area[STACK_SIZE / 4];

void init_stack_monitor(void) {
    for (int i = 0; i < STACK_SIZE / 4; i++) {
        stack_area[i] = STACK_FILL_PATTERN;
    }
}

uint32_t get_stack_usage(void) {
    uint32_t used = 0;
    for (int i = STACK_SIZE / 4 - 1; i >= 0; i--) {
        if (stack_area[i] != STACK_FILL_PATTERN) {
            used = (i + 1) * 4;
            break;
        }
    }
    return used;
}

曾经踩过的坑：我曾经在一个项目中把中断栈和主栈设成共享的。结果一个高频率的中断里调用了printf，printf内部又用了不小的栈空间，直接导致主任务栈溢出。后来我强制把中断栈独立出来，问题就解决了。

4.3 堆碎片化问题

堆碎片化，是动态内存管理的另一个大敌。你想想看，虽然总空闲空间可能还有好几KB，但都是零零散散的小块，连一个256字节的连续区域都分配不出来。

4.3.1 碎片化的成因

说白了，就是频繁地分配和释放不同大小的内存块。分配器在合并相邻空闲块时，如果做不到完美合并，碎片就会越来越多。

我在项目中遇到过最严重的一次：一个网络协议栈，每收到一个包就malloc，处理完就free。包大小从几十字节到一千多字节不等。跑了几个小时之后，malloc开始返回NULL，但实际空闲总量还有60%。

4.3.2 碎片化检测方法

检测碎片化，我一般看两个指标：

指标	计算方法	健康值
碎片率	1 - (最大连续块 / 总空闲大小)	< 0.3
分配失败率	malloc返回NULL的次数 / 总分配次数	0%

// 简单碎片检测函数
typedef struct {
    uint32_t total_free;
    uint32_t max_free_block;
    uint32_t fragment_count;
} heap_info_t;

void get_heap_info(heap_info_t *info) {
    // 遍历空闲链表，统计信息
    // 具体实现依赖使用的堆分配器
    // 这里只是示意
    info->fragment_rate = 1.0f - 
        (float)info->max_free_block / info->total_free;
}

4.3.3 应对策略

固定大小内存池：预分配几个不同大小的内存池，避免频繁malloc/free
尽量使用栈分配：能放栈上的就别用堆
避免频繁分配释放：用对象池或缓存机制复用内存
选择合适分配器：有些分配器（如TLSF）天生抗碎片化能力强

我的建议：在实时性要求高的系统中，尽量在初始化阶段就把所有内存分配好。运行期间只使用，不分配。这样既避免了碎片化，也避免了分配耗时带来的不确定性。

4.4 内存映射查看

内存映射，就是搞清楚你的程序把代码、数据、堆、栈都放在了哪里。调试内存问题时，不看内存映射图，就像蒙着眼睛找东西。

4.4.1 链接脚本与内存布局

每个嵌入式项目都有一个链接脚本（.ld文件），它定义了各段的起始地址和大小。我每次接手一个新项目，第一件事就是看链接脚本：

/* 典型的STM32链接脚本片段 */
MEMORY
{
    FLASH (rx)  : ORIGIN = 0x08000000, LENGTH = 512K
    RAM   (xrw) : ORIGIN = 0x20000000, LENGTH = 128K
}

SECTIONS
{
    .text : { *(.text*) } > FLASH
    .data : { *(.data*) } > RAM AT> FLASH
    .bss  : { *(.bss*) }  > RAM
    .heap : { . = ALIGN(8); _heap_start = .; } > RAM
    .stack : { . = ALIGN(8); _stack_start = .; } > RAM
}

4.4.2 运行时内存映射查看

在调试器里，我经常用以下命令查看内存布局：

info mem：查看GDB中的内存映射
info registers：查看SP、PC等关键寄存器
查看map文件：编译器生成的.map文件包含了所有符号的地址

我自己写过一个小的内存映射打印函数，可以在串口上输出当前的内存使用情况：

void print_memory_map(void) {
    extern uint32_t _text_start, _text_end;
    extern uint32_t _data_start, _data_end;
    extern uint32_t _bss_start, _bss_end;
    extern uint32_t _heap_start, _heap_end;
    extern uint32_t _stack_start, _stack_end;

    printf("=== Memory Map ===\n");
    printf(".text:  0x%08X - 0x%08X (%u bytes)\n",
           &_text_start, &_text_end,
           (uint32_t)&_text_end - (uint32_t)&_text_start);
    printf(".data:  0x%08X - 0x%08X (%u bytes)\n",
           &_data_start, &_data_end,
           (uint32_t)&_data_end - (uint32_t)&_data_start);
    printf(".bss:   0x%08X - 0x%08X (%u bytes)\n",
           &_bss_start, &_bss_end,
           (uint32_t)&_bss_end - (uint32_t)&_bss_start);
    printf(".heap:  0x%08X - 0x%08X (%u bytes)\n",
           &_heap_start, &_heap_end,
           (uint32_t)&_heap_end - (uint32_t)&_heap_start);
    printf(".stack: 0x%08X - 0x%08X (%u bytes)\n",
           &_stack_start, &_stack_end,
           (uint32_t)&_stack_end - (uint32_t)&_stack_start);
}

注意：堆和栈的地址范围在链接脚本里定义，但实际使用中它们可能会相向生长。如果堆向上增长、栈向下增长，它们在中途相遇时就会出问题。我建议在堆和栈之间留一个保护区域，或者用MPU做硬件保护。

4.5 知识体系总览

下面这张图，把本章的内存问题诊断体系串起来了。你可以把它当作一个检查清单：遇到内存问题，按这个流程走一遍，基本能定位到根因。

嗯，这一章的内容就到这里。内存问题诊断，说白了就是要有工具、有方法、有经验。工具和方法我可以教给你，经验需要你在实际项目中慢慢积累。下次遇到内存相关的Bug，别慌，按这个体系一步步排查，大部分问题都能搞定。