📚 课程目录第4章 C++对象生命周期

4. C++对象生命周期

内存问题，是嵌入式开发里最让人头疼的几类问题之一。我见过不少项目，功能逻辑都跑通了，一上压力测试就崩，查来查去，最后都是内存惹的祸。这一章，咱们就把内存调试的四个核心方向掰开揉碎讲清楚。

  本章核心脉络： 内存泄漏 → 堆栈溢出 → 内存碎片 → MPU/MMU保护。前三个是“诊断”，最后一个是“防护”。诊断不清，防护也无从谈起。

4.1 内存泄漏检测

内存泄漏，说白了就是“只借不还”。你malloc了一块内存，用完了没free，这块内存就再也找不回来了。系统跑得越久，可用内存越少，最后要么分配失败，要么触发OOM。

我在项目中遇到过最隐蔽的一次泄漏：一个定时器回调里，每次触发都malloc一个很小的结构体，但释放条件写错了，只有特定分支才执行free。平时测试数据量小，根本看不出来。产品上线跑了三天，系统挂了。查了两天才定位到。

4.1.1 静态检测：代码审查与工具

静态检测，就是在代码还没跑的时候，靠工具扫描。我个人习惯在提交代码前，先用工具扫一遍。

PC-lint / FlexeLint： 老牌工具，规则极其严格。能检测出“分配了但未释放”的路径。
Cppcheck： 开源免费，对C/C++的内存泄漏检测效果不错。我常用它做快速扫描。
Clang Static Analyzer： 集成在Clang里，分析精度高，能发现一些深层路径上的泄漏。

我的习惯： 静态检测只能发现“确定会泄漏”的情况。对于“条件泄漏”（比如某个错误分支忘了释放），静态工具往往力不从心。这时候就得靠动态检测了。

4.1.2 动态检测：运行时追踪

动态检测，就是在程序运行时，记录每次malloc/free的调用栈。跑完一轮测试，看看哪些内存没被释放。

常用的方法有几种：

方法	原理	适用场景	缺点
Valgrind (Memcheck)	模拟CPU执行，拦截所有内存操作	Linux用户态，功能完整	运行速度极慢（10-50倍），资源受限平台跑不了
AddressSanitizer (ASan)	编译时插桩，运行时检测	Linux/Android，速度较快（2-5倍）	需要编译器支持，增加代码体积
自定义Hook	重写malloc/free，记录分配信息	裸机/RTOS，资源受限	需要自己实现，功能有限

在嵌入式裸机或RTOS环境下，Valgrind基本用不了。我一般自己写一个轻量级的Hook。思路很简单：

// 自定义malloc hook示例
void *my_malloc(size_t size, const char *file, int line) {
    void *ptr = real_malloc(size);
    if (ptr) {
        // 将分配信息记录到链表或哈希表
        record_allocation(ptr, size, file, line);
    }
    return ptr;
}

void my_free(void *ptr) {
    if (ptr) {
        // 从记录中移除
        remove_allocation(ptr);
        real_free(ptr);
    }
}

// 在系统空闲时，打印所有未释放的记录
void dump_leaks(void) {
    print_all_allocations(); // 输出泄漏点
}

注意： 自定义Hook会增加内存开销和运行时间。生产环境中一定要关闭。我曾经在发布版本里忘了关Hook，结果内存占用多了20%，排查了半天才发现。

4.2 堆栈溢出检测

堆栈溢出，比内存泄漏更致命。泄漏是慢慢死，溢出是瞬间崩。函数调用层数太多、局部变量太大、或者中断嵌套过深，都会导致栈指针越界，踩到别人的数据。

你想想看，栈溢出后，程序的行为是完全不可预测的。可能某个全局变量莫名其妙被改了，可能函数返回地址被覆盖了，然后跳到一个奇怪的地方执行。这种bug最难复现。

4.2.1 栈边界检测：Canary与Watermark

最经典的方法，就是在栈的边界放一个“哨兵”。

Canary（金丝雀）： 编译器在函数调用时，在栈帧底部压入一个固定值（比如0xDEADBEEF）。函数返回前检查这个值是否被修改。如果变了，说明栈溢出了。GCC的-fstack-protector就是干这个的。
Watermark（水位标记）： 在任务创建时，把整个栈空间初始化为一个固定模式（比如0xCC）。系统运行时，定期检查栈空间末尾的“水位线”是否被覆盖。如果覆盖了，说明栈使用量接近上限了。

我在项目中遇到过最典型的一次：一个任务里定义了一个512字节的局部数组，但任务栈总共才1024字节。加上函数调用链，栈空间直接爆了。Canary检测到溢出，系统直接panic。如果没有Canary，后果不堪设想。

4.2.2 栈使用量统计

除了检测溢出，我们还需要知道“栈用了多少”。这在RTOS里尤其重要，因为每个任务都有自己的栈。

方法很简单：任务创建时，把整个栈填成0xCC或0x55。任务运行一段时间后，从栈顶往下扫描，找到第一个不是初始值的地址。这个地址到栈底的差值，就是最大栈使用量。

// 统计栈使用量示例（FreeRTOS风格）
uint32_t get_stack_high_water_mark(TaskHandle_t task) {
    StackType_t *stack_start = (StackType_t *)task->pxStack;
    StackType_t *stack_end = stack_start + task->uxStackDepth;
    
    // 从栈顶往下扫描
    for (StackType_t *p = stack_end - 1; p >= stack_start; p--) {
        if (*p != TASK_STACK_FILL_VALUE) {
            // 找到第一个非填充值的位置
            return (uint32_t)(stack_end - p - 1) * sizeof(StackType_t);
        }
    }
    return 0;
}

我的建议： 在产品开发阶段，每个任务都留出30%-50%的栈余量。等稳定后，再根据实际使用量调整。别为了省那几百字节，把系统稳定性搭进去。

4.3 内存碎片分析

内存碎片，是动态内存分配的头号杀手。系统跑着跑着，明明总空闲内存还有不少，但就是分配不出一个连续的大块。这就是碎片化。

为什么会这样？你想想看，频繁地malloc和free，内存被切得七零八落。大块的空闲块被分割成小块，小块之间又夹着已分配的内存。最后，最大的连续空闲块可能只有几十字节。

4.3.1 碎片度量指标

怎么量化碎片程度？我常用两个指标：

指标	定义	含义
最大连续空闲块	堆中最大的连续空闲区域大小	能分配的最大单次请求
碎片率	1 - (最大连续空闲块 / 总空闲内存)	越接近1，碎片越严重

举个例子：总空闲内存有10KB，但最大连续空闲块只有1KB。碎片率就是1 - (1/10) = 0.9。这个值超过0.5，就要警惕了。

4.3.2 碎片可视化

光看数字不够直观。我习惯把堆内存的状态画出来。下面这张图，就是一次典型的碎片分布：

4.3.3 碎片防治策略

碎片一旦产生，很难消除。最好的办法是预防。

固定大小内存池： 如果分配的对象大小是固定的（比如网络包、消息结构体），用内存池代替malloc。没有碎片问题。
伙伴算法（Buddy System）： 把内存按2的幂次分成块。分配和释放时，相邻的块可以合并。碎片率比普通malloc低很多。
避免频繁分配释放： 能静态分配的就静态分配。实在要动态，尽量在初始化阶段一次分配完。

我曾经踩过的坑： 在一个音频处理项目里，每次处理一帧数据就malloc一个缓冲区，处理完就free。跑了几分钟后，系统开始卡顿。一查，碎片率高达0.8。后来改成环形缓冲区，问题彻底解决。

4.4 MPU/MMU配置与保护

前面讲的都是“诊断”。但最好的调试，是让问题根本发生不了。MPU（内存保护单元）和MMU（内存管理单元）就是干这个的。

MPU常见于Cortex-M系列MCU，MMU常见于Cortex-A系列和应用处理器。它们的作用类似：给内存区域设置访问权限。谁可以读、谁可以写、谁可以执行，都由你说了算。

4.4.1 MPU配置实战

以Cortex-M4为例，MPU最多支持8个区域。每个区域可以独立配置起始地址、大小、访问权限。

我一般这样配置：

代码区（Flash）： 只读+可执行。防止代码被意外修改。
数据区（SRAM）： 可读+可写，但不可执行。防止栈溢出后执行恶意代码。
外设区： 强序访问，不可缓存。保证外设寄存器访问的正确性。
关键数据区： 比如任务栈、系统堆，设置成特权级才能访问。用户任务访问会触发异常。

// MPU配置示例（Cortex-M4）
void MPU_Config(void) {
    // 禁用MPU
    MPU->CTRL = 0;
    
    // 区域0：Flash (0x08000000, 512KB) - 只读，可执行
    MPU->RBAR = (0x08000000 & MPU_RBAR_ADDR_Msk) | (0 << 4);
    MPU->RASR = (0x1 << 0) |  // 使能
                 (0x3 << 1) |  // 全访问（特权+用户）
                 (0x0 << 3) |  // 不可执行？这里设为可执行
                 (0x1 << 8) |  // 区域大小：2^(1+8) = 512KB
                 (0x0 << 16);  // 禁止写
    
    // 区域1：SRAM (0x20000000, 128KB) - 可读写，不可执行
    MPU->RBAR = (0x20000000 & MPU_RBAR_ADDR_Msk) | (1 << 4);
    MPU->RASR = (0x1 << 0) |
                 (0x3 << 1) |
                 (0x1 << 3) |  // 不可执行
                 (0x6 << 8) |  // 2^(6+8) = 128KB
                 (0x1 << 16);  // 允许写
    
    // 使能MPU，并启用默认区域映射
    MPU->CTRL = MPU_CTRL_ENABLE_Msk | MPU_CTRL_PRIVDEFENA_Msk;
    
    // 同步
    __DSB();
    __ISB();
}

注意： 配置MPU后，如果某个任务访问了未授权的区域，会触发MemManage Fault。这个fault处理函数里，可以打印出访问地址和当前任务信息，对调试帮助极大。

4.4.2 MMU与页表

MMU比MPU复杂得多。它不光做权限控制，还做虚拟地址到物理地址的映射。在嵌入式Linux里，每个进程都有自己的虚拟地址空间，互不干扰。这就是MMU的功劳。

MMU的核心是页表。页表里每一项（PTE）都记录了虚拟页到物理页的映射关系，以及访问权限。

页表项字段	作用
物理页帧号 (PFN)	映射到的物理页地址
可读 (R)	允许读访问
可写 (W)	允许写访问
可执行 (X)	允许执行
用户/特权 (U/S)	区分用户态和内核态访问
存在位 (P)	该页是否在物理内存中

在调试MMU相关问题时，我常用的手段是：

检查页表： 通过/proc/pid/maps查看进程的内存映射。看看有没有意外的映射区域。
触发缺页异常： 故意访问一个未映射的地址，观察内核的缺页处理流程。这能帮你理解MMU的工作机制。
使用KASAN： Linux内核里的动态内存检测工具，利用MMU的shadow内存来检测越界和释放后使用。

  一句话总结： MPU/MMU不是摆设。配置得当，它们能把大部分内存问题挡在门外。即使出了问题，也能让你第一时间知道“谁、在哪儿、干了什么坏事”。

嗯，内存调试这块，内容确实不少。从泄漏到溢出，从碎片到保护，每一步都有坑。但只要你把这些工具和方法用熟了，遇到内存问题就不会慌了。记住，预防永远比事后排查更省心。