嵌入式内存管理实战：从裸机、RTOS到Linux的内存分配与泄漏排查

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 分配器管理，用户态看到的都是虚拟地址。

这张表不是让你背的，是让你在选方案时有个参照。我见过太多人拿 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 里备用。这就是为什么你看进程的 RSS，free 之后不一定马上降。很多嵌入式 Linux 开发者看到 RSS 不降就以为泄漏了，其实只是 glibc 没还。

提示：判断是否真泄漏，不能只看 RSS。用 valgrind 或 AddressSanitizer 跑一遍，看有没有“definitely lost”的块，那才是真泄漏。

3.3 为什么 RTOS 里经常禁用 malloc

FreeRTOS 官方文档里有一句话：在实时系统里，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-check=full --show-leak-kinds=all ./my_app

输出会告诉你哪些块“definitely lost”、“indirectly lost”、“possibly lost”。definitely lost 就是真泄漏，必须修。

如果 valgrind 太重，用 AddressSanitizer。编译时加-fsanitize=address -g，运行时会检测越界、释放后使用、泄漏。ASan 的性能开销比 valgrind 小，适合在设备上跑。

gcc -fsanitize=address -g -o my_app my_app.c ./my_app

ASan 会在程序退出时打印泄漏报告。注意 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 左右。同样的界面用 QML，RSS 直接 60MB 起。

6. 常见问题与排查技巧实录

6.1 内存问题速查表

这张表建议打印出来贴工位上。遇到问题先对号入座，能省不少时间。

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：可视化任务切换和中断，间接看栈使用。
• FreeRTOS+Trace：FreeRTOS 自带的分析工具，看堆使用曲线。

嵌入式 Linux 侧：

• valgrind：重量级但全面。
• AddressSanitizer：轻量级，适合设备上跑。
• mtrace：glibc 自带，开销最小。
• 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。

这三步走完，你对内存的理解就不是纸上谈兵了。后面再遇到内存问题，你会有直觉——知道去哪看，知道怎么查，知道怎么修。这种直觉，才是嵌入式工程师真正的护城河。