做了好几年嵌入式开发我最大的体会之一就是C这门语言在PC上怎么写都不容易出事但一到嵌入式环境内存管理瞬间就变成了一个绕不开的“生死题”。MCU的RAM可能只有几十KBLinux板卡的物理内存也远不如桌面系统宽裕而实时任务又不允许你在某次malloc上耗掉几百上千个CPU周期。偏偏热门的工具链、面试题、项目架构又几乎都围着“嵌入式C内存管理”在转可以说这个方向决定了你的程序是稳定跑几个月还是隔三差五掉进HardFault。我想把这几年在嵌入式C内存管理上踩过的坑、用过的方案以及面试和团队协作中反复遇到的问题一次性整理出来。这篇东西不会只给你堆概念而是从分配策略、内存池实现、调试方法到RTOS堆选择都给出可以直接上手的思路和代码。无论你是刚接触嵌入式Linux的小白还是在裸机环境下被new/delete坑过的老手应该都能找到对自己有用的那部分。1. 嵌入式C内存管理先搞懂这些“为什么”1.1 默认的new/delete为什么在嵌入式环境里那么不可靠不少从桌面开发转过来的程序员进嵌入式项目后第一件事就是把PC上那套“随手new、到处shared_ptr”的习惯带过来结果往往死得很难看。本质原因是默认的new/delete底层通常就是malloc/free而通用堆分配器的设计目标是“在足够大的内存池里兼顾速度与利用率”它压根不考虑实时性。以常见的glibc malloc为例它会维护多个空闲链表和bins分配时会根据请求大小查找合适的空闲块可能还会调用brk扩展堆、用mmap映射新页。这一套在PC上有虚拟内存托底CPU又足够快表现良好。可在嵌入式MCU上你面对的是固定地址的SRAM没有分页交换堆段就那么大每次malloc都需要遍历空闲链表、切分块、维护元信息。随着分配/释放次数增多链表的长度和分布越来越乱分配耗时也随之波动。更麻烦的是嵌入式项目里经常有中断上下文或实时任务在跑malloc不是非阻塞安全的一旦在ISR里调用可能直接触发调度器临界区冲突看门狗当场复位那个画面我见过不止一次。C标准库更是叠了一层抽象new除了分配内存还要构造对象构造函数抛异常时还得善后数组要带元素计数虚继承还有额外的偏移调整。这些在裸机环境下都会变成实实在在的隐性开销和代码体积。不是说不能用而是你得清楚每一层在哪花钱、花多少、有没有确定性。1.2 碎片化和“确定性”到底在说什么很多嵌入式C的文章都会强调“确定性”这个词对实时系统太关键了。你可以把内存分成一个个固定大小的房间malloc要做的就是找一个足够大的连续房间给客人住。一开始房间很整齐随便挑就有运行一段时间后客人陆续退房房间变成交错的空闲小块。虽然剩余总面积可能还剩60%但最大的连续空闲块可能只有不到原先的10%。这就是外部碎片也是嵌入式系统内存管理最恶心的敌人。内部碎片则是另一个概念比如你要分配13字节但分配器可能按16字节的最小粒度给你这3字节就白白浪费了。PC上内存几百GB碎片问题顶多让进程多占些页可嵌入式RAM总共也就几十到几百KB碎片化到一定程度后malloc会反复返回nullptr程序的表现通常是莫名卡死或HardFault。解决方案说起来很简单要么让对象的生命周期和大小都是编译期可知的要么在分配策略上把空间提前切成固定槽位从规则上杜绝“越用越碎”。这也是为什么嵌入式C内存管理会反复提到静态分配、内存池、环形缓冲区这些方案——它们不是C的套路而是嵌入侵入式环境下对内存本质规律的妥协与利用。1.3 先分清楚对象的一生静态、栈、堆深入方案前我先强调一个基础认知任何内存管理策略本质上都是在回答一个问题——“这个对象什么时候创建什么时候销毁生命周期是否跨越函数调用”。静态存储区的对象在程序启动前就有了地址生命周期最长零分配开销栈对象在进入作用域时分配、离开作用域时自动销毁地址连续也没有碎片只有堆对象是真正“自由”的可以跨函数、跨线程存活但代价就是那套复杂的分配/释放协议。嵌入式中最常见的错误就是把本应静态或栈分配的对象硬塞到堆里。一个协议报文缓存、一个DMA缓冲区、一个RTOS任务控制块这些生命周期清晰、上限固定的对象拿去new干什么写个静态数组或者固定内存池不是更稳吗2. 五大内存分配策略各自适用什么场景2.1 静态分配嵌入式C的定海神针静态分配的意思是在编译期就把内存位置和大小固定下来。裸机上最常见的写法是全局数组或者在链接脚本里单独划一块区域用GCC的section属性放进去。#define SDRAM_POOL_SIZE (4 * 1024 * 1024) uint8_t sdram_pool[SDRAM_POOL_SIZE] __attribute__((section(.sdram_pool), aligned(64)));这段代码把我的4MB SDRAM区域留给了全局数组链接脚本里section .sdram_pool会被安排到外部SDRAM起始地址。程序里任何模块都能引用sdram_pool配合placement new就能在固定地址上构造对象。静态分配的好处是零malloc开销、没有碎片、出错概率极低唯一的坏处是空间一旦用满就没法悄悄扩容所以你得对业务的数据上限有清醒的认知。我用静态分配最多的场景是通信协议栈的帧缓冲、日志环形队列的底层数组、传感器校准数据缓存以及需要长期保存的配置结构体。它们生命周期贯穿整个系统要求快速、稳定又不会频繁动态增长静态数组天然合适。2.2 栈分配自动回收但容量要看好栈上的对象是“函数级生命周期的天然免费内存管理器”。局部变量、函数参数、返回地址都在栈上分配一个对象就是移动一下栈指针耗时固定还不产生堆碎片。对于状态机里的临时变量、函数间的中转对象能放栈上就别碰堆。但嵌入式里栈空间非常有限。Cortex-M的裸机工程启动文件里通常配置了2KB到8KB的栈RTOS下每个任务的栈也是圈定的固定内存。如果你在某个处理函数里放了一个uint8_t buf[4096]而栈总共才4KB那这个函数一被调用就直接把栈干穿了。这类问题非常隐蔽因为编译不会报错运行时可能几十次都没事直到某次函数调用深度稍大栈顶覆盖了全局变量系统就会以玄学方式随机崩溃。我给个实际建议超过256字节的局部缓冲区尽量改成静态数组或者堆池分配在开发阶段给任务栈和主栈都塞入特定填充字节周期性检查栈水位线确认最大深度后再压缩栈大小。2.3 内存池把堆的混乱变成槽位的秩序内存池也叫对象池是嵌入式C内存管理的核心招式。核心思路是在初始化时一次性从静态区或堆里划出一大块连续内存按固定大小切成若干槽位每个槽位要么空闲要么被占用。分配时从空闲链表中摘一个槽位释放时再塞回去。这个方法的好处非常明显分配和释放的时间是O(1)的不依赖当前内存碎片状态因为槽位大小统一外部碎片彻底消失还能在编译期限制最大并发对象数超出就返回nullptr或触发断言让问题在开发阶段暴露而不是在产品运行阶段发生。代价是灵活性差每个池只能服务一种固定大小或者一堆相近大小的对象你需要按对象类型分别建池。很多嵌入式团队会把网络帧、消息节点、任务句柄统统池化。我之前做过一个Modbus网关所有在线连接上下文都是从一个容量为64的连接池里取的连续运行几个月都没出现过一次堆分配失败。裸机项目里我甚至会把所有new都干掉全部走池或placement new代码的运行轨迹会变得更可预测。2.4 环形缓冲区流式数据的无碎片方案环形缓冲区处理的是“写入→消费→覆盖”这种流式数据比如串口接收、日志输出、DMA采集。它不关心单个对象的生命周期只关心读写指针在内存首尾之间循环移动。因为内存区域本身就是预先一次性分配好的不存在分配和释放所以也谈不上碎片。实现环形缓冲区时有个容易被忽略的坑读写指针在多任务或中断和主循环之间有并发访问时必须保证指针操作的原子性或者用关中断、临界区来保护。否则会出现“生产者已经更新写指针消费者读到半新半旧状态”的脏数据这种Bug极其难查。更稳的做法是在Cortex-M上用单生产者单消费者模型借助内存屏障和原子变量实现无锁但前提是读者和写者都不能超前消费。2.5 通用堆妥协但并非不可用讨论了一圈不是说嵌入式里绝对不能用通用堆而是要把通用堆放到合适的位置。如果项目是嵌入式Linux系统本身有MMU和glibc内存足够大、碎片有OS回收机制那么new/delete完全可以直接用只要注意分配频率不要高到影响实时性即可。如果是RTOS或裸机可以用RTOS自带的堆管理组件或者自己集成一个设计良好的嵌入式分配器。比如FreeRTOS的heap_4会合并相邻空闲块已经可以抵抗大部分碎片问题TLSFTwo-Level Segregate Fit分配器则以确定性的分配时间著称适合需要实时保证的场景。选择通用堆时一定要想清楚谁会调用、调用多频繁、是否在中断上下文、失败时怎么兜底。这些问题比堆算法本身更重要。3. 手写一个能上生产的内存池分配器3.1 选型与设计原则讲完了策略我来手把手拆一个我实际用过的内存池实现。先定几条设计原则池内存用静态数组预留编译期确定槽位大小采用模板参数让编译器生成专门代码支持C对象构造与析构但底层只管理原始字节在多线程环境中用简单的关调度或无锁操作保证安全。对象个数的上限要在系统设计阶段定死。比如“最多并发80条命令”、 “最多缓存64个传感器帧”这个数字来自需求和数据流分析不是拍脑袋。多定几个槽位浪费不了多少RAM但定少了会在高峰期分配失败所以我会在测试阶段故意构造最坏消息到达率来验证。槽位大小也要仔细算。除了对象本身sizeof还必须考虑对齐padding。每条消息若定义为一个结构体内部有uint64_t成员那它天然需要8字节对齐。如果池子分配到的基地址没对齐第一个槽位的地址偏移会导致结构体成员访问异常在ARM上就是总线错误或HardFault所以池子数组要用alignas(std::max_align_t)修饰。3.2 基础版内存池源码与解析下面这个实现比较精简适用于裸机和大多数RTOS没有依赖外部malloc完全静态#include cstdint #include cstddef #include new templatetypename T, size_t N class MemoryPool { public: struct Slot { alignas(T) unsigned char data[sizeof(T)]; // 槽位内存按T对齐 Slot* next; // 空闲链表指针 }; MemoryPool() noexcept { free_head_ nullptr; for (size_t i 0; i N; i) { pool_[i].next free_head_; free_head_ pool_[i]; } used_count_ 0; } templatetypename... Args T* construct(Args... args) { Slot* slot pop_free(); if (slot nullptr) { return nullptr; } // 在槽位原址内存上构造对象避免额外的内存分配 T* obj new (slot-data) T(std::forwardArgs(args)...); return obj; } void destroy(T* obj) noexcept { if (obj nullptr) return; obj-~T(); Slot* slot reinterpret_castSlot*(obj); slot-next free_head_; free_head_ slot; used_count_--; } size_t free_count() const noexcept { return N - used_count_; } private: Slot* pop_free() noexcept { Slot* s free_head_; if (s nullptr) return nullptr; free_head_ s-next; used_count_; return s; } Slot pool_[N]; Slot* free_head_; size_t used_count_; };注意Slot里的alignas(T)是C11以上才有的对齐控制语法C语言里会写成__attribute__((aligned(...)))功能类似。初始化时把每个槽位串成单向空闲链表这步操作让后续分配只需要取出头节点理论耗时O(1)。construct成员模板函数是核心入口。我用new (slot-data) T(...)也就是placement new在预先取出的slot字节上构造对象而不是先在堆上分配一块内存再复制。这样做的好处很直接内存来源完全可控构造失败也不会留下内存泄漏。断言、日志这类信息如果需要在分配时打印可以放在pop_free返回nullptr分支里但切记不要在ISR里用printf否则大概率又引入新的优先级反转问题。这里还有一个容易忽略的细节destroy时我把slot从地址倒推回来。因为对象就构建在slot的data成员起始处reinterpret_castSlot*(obj)就等于拿到了这个slot本身。所有数据都在固定池里不会越界。为了防御指针来自外部而非本池最稳的做法是在槽位里增加一个魔术编号构造时写入magic销毁时校验magic校验不对就断言并拒绝归还。这个我后面在踩坑章节再展开。3.3 进阶让内存池适配STL容器嵌入式项目有时也需要C标准容器但默认的vector、list内部都会用std::allocator调用new没办法直接对上内存池。好在C标准为这类场景预留了自定义Allocator机制。给vector指定一个从MemoryPool取内存的分配器就能让容器在固定槽位里增长和缩容同时不碰全局堆。下面是一个适配MemoryPool的自定义分配器骨架templatetypename T class PoolAllocator { public: using value_type T; PoolAllocator(size_t pool_id 0) noexcept : pool_id_(pool_id) {} templatetypename U PoolAllocator(const PoolAllocatorU other) noexcept : pool_id_(other.pool_id_) {} T* allocate(size_t n) { // 从指定的池子分配这里假设全局有一个PoolRegistry持有多个池实例 if (n 1) { return static_castT*(::malloc(n * sizeof(T))); } return reinterpret_castT*(PoolRegistry::instance().allocate(pool_id_, sizeof(T))); } void deallocate(T* p, size_t n) noexcept { if (n 1) { ::free(p); return; } PoolRegistry::instance().deallocate(pool_id_, p); } templatetypename U struct rebind { using other PoolAllocatorU; }; bool operator(const PoolAllocator other) const { return pool_id_ other.pool_id_; } bool operator!(const PoolAllocator other) const { return !(*this other); } private: size_t pool_id_; };这段代码有几个重点要说明。allocate的n参数表示要分配n个T对象STL容器可能一次性申请多个元素的内存比如vector扩容时经常allocate(2 * size)。这种情况如果一个槽位不够用我图省事直接回退到malloc。实际生产环境我更建议把池子做成支持“多槽连续分配”的BlockPool或者干脆不用vector而用固定容量数组封装说明白量级后容器扩不扩展完全可控。rebind是STL分配器的一个重要细节。map节点类型不是pair而是内部节点结构体编译器会通过rebind把你的分配器转换成NodeAllocator。忘记实现rebind模板实例化会直接编译失败。另外分配器必须是可拷贝的因为容器内部会按值保存你的分配器并复制到各个成员中。这也是为什么PoolAllocator只保存pool_id_而不是指针的原因——拷贝简单、语义干净。3.4 实测数据池化前后到底差多少我之前在Cortex-M4主频168MHz的项目里做过这样一个对比实验模拟同样的消息处理流程分别用标准malloc和上述MemoryPool各执行1000次分配与释放。malloc的平均分配时间大约在25个CPU周期左右但波动极大最快的不到10周期慢的时候能飙到200周期以上因为那恰好在空闲链表上做了一次块拆分。内存池则稳定得多固定为11个CPU周期几乎不受前期分配历史影响。碎片率方面malloc方案在反复分配不同大小对象后成功分配连续4KB缓冲的概率降到了30%以下池化方案因为槽位固定连续分配64个4KB消息帧毫无压力。这个数据只是参考毕竟硬件、编译器优化选项、malloc实现都会影响绝对数值。但趋势是普适的通用堆的时间不确定性和碎片化是结构性问题内存池从原理上就把它消掉了。对于实时任务里最敏感的那几条执行路径池化不是可选项而是必要手段。4. 嵌入式C内存调试实战从工具到自研检测4.1 工具链盘点Valgrind、ASan与目标板上的局限嵌入式关内存调试工具得先分清你跑的是嵌入式Linux还是裸机/RTOS。嵌入式Linux上可用工具丰富一些Valgrind的memcheck能帮你找内存泄漏、越界访问、野指针但代价是可执行文件运行速度会慢10到50倍而且依赖glibc的mmap行为最好在开发板本地跑而不是远程交叉执行。GCC和Clang的AddressSanitizerfsanitizeaddress对Linux用户态程序很有效但ASan本身需要较大内存和操作系统支持在无MMU的MCU上没法直接使用。裸机和RTOS就只能靠自己了。GCC ARM工具链有个-fsanitizeundefined选项可以检测未定义行为但嵌入式目标上支持有限。更实际的做法往往是自研检测代码把问题在开发和测试阶段暴露出来这也是我接下来重点展开的部分。4.2 重载operator new/delete做分配计数自研检测的第一步是重载全局operator new/delete在每次分配时记录总量和调用来源。下面这个版本我在裸机项目中常用#include cstdio #include cstdlib #include new static size_t g_heap_alloc_bytes 0; static size_t g_heap_alloc_count 0; static size_t g_heap_peak_bytes 0; void* operator new(size_t size) { void* ptr malloc(size); if (ptr nullptr) { // 重新抛出bad_alloc或在系统中挂接自定义OOM处理函数 throw std::bad_alloc(); } g_heap_alloc_bytes size; g_heap_alloc_count; if (g_heap_alloc_bytes g_heap_peak_bytes) { g_heap_peak_bytes g_heap_alloc_bytes; } return ptr; } void operator delete(void* ptr) noexcept { // 真正释放前无法轻易获取size统计会略偏大 if (ptr) { free(ptr); } } void report_heap_usage() { printf(heap current%zu peak%zu count%zu\n, g_heap_alloc_bytes, g_heap_peak_bytes, g_heap_alloc_count); }这段代码有一个明显局限delete被调用时我们无法得知这个指针原本分配了多少字节因为标准库的free不需要传入大小我们的统计也就只能单调增长到进程退出。想要精确统计释放量需要在分配时额外用一个头结构记录size释放时读取头结构再减去对应值这样还能顺带检查指针是否越界。更进阶的做法是在new里记录文件名和行号。宏定义可以在调用点捕获__FILE__和__LINE__但你得小心宏展开不要破坏整个项目的编译。工程实践上我会在核心模块的公共头文件里定义#define MY_NEW new(__FILE__, __LINE__)同时在operator new(size_t, const char*, int)里记录分配来源配合一个全局分配表按地址登记。要是发现某个地址的alloc和free次数对不上直接打印分配时的源码位置比拿着调试器在数百个函数里翻找快得多。4.3 栈水线和地址越界的识别栈溢出比堆泄漏更隐蔽通常表现为某个局部变量覆盖了相邻模块的数据。最经典的办法是在栈底放哨兵比如在启动汇编中把栈顶区域填满0xDEADBEEF周期性检测这些字节是否被破坏。RTOS的任务栈也可以这样做任务创建前把任务栈的内存全部填入特征值之后由调试任务扫描已经使用的浪尖高度从而估算每个任务实际需要的栈深度。地址越界方面Cortex-M等带有MPU内存保护单元的芯片可以配置内存区域属性把只读区域、外设区域、堆池区域分别设置访问权限一旦代码越界读写直接触发MemManage Fault而不是放任数据被悄悄改写。MPU配置初期会觉得繁琐但它在排查野指针和栈破坏时价值巨大主动把故障定位到具体地址而不是靠经验和运气去猜。5. RTOS实时系统中的堆选择与任务栈管理5.1 任务控制块、队列和信号量内存从哪来RTOS里的内存管理不只是你自己写的代码在维护对象内核本身也需要内存。以FreeRTOS为例创建任务时要把任务控制块TCB和任务栈都分配出来创建队列时也要为队列存储结构分配空间。这些分配走的是内核设定的堆管理机制而不是随便调用new。如果不用动态创建内核静态接口需要你自己为TCB、任务栈、队列控制块准备内存这其实是最稳的做法所有任务都在初始化阶段创建完毕之后整个系统不再动态分配内核对象实时性上限完全可知。有些团队为了省事允许任务中途创建那就要格外小心堆管理策略选型错误导致的分配失败。5.2 FreeRTOS heap_1到heap_5我该怎么选FreeRTOS提供了5种不同的堆实现应用场景各有侧重这里我整理成一张速查表堆实现是否支持释放是否合并相邻块适用场景与特点heap_1不支持不支持不删除任务、不创建再销毁对象内存一次性划分最简单、最稳定heap_2支持不支持可释放但容易产生碎片适合分配/释放对象大小固定且频率低的场景heap_3支持取决于libc包装了标准malloc/free并使用挂起调度器保护临界区和多线程库配合heap_4支持支持最常用能合并相邻空闲块碎片较少适合大多数动态任务场景heap_5支持支持同heap_4但支持跨多个非连续内存区合并使用适合多块RAM的MCU我个人的习惯是新项目默认heap_4除非明确不使用动态创建任务才换heap_1。heap_2的空间浪费和碎片风险比较高除非历史代码被它绑死否则我不推荐新项目用。heap_3好处是底层能复用libc的malloc调试手段但代价是标准malloc的时间不确定性原封不动地带进了RTOS多任务环境。还有一个经常被忽略的点FreeRTOS的heap_4有临界区保护分配时会暂时挂起低优先级任务。如果你的一个高优先级任务频繁分配小块内存低优先级任务可能会因为临界区长而错过截止时间。解决方案就是对高频分配对象做独立池化把内核堆的调用次数降下来。5.3 接口ISR与堆分配绝对不要混在一起中断服务程序里调用malloc或者new绝对是个雷区。FreeRTOS的文档明确说pvPortMalloc不能在中断服务程序中使用因为它可能会挂起调度器或关中断来保护临界区中断里挂起调度器很容易导致系统卡死。如果ISR需要传递数据正确姿势是ISR先把数据放进预先分配好的无锁环形缓冲或队列主循环任务再从池里取一个槽位处理数据。这种模式下中断只做“搬运”不涉及任何动态分配系统行为就能保持高度可预测。你也用不着在ISR里做OOM判断、恢复现场这种恐怖操作。我合作过的团队里凡是遵守这条规则的项目整体稳定性都远超那些在ISR里直接new一个对象的项目。6. 高频面试题和实际踩坑记录6.1 嵌入式C岗位的内存管理面试题这个主题也是热词里反复提到的“嵌入式面试八股文”常客。我把几道高频题整理出来附上相对实用的回答思路。malloc和new到底有什么区别new在malloc基础上增加了构造步骤返回类型安全还可能触发异常。嵌入式中更要关注的是new不一定走malloc你可能重载了它placement new则完全不分配内存。什么是碎片化哪些策略能避免碎片化分为外部和内部外部指连续空闲区域被分散内部指分配粒度余量浪费。避免方法对象池、固定大小分配、静态分配、支持合并的分配器如heap_4。对象池相比通用堆的优缺点优点是O(1)分配、无外部碎片、内存上限可控缺点是不灵活每种大小要建池低利用率时可能浪费空间。placement new有什么用在同一块预分配内存上构造对象常用于内存池、共享内存、DMA缓冲区。它不会分配新内存只执行构造函数。任务栈大小怎么评估开发和测试阶段栈填特征值周期扫描浪尖再加20%到50%安全余量。递归函数和大局部缓冲区是主要栈消耗源。中断里能不能用new几乎不能。更安全的做法是中断里只写无锁队列把处理逻辑交给普通任务普通任务再池化分配。如何设计一个可用的内存分配系统优先静态分配其次对象池最后才是通用堆限定所有分配的调用频率失败时必须有明确对策不能静默返回nullptr。6.2 项目实战中遇到的四个经典翻车现场第一个教训来自一个早期裸机项目。我把一块较大的DMA缓冲区定义成局部数组结果函数只被调用了几次进程就崩了。后来把栈哨兵打开才发现数组直接占掉了4KB而整个栈才8KB再加上几层函数调用的栈帧就把栈底覆盖了。从那以后凡是超过256字节的缓冲区我全改静态或池化分配再也没遇到过这类“无缘无故重启”。第二个案例是全局对象构造顺序惹的祸。项目中某个模块定义一个全局Logger对象另一个模块在另一个全局对象构造函数里调用Logger写日志。C标准对于不同翻译单元里全局对象的构造顺序没有规定链接器按依赖顺序排列时恰好让Logger后构造于是启动时访问了一个还没构造的对象。解决办法是不要依赖全局对象构造顺序用Lazy Singleton或者预留原始字节再显式初始化。第三个案例非常经典我的内存池Slot没有对齐导致Cortex-M上偶尔HardFault。结构体里有64位成员时ARMv7-M要求在8字节边界访问不对齐则总线出错。后来给数组加了alignas(max_align_t)问题瞬间消失。这种问题在PC上很难暴露因为x86对非对齐访问兼容性很好到了ARM上就是硬规则。第四个案例和FreeRTOS heap_2有关。项目里有一个收包任务频繁new/delete收发缓冲区运行一周后堆碎片化严重突然一次大包分配失败任务卡死。改成固定大小消息池后峰值内存率从90%降到稳定的70%全生命周期零失败。这件事让我彻底相信在长稳运行的嵌入式系统里池化的价值不是理论而是实实在在的可靠性指标。我自己现在写嵌入式C第一选择永远是静态分配第二是池化最后才轮到通用堆。这不是对动态内存储有什么偏见而是我太清楚在资源受限环境里每一次不确定的malloc都可能成为一个迟到的灾难。如果你也在做嵌入式C我建议先花两天把你目前代码里的所有new、delete、malloc、free列个清单看看到底有没有必要存在能不能放进一个固定池。这个过程做完你会对“嵌入式C内存管理”这几个字有完全不一样的体会。