1. 为什么嵌入式内存管理值得单独开一堂课做嵌入式开发这些年被问得最多的问题里“内存怎么又不够了”绝对排得进前三。MCU 上跑裸机程序RAM 就几十 KB堆栈稍微一抖就 HardFault上了 RTOS任务栈、消息队列、动态内存池层层叠加一个没算准跑几个小时就死机。更别提嵌入式 Linux 那边用户态一个 malloc 没配对 free进程的 RSS 一路涨到 OOM Killer 出手。这堂课我想把嵌入式内存这件事从头到尾捋一遍。不是那种“malloc 申请、free 释放”的教科书式讲法而是从实际项目里踩过的坑出发把裸机、RTOS、嵌入式 Linux 三个层面的内存管理串起来讲。你会看到堆和栈到底怎么划分、malloc 在 RTOS 里为什么经常被禁用、内存碎片是怎么把系统搞死的、以及怎么用工具把内存泄漏揪出来。适合谁看刚入行做嵌入式、被内存问题折磨过的朋友从裸机转 RTOS、发现 malloc 不好使的兄弟还有做嵌入式 Linux 应用、想搞清楚进程内存模型的开发者。不管你现在在哪一层这篇内容都能给你一套可落地的方法。2. 嵌入式内存的整体版图与设计取舍2.1 裸机、RTOS、Linux 三层内存模型对比先把三层的内存版图摆清楚不然后面聊 malloc 和 free 容易混。裸机程序的内存布局非常朴素Flash 里放代码和常量RAM 里分三块——全局/静态区、堆区、栈区。栈从 RAM 高地址往下长堆从低地址往上长中间留一段空隙。栈主要给函数调用、局部变量、中断现场用堆就是 malloc 的地盘。很多小型 MCU 项目干脆不用堆所有变量都静态分配图的就是确定性。RTOS 上来之后情况复杂了。每个任务有自己的栈任务栈大小在创建时就得定死。RTOS 内核本身还需要一块系统堆来分配任务控制块、队列、信号量这些对象。这时候 malloc 就有两种来源一种是编译器自带的 C 库堆一种是 RTOS 提供的专用内存池。这两者混用是很多 bug 的根源。嵌入式 Linux 则是另一套玩法。每个进程有独立的虚拟地址空间分为代码段、数据段、BSS 段、堆、栈、mmap 区。malloc 在用户态申请内存背后可能是 brk 扩展堆顶也可能是 mmap 映射一块新区域。物理内存由内核的伙伴系统和 slab 分配器管理用户态看到的都是虚拟地址。层级内存管理方式典型堆大小主要风险裸机静态分配为主少量 malloc几 KB 到几十 KB栈溢出、堆碎片RTOS任务栈 系统堆 内存池几十 KB 到几百 KB任务栈溢出、堆碎片、优先级反转嵌入式 Linux虚拟内存 伙伴系统 slab几 MB 到几百 MB内存泄漏、OOM、碎片这张表不是让你背的是让你在选方案时有个参照。我见过太多人拿 Linux 那套思维去做 RTOS 项目上来就 malloc 一把梭结果跑两天就崩。2.2 静态分配与动态分配的取舍逻辑嵌入式圈有句老话能静态就别动态。这话不是保守是血泪教训。静态分配的好处是确定性。编译期就知道内存用多少链接脚本一配map 文件一看心里有底。缺点是灵活性差比如你要支持不同数量的设备连接静态数组就得按最大值开浪费。动态分配的好处是灵活按需申请。但代价是碎片、不确定性、失败路径难处理。malloc 返回 NULL 的时候你怎么办很多代码直接不处理然后解引用空指针崩。我的经验是分场景生命周期贯穿整个程序的资源静态分配。比如系统配置、全局缓冲区。生命周期明确、大小固定的资源用内存池。比如网络包缓冲、任务间消息。生命周期短、大小不定的才考虑 malloc而且要配一套失败处理逻辑。这个取舍逻辑贯穿后面所有内容。你看到任何一个内存方案先问自己这个资源的生命周期是多长大小是否可预测失败了我能不能兜住2.3 内存碎片嵌入式系统最隐蔽的杀手碎片这东西平时不显山不露水等到系统跑了一周突然分配失败你才发现堆已经千疮百孔。碎片分两种。外部碎片是空闲内存总量够但不连续凑不出一块大的。内部碎片是分配出去的块比实际需要的大多出来的部分浪费了。举个例子。堆有 10KB你依次申请 1KB、2KB、3KB、4KB然后释放 1KB 和 3KB。现在空闲总量是 4KB但分成两块 1KB 和 3KB不连续。这时候你要申请 4KB直接失败。这就是外部碎片。嵌入式系统里碎片特别容易积累因为内存小、分配频繁、块大小多变。RTOS 里如果用 C 库的 malloc碎片问题几乎无解。所以 FreeRTOS 才提供了 heap_1 到 heap_5 五种堆实现其中 heap_4 带合并相邻空闲块的功能heap_5 还支持多块不连续内存区域。注意heap_4 的合并只能合并物理相邻的空闲块如果你的分配模式是“大块和小块交替申请释放”碎片照样会产生。真正抗碎片的是固定大小内存池。3. malloc 与 free 在嵌入式里的真实面目3.1 malloc 到底做了什么从 brk 到内存池很多人以为 malloc 就是“向系统要内存”其实在嵌入式里malloc 的行为取决于你用的是哪套实现。在裸机和 RTOS 上malloc 通常是 C 库自带的实现它管理一块叫 heap 的连续内存区域。这块区域的起点和大小由链接脚本决定比如 STM32 的启动文件里_heap_start和_heap_end就定义了堆的范围。malloc 在这块区域里维护一个空闲链表每次分配就找一块够大的空闲块切一块出来剩下的还回去。在嵌入式 Linux 上malloc 是 glibc 或 musl 的实现。小块内存从堆顶通过 brk 扩展大块内存默认超过 128KB用 mmap 单独映射。glibc 的 malloc 还有 per-thread arena 的概念多线程环境下每个线程有自己的分配区减少锁竞争。关键点在于嵌入式里的 malloc 不是无限的。堆就那么大用完了就返回 NULL。而且很多 RTOS 的 malloc 不是线程安全的多任务同时调用会出问题。FreeRTOS 就明确建议用 pvPortMalloc 而不是 malloc因为前者带临界区保护。3.2 free 之后内存去哪了释放不等于归还这是新手最容易误解的地方。free 之后内存不一定还给系统大多数情况下只是标记为空闲还给堆管理器。在裸机和 RTOS 上free 把块放回空闲链表可能和相邻空闲块合并。但物理内存还是那块不会“消失”。所以你看 map 文件堆的大小始终不变变的是空闲链表的分布。在 Linux 上free 之后 glibc 可能把内存还给内核通过 brk 收缩或 munmap也可能留在 arena 里备用。这就是为什么你看进程的 RSSfree 之后不一定马上降。很多嵌入式 Linux 开发者看到 RSS 不降就以为泄漏了其实只是 glibc 没还。提示判断是否真泄漏不能只看 RSS。用 valgrind 或 AddressSanitizer 跑一遍看有没有“definitely lost”的块那才是真泄漏。3.3 为什么 RTOS 里经常禁用 mallocFreeRTOS 官方文档里有一句话在实时系统里malloc 和 free 通常是不推荐的。原因有三。第一不确定性。malloc 的执行时间取决于空闲链表的长度和碎片程度最坏情况可能遍历整个链表。实时系统要求确定性这个不可接受。第二碎片。前面讲过了频繁分配释放必然产生碎片最终导致分配失败。第三线程安全。C 库的 malloc 不一定线程安全多任务环境下需要加锁加锁又引入优先级反转风险。所以 FreeRTOS 提供了五种堆实现heap_1只分配不释放最简单适合任务创建后不再动态分配的系统。heap_2可释放但不合并适合分配大小固定的场景。heap_3包装 C 库的 malloc/free加了线程安全。heap_4可释放且合并相邻空闲块最常用。heap_5在 heap_4 基础上支持多块不连续内存区域。选哪个我的建议是如果任务和队列都在启动时创建好用 heap_1零碎片风险。如果需要运行中动态创建删除用 heap_4。如果内存分布在多个不连续的 RAM 区比如内部 SRAM 外部 SDRAM用 heap_5。3.4 内存池比 malloc 更靠谱的选择内存池的思路很简单预先分配一大块内存切成固定大小的块用一个空闲链表管理。申请时从链表取一块释放时还回去。没有碎片因为所有块大小一样时间确定因为就是链表操作。在 RTOS 里消息队列、信号量这些对象通常就是用内存池管理的。你自己写应用时也可以为频繁分配释放的对象建内存池。比如网络协议栈的包缓冲每个包固定 1500 字节建一个 32 块的池子比 malloc 靠谱得多。内存池的缺点是灵活性差。块大小固定申请不同大小的对象就得建多个池子。而且池子空了怎么办要么阻塞等待要么返回失败。这需要你在设计阶段就想清楚。我做过一个项目用内存池管理 Modbus 帧缓冲池子大小 16 块每块 256 字节。跑了一年多零碎片、零分配失败。换成 malloc 的话估计撑不过一个月。4. 实操从裸机到 RTOS 的内存管理落地4.1 裸机项目链接脚本与栈堆划分裸机项目的第一步是看链接脚本。以 GCC 为例.ld文件里定义了 MEMORY 区域和 SECTION 布局。MEMORY { FLASH (rx) : ORIGIN 0x08000000, LENGTH 512K RAM (rwx) : ORIGIN 0x20000000, LENGTH 128K } _estack ORIGIN(RAM) LENGTH(RAM);栈顶_estack设在 RAM 最高地址栈向下生长。堆的起点通常在 BSS 段之后终点是栈底减去一个安全余量。_heap_start _end; _heap_end _estack - 0x400;这个0x400是留给栈的安全余量。怎么定看你的中断嵌套深度和局部变量大小。我一般留 1KB如果用了浮点运算或递归留 2KB。栈大小怎么估算最笨也最有效的办法在栈区域填充特定模式比如 0xDEADBEEF跑一遍所有功能然后看有多少模式被改写了。改写的深度就是栈的最大使用量再乘个 1.5 倍安全系数。注意中断服务函数用的栈可能是主栈也可能是独立的中断栈取决于 MCU 架构。Cortex-M 默认用主栈所以中断嵌套会加深栈使用。别只测主循环要带着中断一起测。4.2 FreeRTOS 任务栈大小怎么算才不翻车FreeRTOS 创建任务时usStackDepth参数的单位是字不是字节。Cortex-M 上一个字 4 字节所以usStackDepth 128实际是 512 字节。这个坑我见过太多人踩。栈大小怎么定FreeRTOS 提供了两个工具。一是uxTaskGetStackHighWaterMark()返回任务运行过程中栈剩余的最小值。二是configCHECK_FOR_STACK_OVERFLOW设为 2 时会在任务切换时检查栈是否溢出溢出就调用vApplicationStackOverflowHook。我的做法是先给一个偏大的值比如 512 字跑完所有功能看 high water mark。如果剩余很多逐步减小如果剩余很少加大。最终值留 30% 余量。void vTaskFunction(void *pvParameters) { for (;;) { // 任务逻辑 UBaseType_t watermark uxTaskGetStackHighWaterMark(NULL); printf(Stack watermark: %u\n, watermark); vTaskDelay(pdMS_TO_TICKS(1000)); } }这个 watermark 是“历史最小剩余”单位是字。如果它接近 0说明栈快满了赶紧加。还有一个坑在任务里调用 printf 或 sprintf这些函数可能占用大量栈空间。我见过一个任务栈设了 256 字加了 printf 之后直接溢出。解决办法是用vsnprintf到固定缓冲或者把日志任务单独拆出来。4.3 用 heap_4 还是 heap_5多块 RAM 区的处理有些 MCU 有多个不连续的 RAM 区比如 STM32H7 有 DTCM、AXI SRAM、SRAM1-4。默认的 heap 只能覆盖一个连续区域。这时候用 heap_5。heap_5 的用法是定义HeapRegion_t数组然后调用vPortDefineHeapRegions。const HeapRegion_t xHeapRegions[] { { (uint8_t *)0x20000000, 0x10000 }, // 64KB { (uint8_t *)0x24000000, 0x20000 }, // 128KB { NULL, 0 } }; vPortDefineHeapRegions(xHeapRegions);注意这个函数必须在创建任何 RTOS 对象之前调用而且只能调一次。调用之后pvPortMalloc 就会在这两块区域里分配。heap_5 的分配策略是首次适应从第一个区域开始找。如果第一个区域碎片化了即使第二个区域有大块空闲也可能分配失败。所以我的建议是把频繁分配的小对象放在一个区域大块内存放在另一个区域减少交叉。4.4 内存泄漏排查从 map 文件到运行时监控嵌入式里的内存泄漏排查比 Linux 难因为没有 valgrind。但有几招管用。第一招看 map 文件。编译后生成的.map文件里有每个符号的地址和大小。如果某个全局数组异常大或者堆的起点终点不对一眼就能看出来。第二招运行时监控。在 pvPortMalloc 和 vPortFree 里加钩子记录当前空闲堆大小。FreeRTOS 提供了xPortGetFreeHeapSize()和xPortGetMinimumEverFreeHeapSize()。前者返回当前空闲后者返回历史最小空闲。如果当前空闲持续下降基本就是泄漏。void vMonitorTask(void *pvParameters) { for (;;) { size_t free_heap xPortGetFreeHeapSize(); size_t min_heap xPortGetMinimumEverFreeHeapSize(); printf(Free: %u, Min: %u\n, free_heap, min_heap); vTaskDelay(pdMS_TO_TICKS(5000)); } }第三招包装 malloc/free。自己写一层my_malloc和my_free在块头加一个魔数和大小释放时检查魔数。这样能抓到重复释放和越界写。typedef struct { uint32_t magic; size_t size; } mem_header_t; void *my_malloc(size_t size) { mem_header_t *h pvPortMalloc(size sizeof(mem_header_t)); if (!h) return NULL; h-magic 0xDEADBEEF; h-size size; return (void *)(h 1); } void my_free(void *ptr) { if (!ptr) return; mem_header_t *h (mem_header_t *)ptr - 1; if (h-magic ! 0xDEADBEEF) { printf(Memory corruption detected!\n); return; } h-magic 0; vPortFree(h); }这套包装会增加一点开销但在调试阶段非常值。5. 嵌入式 Linux 侧的内存管理要点5.1 进程内存模型与 malloc 的底层行为嵌入式 Linux 上跑应用内存模型和桌面 Linux 一样但资源更紧张。每个进程有 4GB 虚拟地址空间32 位其中用户态占 3GB内核态占 1GB。实际物理内存可能只有 128MB 或 256MB。malloc 在 glibc 里的行为小于 128KB 的分配走 brk从堆顶扩展大于等于 128KB 的走 mmap单独映射一块。这个阈值可以通过M_MMAP_THRESHOLD调整。为什么关心这个因为 brk 扩展的内存free 之后不一定还给内核可能留在进程的堆里。而 mmap 的内存free 之后直接 munmap 还给内核。所以如果你频繁申请释放大块内存RSS 会上下波动如果是小块RSS 可能只涨不降。在嵌入式设备上我通常会把M_MMAP_THRESHOLD调小比如 64KB让更多分配走 mmap这样释放后能真正还给系统。设置方法是在程序启动时调用mallopt(M_MMAP_THRESHOLD, 64*1024)。5.2 内存泄漏检测valgrind 与 AddressSanitizer嵌入式 Linux 上跑 valgrind 比较重但如果是 Cortex-A 级别的芯片跑得动。用法很简单valgrind --leak-checkfull --show-leak-kindsall ./my_app输出会告诉你哪些块“definitely lost”、“indirectly lost”、“possibly lost”。definitely lost 就是真泄漏必须修。如果 valgrind 太重用 AddressSanitizer。编译时加-fsanitizeaddress -g运行时会检测越界、释放后使用、泄漏。ASan 的性能开销比 valgrind 小适合在设备上跑。gcc -fsanitizeaddress -g -o my_app my_app.c ./my_appASan 会在程序退出时打印泄漏报告。注意 ASan 需要链接 libasan嵌入式根文件系统里要带上。还有一个轻量方案mtrace。glibc 自带通过MALLOC_TRACE环境变量指定日志文件然后在代码里调用mtrace()开始记录muntrace()结束。用mtrace命令分析日志。这个方案开销极小适合资源紧张的设备。5.3 OOM Killer 与内存水位调优嵌入式 Linux 上内存耗尽时内核的 OOM Killer 会挑一个进程杀掉。挑谁看oom_score分数高的先杀。分数和进程的内存占用、运行时间、优先级有关。你可以通过/proc/pid/oom_score_adj调整分数范围 -1000 到 1000。-1000 表示永不被杀。关键进程可以设成 -1000防止被误杀。echo -1000 /proc/$(pidof my_critical_app)/oom_score_adj但更好的做法是预防 OOM。几个手段限制进程内存用 cgroup 的 memory 子系统给每个进程设上限。监控内存水位读/proc/meminfo的MemAvailable低于阈值就告警或重启服务。用 zram 或 zswap压缩内存相当于变相扩容。嵌入式设备上 zram 很实用配置得当能省 30% 到 50% 内存。注意zram 用的是 CPU 换内存如果 CPU 本来就吃紧开了反而更卡。先测 CPU 负载再决定。5.4 嵌入式 Qt 应用的内存优化实践嵌入式 Qt 应用内存占用大是出了名的。一个简单的界面跑起来 RSS 可能就 50MB 起。优化手段有几个。第一用 QWidget 而不是 QML。QML 的 JavaScript 引擎和场景图开销大QWidget 轻量得多。如果非要用 QML用 Qt Quick Ultralite 或 Qt for MCU。第二裁剪 Qt 模块。编译 Qt 时只选需要的模块去掉 WebEngine、Multimedia 这些大块头。用-skip参数跳过不需要的模块。第三图片资源用 QResource 编译进二进制避免运行时加载。大图用 JPEG 而不是 PNG解码后及时释放。第四字体裁剪。嵌入式设备不需要完整字体库用fontconfig或Qt的字体子集工具只保留用到的字符。第五监控 QWidget 的创建销毁。Qt 的对象树机制下父对象销毁会连带销毁子对象。但如果你手动 new 了一个没有父对象的 widget忘了 delete就泄漏了。用QScopedPointer或QSharedPointer管理生命周期。我做过一个 800x480 的工业 HMI用 QWidget裁剪后 Qt 库 8MB应用 RSS 稳定在 25MB 左右。同样的界面用 QMLRSS 直接 60MB 起。6. 常见问题与排查技巧实录6.1 内存问题速查表现象可能原因排查手段解决方向HardFaultPC 指向异常地址栈溢出、空指针解引用看 LR 和 PC查 map 文件加大栈、检查 malloc 返回值跑一段时间后 malloc 返回 NULL内存泄漏、碎片监控空闲堆大小修泄漏、换内存池任务切换时死机任务栈溢出开 configCHECK_FOR_STACK_OVERFLOW加大任务栈Linux 进程 RSS 持续上涨内存泄漏valgrind、ASan修泄漏、调 mmap 阈值系统突然变慢OOM Killer 杀进程内存耗尽看 dmesg、/proc/meminfo限制进程内存、开 zramfree 之后 RSS 不降glibc 未归还内存看 malloc_trim调 M_MMAP_THRESHOLD、手动 trim这张表建议打印出来贴工位上。遇到问题先对号入座能省不少时间。6.2 那些年我踩过的内存坑坑一在中断里调用 malloc。C 库的 malloc 不是中断安全的在 ISR 里调用可能死锁或破坏堆。FreeRTOS 的 pvPortMalloc 如果在中断里调用必须用pvPortMalloc的 FromISR 版本但 heap_4 本身不带 FromISR 接口。正确做法是在中断里发信号给任务由任务去分配。坑二任务栈单位搞错。FreeRTOS 的usStackDepth是字不是字节。我见过有人写xTaskCreate(task, t, 512, ...)以为是 512 字节实际是 2048 字节。反过来也有人写 128 以为是 128 字节实际 512 字节结果栈不够。坑三字符串常量放 RAM。const char *str hello;这个字符串在 Flash 里不占 RAM。但char str[] hello;是数组在 RAM 里。大量字符串用数组形式RAM 很快就不够了。用const加指针或者用PROGMEM之类的宏。坑四递归函数在嵌入式里失控。递归深度不可预测栈很快爆。嵌入式里尽量用迭代代替递归。如果非要用限制深度并监控栈水位。坑五结构体对齐浪费内存。struct { char a; int b; char c; }在 32 位系统上占 12 字节不是 6 字节。调整成员顺序把大的放前面能省不少。用__attribute__((packed))可以取消对齐但访问速度会降而且某些架构不支持非对齐访问。6.3 内存调试工具链推荐裸机和 RTOS 侧SEGGER RTT实时传输调试信息不占串口速度快。SystemView可视化任务切换和中断间接看栈使用。FreeRTOSTraceFreeRTOS 自带的分析工具看堆使用曲线。嵌入式 Linux 侧valgrind重量级但全面。AddressSanitizer轻量级适合设备上跑。mtraceglibc 自带开销最小。perf看内存相关的性能事件。smem看进程的 PSS 和 USS比 RSS 准确。我一般组合使用开发阶段用 ASan 快速定位集成测试用 valgrind 全面扫描上线后用 smem 和自定义监控长期观察。6.4 内存优化的几个实用技巧技巧一用位域压缩标志位。一个uint8_t存 8 个布尔标志比 8 个bool省 7 字节。大量标志位场景下很可观。技巧二用联合体共享内存。互斥的变量放联合体里同一时间只用一个。比如通信协议的不同帧类型用联合体解析省一块缓冲。技巧三缓冲区复用。不要每个模块都开自己的缓冲搞一个全局缓冲池按需借用。网络协议栈、文件系统、UI 渲染可以共用。技巧四延迟分配。不是所有内存都要在初始化时申请。用到再申请用完就释放。但要注意失败路径。技巧五用内存映射文件代替读文件到内存。大文件处理时mmap 比 read 到缓冲更省内存因为内核按页加载不用一次性全读进来。这些技巧单个看省得不多但组合起来一个项目省 20% 到 30% RAM 是常事。嵌入式里省下来的内存就是竞争力。7. 从内存课延伸出去的学习路径内存管理只是嵌入式系统的一个切面但它串起了很多知识点。往下挖你会碰到链接脚本、启动流程、MMU、cache 一致性往上走你会碰到 RTOS 内核实现、Linux 内存子系统、性能调优。如果你想把这块吃透我的建议是先在一个具体的 MCU 上把裸机内存布局摸清楚看 map 文件改链接脚本测栈深度。然后上 FreeRTOS把五种 heap 实现都跑一遍看碎片怎么产生。最后上嵌入式 Linux用 valgrind 抓一次泄漏用 smem 看一次 PSS。这三步走完你对内存的理解就不是纸上谈兵了。后面再遇到内存问题你会有直觉——知道去哪看知道怎么查知道怎么修。这种直觉才是嵌入式工程师真正的护城河。
1. 为什么嵌入式内存管理值得单独开一堂课做嵌入式开发这些年被问得最多的问题里“内存怎么又不够了”绝对排得进前三。MCU 上跑裸机程序RAM 就几十 KB堆栈稍微一抖就 HardFault上了 RTOS任务栈、消息队列、动态内存池层层叠加一个没算准跑几个小时就死机。更别提嵌入式 Linux 那边用户态一个 malloc 没配对 free进程的 RSS 一路涨到 OOM Killer 出手。这堂课我想把嵌入式内存这件事从头到尾捋一遍。不是那种“malloc 申请、free 释放”的教科书式讲法而是从实际项目里踩过的坑出发把裸机、RTOS、嵌入式 Linux 三个层面的内存管理串起来讲。你会看到堆和栈到底怎么划分、malloc 在 RTOS 里为什么经常被禁用、内存碎片是怎么把系统搞死的、以及怎么用工具把内存泄漏揪出来。适合谁看刚入行做嵌入式、被内存问题折磨过的朋友从裸机转 RTOS、发现 malloc 不好使的兄弟还有做嵌入式 Linux 应用、想搞清楚进程内存模型的开发者。不管你现在在哪一层这篇内容都能给你一套可落地的方法。2. 嵌入式内存的整体版图与设计取舍2.1 裸机、RTOS、Linux 三层内存模型对比先把三层的内存版图摆清楚不然后面聊 malloc 和 free 容易混。裸机程序的内存布局非常朴素Flash 里放代码和常量RAM 里分三块——全局/静态区、堆区、栈区。栈从 RAM 高地址往下长堆从低地址往上长中间留一段空隙。栈主要给函数调用、局部变量、中断现场用堆就是 malloc 的地盘。很多小型 MCU 项目干脆不用堆所有变量都静态分配图的就是确定性。RTOS 上来之后情况复杂了。每个任务有自己的栈任务栈大小在创建时就得定死。RTOS 内核本身还需要一块系统堆来分配任务控制块、队列、信号量这些对象。这时候 malloc 就有两种来源一种是编译器自带的 C 库堆一种是 RTOS 提供的专用内存池。这两者混用是很多 bug 的根源。嵌入式 Linux 则是另一套玩法。每个进程有独立的虚拟地址空间分为代码段、数据段、BSS 段、堆、栈、mmap 区。malloc 在用户态申请内存背后可能是 brk 扩展堆顶也可能是 mmap 映射一块新区域。物理内存由内核的伙伴系统和 slab 分配器管理用户态看到的都是虚拟地址。层级内存管理方式典型堆大小主要风险裸机静态分配为主少量 malloc几 KB 到几十 KB栈溢出、堆碎片RTOS任务栈 系统堆 内存池几十 KB 到几百 KB任务栈溢出、堆碎片、优先级反转嵌入式 Linux虚拟内存 伙伴系统 slab几 MB 到几百 MB内存泄漏、OOM、碎片这张表不是让你背的是让你在选方案时有个参照。我见过太多人拿 Linux 那套思维去做 RTOS 项目上来就 malloc 一把梭结果跑两天就崩。2.2 静态分配与动态分配的取舍逻辑嵌入式圈有句老话能静态就别动态。这话不是保守是血泪教训。静态分配的好处是确定性。编译期就知道内存用多少链接脚本一配map 文件一看心里有底。缺点是灵活性差比如你要支持不同数量的设备连接静态数组就得按最大值开浪费。动态分配的好处是灵活按需申请。但代价是碎片、不确定性、失败路径难处理。malloc 返回 NULL 的时候你怎么办很多代码直接不处理然后解引用空指针崩。我的经验是分场景生命周期贯穿整个程序的资源静态分配。比如系统配置、全局缓冲区。生命周期明确、大小固定的资源用内存池。比如网络包缓冲、任务间消息。生命周期短、大小不定的才考虑 malloc而且要配一套失败处理逻辑。这个取舍逻辑贯穿后面所有内容。你看到任何一个内存方案先问自己这个资源的生命周期是多长大小是否可预测失败了我能不能兜住2.3 内存碎片嵌入式系统最隐蔽的杀手碎片这东西平时不显山不露水等到系统跑了一周突然分配失败你才发现堆已经千疮百孔。碎片分两种。外部碎片是空闲内存总量够但不连续凑不出一块大的。内部碎片是分配出去的块比实际需要的大多出来的部分浪费了。举个例子。堆有 10KB你依次申请 1KB、2KB、3KB、4KB然后释放 1KB 和 3KB。现在空闲总量是 4KB但分成两块 1KB 和 3KB不连续。这时候你要申请 4KB直接失败。这就是外部碎片。嵌入式系统里碎片特别容易积累因为内存小、分配频繁、块大小多变。RTOS 里如果用 C 库的 malloc碎片问题几乎无解。所以 FreeRTOS 才提供了 heap_1 到 heap_5 五种堆实现其中 heap_4 带合并相邻空闲块的功能heap_5 还支持多块不连续内存区域。注意heap_4 的合并只能合并物理相邻的空闲块如果你的分配模式是“大块和小块交替申请释放”碎片照样会产生。真正抗碎片的是固定大小内存池。3. malloc 与 free 在嵌入式里的真实面目3.1 malloc 到底做了什么从 brk 到内存池很多人以为 malloc 就是“向系统要内存”其实在嵌入式里malloc 的行为取决于你用的是哪套实现。在裸机和 RTOS 上malloc 通常是 C 库自带的实现它管理一块叫 heap 的连续内存区域。这块区域的起点和大小由链接脚本决定比如 STM32 的启动文件里_heap_start和_heap_end就定义了堆的范围。malloc 在这块区域里维护一个空闲链表每次分配就找一块够大的空闲块切一块出来剩下的还回去。在嵌入式 Linux 上malloc 是 glibc 或 musl 的实现。小块内存从堆顶通过 brk 扩展大块内存默认超过 128KB用 mmap 单独映射。glibc 的 malloc 还有 per-thread arena 的概念多线程环境下每个线程有自己的分配区减少锁竞争。关键点在于嵌入式里的 malloc 不是无限的。堆就那么大用完了就返回 NULL。而且很多 RTOS 的 malloc 不是线程安全的多任务同时调用会出问题。FreeRTOS 就明确建议用 pvPortMalloc 而不是 malloc因为前者带临界区保护。3.2 free 之后内存去哪了释放不等于归还这是新手最容易误解的地方。free 之后内存不一定还给系统大多数情况下只是标记为空闲还给堆管理器。在裸机和 RTOS 上free 把块放回空闲链表可能和相邻空闲块合并。但物理内存还是那块不会“消失”。所以你看 map 文件堆的大小始终不变变的是空闲链表的分布。在 Linux 上free 之后 glibc 可能把内存还给内核通过 brk 收缩或 munmap也可能留在 arena 里备用。这就是为什么你看进程的 RSSfree 之后不一定马上降。很多嵌入式 Linux 开发者看到 RSS 不降就以为泄漏了其实只是 glibc 没还。提示判断是否真泄漏不能只看 RSS。用 valgrind 或 AddressSanitizer 跑一遍看有没有“definitely lost”的块那才是真泄漏。3.3 为什么 RTOS 里经常禁用 mallocFreeRTOS 官方文档里有一句话在实时系统里malloc 和 free 通常是不推荐的。原因有三。第一不确定性。malloc 的执行时间取决于空闲链表的长度和碎片程度最坏情况可能遍历整个链表。实时系统要求确定性这个不可接受。第二碎片。前面讲过了频繁分配释放必然产生碎片最终导致分配失败。第三线程安全。C 库的 malloc 不一定线程安全多任务环境下需要加锁加锁又引入优先级反转风险。所以 FreeRTOS 提供了五种堆实现heap_1只分配不释放最简单适合任务创建后不再动态分配的系统。heap_2可释放但不合并适合分配大小固定的场景。heap_3包装 C 库的 malloc/free加了线程安全。heap_4可释放且合并相邻空闲块最常用。heap_5在 heap_4 基础上支持多块不连续内存区域。选哪个我的建议是如果任务和队列都在启动时创建好用 heap_1零碎片风险。如果需要运行中动态创建删除用 heap_4。如果内存分布在多个不连续的 RAM 区比如内部 SRAM 外部 SDRAM用 heap_5。3.4 内存池比 malloc 更靠谱的选择内存池的思路很简单预先分配一大块内存切成固定大小的块用一个空闲链表管理。申请时从链表取一块释放时还回去。没有碎片因为所有块大小一样时间确定因为就是链表操作。在 RTOS 里消息队列、信号量这些对象通常就是用内存池管理的。你自己写应用时也可以为频繁分配释放的对象建内存池。比如网络协议栈的包缓冲每个包固定 1500 字节建一个 32 块的池子比 malloc 靠谱得多。内存池的缺点是灵活性差。块大小固定申请不同大小的对象就得建多个池子。而且池子空了怎么办要么阻塞等待要么返回失败。这需要你在设计阶段就想清楚。我做过一个项目用内存池管理 Modbus 帧缓冲池子大小 16 块每块 256 字节。跑了一年多零碎片、零分配失败。换成 malloc 的话估计撑不过一个月。4. 实操从裸机到 RTOS 的内存管理落地4.1 裸机项目链接脚本与栈堆划分裸机项目的第一步是看链接脚本。以 GCC 为例.ld文件里定义了 MEMORY 区域和 SECTION 布局。MEMORY { FLASH (rx) : ORIGIN 0x08000000, LENGTH 512K RAM (rwx) : ORIGIN 0x20000000, LENGTH 128K } _estack ORIGIN(RAM) LENGTH(RAM);栈顶_estack设在 RAM 最高地址栈向下生长。堆的起点通常在 BSS 段之后终点是栈底减去一个安全余量。_heap_start _end; _heap_end _estack - 0x400;这个0x400是留给栈的安全余量。怎么定看你的中断嵌套深度和局部变量大小。我一般留 1KB如果用了浮点运算或递归留 2KB。栈大小怎么估算最笨也最有效的办法在栈区域填充特定模式比如 0xDEADBEEF跑一遍所有功能然后看有多少模式被改写了。改写的深度就是栈的最大使用量再乘个 1.5 倍安全系数。注意中断服务函数用的栈可能是主栈也可能是独立的中断栈取决于 MCU 架构。Cortex-M 默认用主栈所以中断嵌套会加深栈使用。别只测主循环要带着中断一起测。4.2 FreeRTOS 任务栈大小怎么算才不翻车FreeRTOS 创建任务时usStackDepth参数的单位是字不是字节。Cortex-M 上一个字 4 字节所以usStackDepth 128实际是 512 字节。这个坑我见过太多人踩。栈大小怎么定FreeRTOS 提供了两个工具。一是uxTaskGetStackHighWaterMark()返回任务运行过程中栈剩余的最小值。二是configCHECK_FOR_STACK_OVERFLOW设为 2 时会在任务切换时检查栈是否溢出溢出就调用vApplicationStackOverflowHook。我的做法是先给一个偏大的值比如 512 字跑完所有功能看 high water mark。如果剩余很多逐步减小如果剩余很少加大。最终值留 30% 余量。void vTaskFunction(void *pvParameters) { for (;;) { // 任务逻辑 UBaseType_t watermark uxTaskGetStackHighWaterMark(NULL); printf(Stack watermark: %u\n, watermark); vTaskDelay(pdMS_TO_TICKS(1000)); } }这个 watermark 是“历史最小剩余”单位是字。如果它接近 0说明栈快满了赶紧加。还有一个坑在任务里调用 printf 或 sprintf这些函数可能占用大量栈空间。我见过一个任务栈设了 256 字加了 printf 之后直接溢出。解决办法是用vsnprintf到固定缓冲或者把日志任务单独拆出来。4.3 用 heap_4 还是 heap_5多块 RAM 区的处理有些 MCU 有多个不连续的 RAM 区比如 STM32H7 有 DTCM、AXI SRAM、SRAM1-4。默认的 heap 只能覆盖一个连续区域。这时候用 heap_5。heap_5 的用法是定义HeapRegion_t数组然后调用vPortDefineHeapRegions。const HeapRegion_t xHeapRegions[] { { (uint8_t *)0x20000000, 0x10000 }, // 64KB { (uint8_t *)0x24000000, 0x20000 }, // 128KB { NULL, 0 } }; vPortDefineHeapRegions(xHeapRegions);注意这个函数必须在创建任何 RTOS 对象之前调用而且只能调一次。调用之后pvPortMalloc 就会在这两块区域里分配。heap_5 的分配策略是首次适应从第一个区域开始找。如果第一个区域碎片化了即使第二个区域有大块空闲也可能分配失败。所以我的建议是把频繁分配的小对象放在一个区域大块内存放在另一个区域减少交叉。4.4 内存泄漏排查从 map 文件到运行时监控嵌入式里的内存泄漏排查比 Linux 难因为没有 valgrind。但有几招管用。第一招看 map 文件。编译后生成的.map文件里有每个符号的地址和大小。如果某个全局数组异常大或者堆的起点终点不对一眼就能看出来。第二招运行时监控。在 pvPortMalloc 和 vPortFree 里加钩子记录当前空闲堆大小。FreeRTOS 提供了xPortGetFreeHeapSize()和xPortGetMinimumEverFreeHeapSize()。前者返回当前空闲后者返回历史最小空闲。如果当前空闲持续下降基本就是泄漏。void vMonitorTask(void *pvParameters) { for (;;) { size_t free_heap xPortGetFreeHeapSize(); size_t min_heap xPortGetMinimumEverFreeHeapSize(); printf(Free: %u, Min: %u\n, free_heap, min_heap); vTaskDelay(pdMS_TO_TICKS(5000)); } }第三招包装 malloc/free。自己写一层my_malloc和my_free在块头加一个魔数和大小释放时检查魔数。这样能抓到重复释放和越界写。typedef struct { uint32_t magic; size_t size; } mem_header_t; void *my_malloc(size_t size) { mem_header_t *h pvPortMalloc(size sizeof(mem_header_t)); if (!h) return NULL; h-magic 0xDEADBEEF; h-size size; return (void *)(h 1); } void my_free(void *ptr) { if (!ptr) return; mem_header_t *h (mem_header_t *)ptr - 1; if (h-magic ! 0xDEADBEEF) { printf(Memory corruption detected!\n); return; } h-magic 0; vPortFree(h); }这套包装会增加一点开销但在调试阶段非常值。5. 嵌入式 Linux 侧的内存管理要点5.1 进程内存模型与 malloc 的底层行为嵌入式 Linux 上跑应用内存模型和桌面 Linux 一样但资源更紧张。每个进程有 4GB 虚拟地址空间32 位其中用户态占 3GB内核态占 1GB。实际物理内存可能只有 128MB 或 256MB。malloc 在 glibc 里的行为小于 128KB 的分配走 brk从堆顶扩展大于等于 128KB 的走 mmap单独映射一块。这个阈值可以通过M_MMAP_THRESHOLD调整。为什么关心这个因为 brk 扩展的内存free 之后不一定还给内核可能留在进程的堆里。而 mmap 的内存free 之后直接 munmap 还给内核。所以如果你频繁申请释放大块内存RSS 会上下波动如果是小块RSS 可能只涨不降。在嵌入式设备上我通常会把M_MMAP_THRESHOLD调小比如 64KB让更多分配走 mmap这样释放后能真正还给系统。设置方法是在程序启动时调用mallopt(M_MMAP_THRESHOLD, 64*1024)。5.2 内存泄漏检测valgrind 与 AddressSanitizer嵌入式 Linux 上跑 valgrind 比较重但如果是 Cortex-A 级别的芯片跑得动。用法很简单valgrind --leak-checkfull --show-leak-kindsall ./my_app输出会告诉你哪些块“definitely lost”、“indirectly lost”、“possibly lost”。definitely lost 就是真泄漏必须修。如果 valgrind 太重用 AddressSanitizer。编译时加-fsanitizeaddress -g运行时会检测越界、释放后使用、泄漏。ASan 的性能开销比 valgrind 小适合在设备上跑。gcc -fsanitizeaddress -g -o my_app my_app.c ./my_appASan 会在程序退出时打印泄漏报告。注意 ASan 需要链接 libasan嵌入式根文件系统里要带上。还有一个轻量方案mtrace。glibc 自带通过MALLOC_TRACE环境变量指定日志文件然后在代码里调用mtrace()开始记录muntrace()结束。用mtrace命令分析日志。这个方案开销极小适合资源紧张的设备。5.3 OOM Killer 与内存水位调优嵌入式 Linux 上内存耗尽时内核的 OOM Killer 会挑一个进程杀掉。挑谁看oom_score分数高的先杀。分数和进程的内存占用、运行时间、优先级有关。你可以通过/proc/pid/oom_score_adj调整分数范围 -1000 到 1000。-1000 表示永不被杀。关键进程可以设成 -1000防止被误杀。echo -1000 /proc/$(pidof my_critical_app)/oom_score_adj但更好的做法是预防 OOM。几个手段限制进程内存用 cgroup 的 memory 子系统给每个进程设上限。监控内存水位读/proc/meminfo的MemAvailable低于阈值就告警或重启服务。用 zram 或 zswap压缩内存相当于变相扩容。嵌入式设备上 zram 很实用配置得当能省 30% 到 50% 内存。注意zram 用的是 CPU 换内存如果 CPU 本来就吃紧开了反而更卡。先测 CPU 负载再决定。5.4 嵌入式 Qt 应用的内存优化实践嵌入式 Qt 应用内存占用大是出了名的。一个简单的界面跑起来 RSS 可能就 50MB 起。优化手段有几个。第一用 QWidget 而不是 QML。QML 的 JavaScript 引擎和场景图开销大QWidget 轻量得多。如果非要用 QML用 Qt Quick Ultralite 或 Qt for MCU。第二裁剪 Qt 模块。编译 Qt 时只选需要的模块去掉 WebEngine、Multimedia 这些大块头。用-skip参数跳过不需要的模块。第三图片资源用 QResource 编译进二进制避免运行时加载。大图用 JPEG 而不是 PNG解码后及时释放。第四字体裁剪。嵌入式设备不需要完整字体库用fontconfig或Qt的字体子集工具只保留用到的字符。第五监控 QWidget 的创建销毁。Qt 的对象树机制下父对象销毁会连带销毁子对象。但如果你手动 new 了一个没有父对象的 widget忘了 delete就泄漏了。用QScopedPointer或QSharedPointer管理生命周期。我做过一个 800x480 的工业 HMI用 QWidget裁剪后 Qt 库 8MB应用 RSS 稳定在 25MB 左右。同样的界面用 QMLRSS 直接 60MB 起。6. 常见问题与排查技巧实录6.1 内存问题速查表现象可能原因排查手段解决方向HardFaultPC 指向异常地址栈溢出、空指针解引用看 LR 和 PC查 map 文件加大栈、检查 malloc 返回值跑一段时间后 malloc 返回 NULL内存泄漏、碎片监控空闲堆大小修泄漏、换内存池任务切换时死机任务栈溢出开 configCHECK_FOR_STACK_OVERFLOW加大任务栈Linux 进程 RSS 持续上涨内存泄漏valgrind、ASan修泄漏、调 mmap 阈值系统突然变慢OOM Killer 杀进程内存耗尽看 dmesg、/proc/meminfo限制进程内存、开 zramfree 之后 RSS 不降glibc 未归还内存看 malloc_trim调 M_MMAP_THRESHOLD、手动 trim这张表建议打印出来贴工位上。遇到问题先对号入座能省不少时间。6.2 那些年我踩过的内存坑坑一在中断里调用 malloc。C 库的 malloc 不是中断安全的在 ISR 里调用可能死锁或破坏堆。FreeRTOS 的 pvPortMalloc 如果在中断里调用必须用pvPortMalloc的 FromISR 版本但 heap_4 本身不带 FromISR 接口。正确做法是在中断里发信号给任务由任务去分配。坑二任务栈单位搞错。FreeRTOS 的usStackDepth是字不是字节。我见过有人写xTaskCreate(task, t, 512, ...)以为是 512 字节实际是 2048 字节。反过来也有人写 128 以为是 128 字节实际 512 字节结果栈不够。坑三字符串常量放 RAM。const char *str hello;这个字符串在 Flash 里不占 RAM。但char str[] hello;是数组在 RAM 里。大量字符串用数组形式RAM 很快就不够了。用const加指针或者用PROGMEM之类的宏。坑四递归函数在嵌入式里失控。递归深度不可预测栈很快爆。嵌入式里尽量用迭代代替递归。如果非要用限制深度并监控栈水位。坑五结构体对齐浪费内存。struct { char a; int b; char c; }在 32 位系统上占 12 字节不是 6 字节。调整成员顺序把大的放前面能省不少。用__attribute__((packed))可以取消对齐但访问速度会降而且某些架构不支持非对齐访问。6.3 内存调试工具链推荐裸机和 RTOS 侧SEGGER RTT实时传输调试信息不占串口速度快。SystemView可视化任务切换和中断间接看栈使用。FreeRTOSTraceFreeRTOS 自带的分析工具看堆使用曲线。嵌入式 Linux 侧valgrind重量级但全面。AddressSanitizer轻量级适合设备上跑。mtraceglibc 自带开销最小。perf看内存相关的性能事件。smem看进程的 PSS 和 USS比 RSS 准确。我一般组合使用开发阶段用 ASan 快速定位集成测试用 valgrind 全面扫描上线后用 smem 和自定义监控长期观察。6.4 内存优化的几个实用技巧技巧一用位域压缩标志位。一个uint8_t存 8 个布尔标志比 8 个bool省 7 字节。大量标志位场景下很可观。技巧二用联合体共享内存。互斥的变量放联合体里同一时间只用一个。比如通信协议的不同帧类型用联合体解析省一块缓冲。技巧三缓冲区复用。不要每个模块都开自己的缓冲搞一个全局缓冲池按需借用。网络协议栈、文件系统、UI 渲染可以共用。技巧四延迟分配。不是所有内存都要在初始化时申请。用到再申请用完就释放。但要注意失败路径。技巧五用内存映射文件代替读文件到内存。大文件处理时mmap 比 read 到缓冲更省内存因为内核按页加载不用一次性全读进来。这些技巧单个看省得不多但组合起来一个项目省 20% 到 30% RAM 是常事。嵌入式里省下来的内存就是竞争力。7. 从内存课延伸出去的学习路径内存管理只是嵌入式系统的一个切面但它串起了很多知识点。往下挖你会碰到链接脚本、启动流程、MMU、cache 一致性往上走你会碰到 RTOS 内核实现、Linux 内存子系统、性能调优。如果你想把这块吃透我的建议是先在一个具体的 MCU 上把裸机内存布局摸清楚看 map 文件改链接脚本测栈深度。然后上 FreeRTOS把五种 heap 实现都跑一遍看碎片怎么产生。最后上嵌入式 Linux用 valgrind 抓一次泄漏用 smem 看一次 PSS。这三步走完你对内存的理解就不是纸上谈兵了。后面再遇到内存问题你会有直觉——知道去哪看知道怎么查知道怎么修。这种直觉才是嵌入式工程师真正的护城河。
