Zephyr的内存管理专题写到第17篇，这次终于轮到了 Memory Pools。之前大家可能已经在项目里见过K_MEM_POOL_DEFINE这个宏，也见过k_mem_pool_alloc和k_mem_pool_free，但真正遇到“pool 到底怎么配？为什么我定义了 8 块的内存池，分配了几次小的就再也分配不出大的？”这类问题时，不少人是靠试错解决的。本文不打算只贴 API，我会把内存池在内核里的角色、新旧两代实现差异、参数设计逻辑和实际项目中容易踩的坑一次性讲清楚。如果你已经开始用 Zephyr 写多线程应用，或者正在调网络栈、传感器缓冲、协议解析这类需要固定配额内存的场景，这篇文章可以直接当参考手册用。
1. 先盘一盘：Zephyr里到底有哪几类内存来源
1.1 静态分配、线程栈、系统堆各有各的舞台
在 Zephyr 里，一个线程能拿到的内存来源其实没有想象中多。大多数时候无非是这四类：编译期静态数组、线程栈、全局系统堆（k_malloc/k_heap）、以及本文的主角 Memory Pools。
| 内存来源 | 分配时机 | 特点 | 典型场景 |
|---|---|---|---|
| 静态数组 | 编译期 | 地址固定、零管理开销、不可动态复用 | 全局配置、常驻缓冲区 |
| 线程栈 | 编译期 | 每个线程独享，大小固定 | K_THREAD_STACK_DEFINE定义的栈 |
| 系统堆 | 运行期 | 全局共享、接口简单、存在碎片风险 | k_malloc分配临时对象 |
| Memory Pool | 运行期 | 私有配额、可阻塞/可超时、碎片更可控 | 网络包缓冲、协议解析、外设 DMA 区域 |
很多人一开始只把k_malloc当成唯一的动态分配手段，项目里所有模块都去全局堆里要内存。这种做法在原型阶段没问题，但等到模块变多之后就麻烦了：A 模块每次申请 200 字节，B 模块申请 2K，C 模块用完了又释放，全局堆的空闲区会被切得越来越散。运气好的时候大家相安无事，运气差的时候某个模块连续申请几次大块，另一次申请就失败。这种“外部碎片”在长期运行的嵌入式设备上特别讨人厌。
Memory Pools 的思路完全不同。它不是让所有模块共享一个大堆，而是允许你在编译期就划出一块独立内存，规定好最小块、最大块、对齐方式和总配额，只给特定模块或者特定用途使用。这样即使别的模块内存告急，也不会影响这块专用区域的稳定性。
1.2 Memory Pools 专门解决什么问题
用一句话概括：Memory Pools 解决的是“确定性”和“隔离性”问题。
所谓确定性，指的是分配时间相对可控。内存池在定义时已经准备好了内部结构，分配一个块就是从池里取空闲块的过程，不需要像系统堆那样频繁扫描空闲链表。
所谓隔离性，则更贴近实际工程。比如一个传感器采集模块，它需要周期性申请缓冲区存放数据，如果它和网络协议栈共用同一个全局堆，那么网络流量一大，传感器就可能拿不到内存，导致采样丢失。把传感器的缓冲区单独放一个 Memory Pool，无论网络模块怎么折腾，这个池子都会留给传感器用。这种“内存配额”的概念在 RTOS 里非常实用。
1.3 一个典型场景里的 Memory Pool 影子
实际开发中，Memory Pool 最常出现在两类代码里：一类是“固定包大小”的收发缓冲，比如 CAN 报文、串口 DMA 的接收描述符；另一类是“并发数量有上限”的资源池，比如 USB 请求块、传感器数据队列。
拿模拟项目 X 里的一个例子来说，某驱动模块需要同时管理 8 个协议帧缓冲，每个缓冲最大 512 字节。如果每次发送都在栈上临时构造，栈压力会很大；如果用全局堆，又怕被其他模块挤占。这时候定义一个专用的 Memory Pool 就是最省心的做法：线程在发送时从池里拿块，填充协议头，交给下层驱动，发送完成后再释放回池子。整个过程不依赖全局堆，也不容易出现“内存被谁偷走”的问题。
2. 两代实现的差别：从 Buddy Split 到 sys_heap 包装
2.1 旧版内存池的 block 分裂逻辑
Zephyr 的 Memory Pools 不是今天才有的。早期版本里的实现是一种类似 Buddy 块分裂的算法，理解它可以帮助你更好地理解现在K_MEM_POOL_DEFINE的参数来源。
老版内存池定义形态和现在很接近：K_MEM_POOL_DEFINE(name, minsize, maxsize, align, nblocks)。宏在后台会准备一块总容量接近nblocks * maxsize的内存，但初始化时并不会把所有内存切成小块。它更聪明一点：一开始只有若干个maxsize大小的“根块”，当有分配请求进来时，比如请求 200 字节，而当前只有一个 1024 字节的大块，分配器就把这个大块从中间劈开，变成两个 512 字节的块；如果 512 还是比 200 大很多，就继续劈成两个 256，直到块大小足够容纳请求但不会太浪费为止。
这种分裂机制的好处是分配块时立刻能找到合适大小，不用遍历一堆零碎的空闲区。代价则是实现复杂：释放的时候要把同一个父亲分裂出来的块合并回去，否则池子里会积累大量大小参差不齐的空闲块。Zephyr 维护这套算法维护了很久，但它本质上还是一个“2 的幂次”固定粒度的分配器，内部碎片无法避免。比如你请求 200 字节，它最终给你的可能是 256 字节块，多出来的 56 字节你是用不上的。
2.2 新版基于 sys_heap 的桶结构
到了新版本，内核把 Memory Pool 的底层全部重构成了统一的sys_heap。也就是说，你看到的k_mem_pool_alloc里实际发生的分配逻辑，和内核自己的k_heap_alloc是同源的，差异主要体现在 API 外壳上。
sys_heap的设计可以简单理解为“按 size class 分桶维护空闲块”。分配的时候，根据请求大小找到合适的桶，取一个大小差不多的块返回；释放的时候，查看相邻内存块是否空闲，如果空闲就合并成一个更大的块，再挂回更大 size 的桶里。这样既保留了旧版 block 分裂的“快速拿到可用块”优势，又通过相邻合并避免了长期运行后外部碎片越积越多的问题。
这套重构对用户最大的好处是：老代码不用推翻重写，K_MEM_POOL_DEFINE和k_mem_pool_alloc这些 API 继续保留，但背后那块底料已经换成更健壮的引擎了。所以你现在读新版本文档，会发现 Memory Pools 描述里经常直接提到 heap 的概念，这并不矛盾——它就是同一个系统的两个面孔。
2.3 K_MEM_POOL_DEFINE 参数逐项拆解
既然参数这么定义，那咱们就得把每个参数背后的含义弄明白，否则内存池很容易配错。
name就是池子对象名，没什么好解释的。minsize是这个池子允许分配的最小块大小。比如你要求最小的内存申请是 8 字节，那么minsize可以定成 8。这里的实际效果不仅仅影响最小请求能不能满足，还影响整个池子的内存分配粒度。
maxsize是池子能够分配的最大块大小。任何大于maxsize的请求都会直接失败，设计时应当以你这个模块可能出现的最大单次内存需求为准。
align是每个内存块的对齐边界，必须是 2 的幂。大多数时候 4 或 8 就够了，但如果内存要给 DMA 外设用，你就得看外设手册要求的对齐字节数，常见的有 32 或 64，这时候align就跟着设成对应值。
nblocks是最容易理解错误的参数。很多初学者把它当成“池子里最多可以有几个块”，但它的真实语义其实是“总空间近似等于 nblocks 个 maxsize 块”。也就是说，假设你定义K_MEM_POOL_DEFINE(my_pool, 8, 1024, 4, 4)，那么这个池子的总容量预算就是 4 个 1024 字节块的总和。你可以拿它分配 4 次 1KB，也可以分配很多次 8 字节的小块，具体能分多少个要看实际分配的大小和释放节奏。
这个参数设计是历史遗留。在老版分裂算法里，以 maxsize 块作为源头比较自然；新版底层换成了 sys_heap 之后，宏只是帮你生成一块总容量对应的连续 RAM 缓冲，再把这块 RAM 初始化为堆。搞清楚这一点之后，你调参时就不会再问“为什么我有 4 个 1KB 的块，分了几个 200 字节之后就申请不出 1KB 了”——因为那些小分配已经把大块分裂/占用掉了。
3. 实例代码：定义一个私有 Memory Pool 并分配/释放
3.1 最小可运行片段
下面是一段最基本的使用代码，把 API 调通再谈细节。
#include <zephyr/kernel.h> #include <string.h> /* 定义一个私有内存池： * 最小块 16 字节，最大块 512 字节，4 字节对齐，总空间约 4 * 512 字节 */ K_MEM_POOL_DEFINE(can_tx_pool, 16, 512, 4, 4); void send_can_frame_demo(uint8_t *payload, size_t len) { struct k_mem_block blk; int ret; ret = k_mem_pool_alloc(&can_tx_pool, &blk, len, K_FOREVER); if (ret != 0) { /* 正常情况下 K_FOREVER 不会走到这里，除非参数有问题 */ return; } /* blk.data 才是真正可用的内存指针 */ memcpy(blk.data, payload, len); /* 使用完释放回池子 */ k_mem_pool_free(&blk); }这段代码看着简单，但里面有几个值得注意的地方。第一，k_mem_pool_alloc的第二个参数不是void **，而是一个struct k_mem_block指针。很多刚接触的人会把返回值直接当成void *，然后发现编译报错，其实分配出的内存地址藏在blk.data里，这个设计有它的历史原因，后面专门讲。第二，k_mem_pool_free传的是&blk，不是blk.data，虽然新版本底层可能只依赖地址，但按照 API 约定传入块描述符是最标准的写法。
3.2 阻塞分配、超时语义与中断上下文约束
上面代码里K_FOREVER意味着如果池子暂时没有足够空间，当前线程会被挂起，等池子里有人释放内存后再被唤醒。这个机制对写实时系统的人来说是把双刃剑。
好处是代码简单，不需要关心“暂时没内存”这种错误分支，拿不到就等。坏处是如果你在一个绝对不能阻塞的地方用了K_FOREVER，整个任务会卡住。典型的翻车场景是中断上下文。在 ISR 里调用k_mem_pool_alloc是允许的，但超时参数只能是K_NO_WAIT，绝不能用K_FOREVER，因为中断回调不能进入休眠等待。ISR 里拿不到内存就直接处理失败分支，返回错误码即可。
带上超时的写法则更适合那些“可以等一会儿但不能无限等”的场景：
ret = k_mem_pool_alloc(&can_tx_pool, &blk, len, K_MSEC(10)); if (ret == 0) { /* 拿到了 */ } else if (ret == -ENOMEM) { /* 10ms 内没等到，做降级处理 */ }我实际使用下来的经验是：普通线程之间用K_FOREVER问题不大，但凡是涉及外部事件驱动、中断下发、协议状态机的代码，最好都用K_NO_WAIT或短超时，宁可失败重试，也不要让任务被一个内存块卡死。
3.3 被许多人搞混的 k_mem_block 结构体
k_mem_block是传统 Memory Pool API 和k_heapAPI 最大的差别所在。k_heap_alloc直接返回void *，用完直接k_heap_free(ptr)，非常直白。而传统 pool 返回的是一个描述符：
struct k_mem_block { void *data; size_t size; };data指向分配到的内存，size表示块的实际大小。为什么要多套这么一层？因为在旧版分裂算法里，释放一个块不只是把内存归还池子，还得知道这个块到底属于哪一层分裂出来的、能不能和兄弟块合并。只传裸指针的话，分配器需要额外去查元数据才能确定归还逻辑。新版底层换了 sys_heap 之后这种需求弱化了很多，但 API 形态保留了下来。
这个结构体有个使用禁忌：它通常定义在栈上，调用完k_mem_pool_free(&blk)之后，这个描述符就没用了。千万不要把blk保存下来以后再用，也不要觉得blk.data还清了就继续往那块内存写东西。释放之后这块内存已经回到池子里，再读再写都属于越界使用，可能破坏堆结构。
4. 选型与踩坑：不要一上来就 K_MEM_POOL_DEFINE
4.1 k_heap、k_malloc、K_MEM_POOL_DEFINE 三者的真实关系
新版本 Zephyr 里，k_malloc其实是一个全局系统堆的便捷接口，这个全局堆由配置项CONFIG_HEAP_MEM_POOL_SIZE控制大小。K_MEM_POOL_DEFINE则是创建一个私有的、只有你自己代码能用的独立内存池。两者可以同时存在，互不干扰。
更值得关注的是k_heap。你可以用K_HEAP_DEFINE直接定义一个私有的堆对象，然后通过k_heap_alloc/k_heap_free使用。本质上，新版 Memory Pool 底层就是 sys_heap，而k_heap也是 sys_heap 的封装，二者共享同一套内核内存管理核心。
那到底用哪个？我的建议是分情况：
| 使用场景 | 推荐方案 |
|---|---|
| 系统级临时对象，各模块共享 | k_malloc |
| 某个模块独占的缓冲区，大小类型多样 | K_HEAP_DEFINE私有堆 |
| 老项目兼容，或者必须使用 pool API | K_MEM_POOL_DEFINE传统池 |
| 固定包大小、并发数量有上限的资源 | pool 或私有堆都可以，倾向 pool 语义 |
对全新项目，我更推荐优先考虑K_HEAP_DEFINE。它的代码更干净，API 返回裸指针，释放也更简单。K_MEM_POOL_DEFINE的主要价值在于兼容老代码和语义明确，新写的模块没必要非吊死在传统 pool 接口上。
4.2 参数设计不当的翻车现场
先说一个很典型的错误。假设有个模块每次最多申请 1KB，你想限制并发 4 个，于是写了：
K_MEM_POOL_DEFINE(stream_pool, 64, 1024, 8, 4);这看起来没毛病，但如果这个模块还经常申请 300 字节的小缓冲区，问题就来了。因为 300 字节在分配器里会被向上取整到某个 size class，比如 320 或 384 字节，它占用的不只是 300 字节。如果你反复分配 300 字节又释放，池子里可能积累了很多中不溜的块，导致你再去申请 1KB 时反而失败。这不是分配器坏了，而是你选的参数组合没有给“最大块请求”留出连续空间。
另一种常见问题是minsize设得太大。比如你把minsize设成 128，但业务里常常只需要 20 字节，那么每次这样的小请求都会浪费 100 多字节。嵌入式内存寸土寸金，池子里大量空间被这种内碎片吃掉非常可惜。反过来，minsize设得太小也不是好事，太小意味着池子的块粒度更细，元数据开销占比更高。
还有对齐问题。很多人以为align = 4已经够了，但 DMA 描述符经常要求 32 字节对齐。如果外设要求 32 字节对齐，而你的池子只按 4 字节对齐分配，拿到的地址可能外设根本没法用，轻则性能下降，重则总线错误。所以定义池子之前一定要把数据最终要交给谁看清楚。
4.3 对齐、元数据开销与调试方法
哪怕你不定义K_MEM_POOL_DEFINE，只写一个static uint8_t buf[4096]，系统也不会占满整个 4096 给你用。因为内存池要管理空闲块，就必须在每个块上维护元数据。sys_heap内部有 chunk header，每个分配出去的块前面都藏着一些控制字段，真正能给你用的时size往往会略小于池子总容量。
我见过有人在配置了CONFIG_HEAP_MEM_POOL_SIZE = 4096的板子上，连续分配 4 次 1024 字节失败。原因就是实际可用空间没有 4096 那么多，元数据和内部记录占了一部分。所以设计内存预算时，不能把配置值当成精确值，要留出 5%~10% 的余量。
调试内存池有没有泄漏，最直接的办法不是打印堆内部的空闲统计，而是在自己的代码里维护计数器。在分配成功时counter++，在释放时counter--，定期打印这个计数。如果它只增不减，那必然有路径漏了释放。配合k_mem_pool_free调用点检查，基本能把问题卡到位。如果你要分析整个 pool 编译后占用的 RAM 大小，可以看构建产物的符号表，搜一下池子对应的 buffer 符号，里面的长度就是宏生成的连续 RAM 缓冲大小。
5. 实测观察：分配耗时和碎片问题的直观感受
5.1 一个粗略的对比实验记录
我在这类内核配置上做过一次很粗糙的对比测试：一块 Cortex-M4 主频 64MHz 的设备，跑模拟项目 X，一个线程负责从传感器采样，另一个线程负责把采样结果拼成协议帧发送。采样线程使用传统K_MEM_POOL_DEFINE定义的固定池，发送线程偶尔会使用k_malloc从系统堆分配较大缓冲。
实测 1000 次分配/释放，Memory Pool 的分配耗时绝大多数在 1~2 微秒之间，波动很小；系统堆k_malloc分配同样大小的块，常规在 2~6 微秒，偶尔在堆状态比较复杂时会到 10 微秒以上。这个数据不是严谨基准，不同芯片和配置差异很大，但趋势是明确的：内存池的分配时间更平稳，系统堆受当前空闲分布影响更明显。
碎片方面我做了个更直观的观察：让模拟项目 X 连续跑几个小时，期间各种不同大小的分配交错进行。系统堆在长时间运行后，能够成功分配大块内存的概率比刚开始时略有下降；而 Memory Pool 因为释放时能合并相邻空闲块，长期运行后的大块可用性要稳定得多。
5.2 关于嵌入式内存管理我的一点总结性经验
真正用下来我才意识到，Memory Pools 的最大价值不是“更快的动态分配”，而是把内存资源在模块间划好了边界。全局堆像过山口，大家挤来挤去；私有 pool 像包间，互不打扰。对于传感器、协议栈、DMA 这些需要稳定配额的模块，划分独立池子能省掉大量排查“内存去哪了”的时间。
最后再分享一个小技巧：如果决定用传统 Memory Pool API，尽量在项目里封装一层自己的 alloc/free 接口，不要把k_mem_pool_alloc散落到业务代码各个角落。封装层里记录申请线程、申请大小、申请时戳，日后排查内存问题时这层日志就是最快的线索。别等到设备跑挂了再从头查，嵌入式内存管理这种事情，越早做工具化越省心。
