3、内存池配置与使用：K_MEM_POOL_DEFINE宏、内存块分配策略、内存池统计

好，咱们接着聊内存管理。前面讲了堆和内存块，这次轮到内存池了。说实话，内存池是我个人在Zephyr项目里用得最多的动态内存方案。为什么？因为它既灵活又可控，不像堆那样容易碎片化，也不像内存块那样死板。

3.1 K_MEM_POOL_DEFINE 宏：内存池的“出生证明”

要创建一个内存池，最直接的方式就是用 K_MEM_POOL_DEFINE 这个宏。它的用法其实挺直观的，但有几个参数你得搞明白。

K_MEM_POOL_DEFINE(my_pool, 64, 1024, 4, 8);

这行代码干了什么？它定义了一个名叫 my_pool 的内存池。后面四个数字分别是：最小块大小、最大块大小、对齐方式、每个尺寸级别的块数。

嗯，这里要注意。最小块和最大块决定了内存池的“粒度”。我习惯把最小块设成任务里最常申请的小内存大小，比如64字节。最大块则根据最大数据包来定。

对齐参数，说白了就是告诉系统：你给我的内存地址，必须是几的倍数？8字节对齐在Cortex-M上很常见。我曾经因为没注意对齐，导致DMA传输数据错位，排查了一整天。

最后一个参数“每个尺寸级别的块数”，这个很关键。它决定了内存池的总大小。你想想看，如果每个级别只有4个块，那同时只能有4个任务申请同一大小的内存。多了就阻塞或者返回NULL。

3.2 内存块分配策略：系统是怎么“分蛋糕”的？

内存池的分配策略，其实是个经典的“最佳适配”算法。但Zephyr做了一点优化。

当你调用 k_mem_pool_alloc() 申请一块内存时，系统会做两件事：

1. 向上取整：把你申请的大小，对齐到最近的“尺寸级别”。比如你申请80字节，系统会给你128字节的块。
2. 查找空闲块：从对应级别开始找，如果有空闲块就直接分配。如果没有，它会尝试从更大的级别“借”一块，然后拆分成两个小一级的块。

为什么会这样设计？说白了就是为了减少碎片。每次分配都尽量用最合适的大小，避免大材小用。

我在项目中遇到过一个问题：频繁申请和释放不同大小的内存，导致内存池里全是“大块拆成小块”的碎片。后来我调整了最小块大小和块数，情况就好多了。

3.3 内存池统计：知己知彼，百战不殆

光会用还不够，你得知道内存池里发生了什么。Zephyr提供了几个统计接口，我每次调试内存问题时都会用。

最常用的是 k_mem_pool_stats_get() 函数。它能告诉你：

• 每个尺寸级别有多少块
• 已经用了多少块
• 最大使用量是多少
• 分配失败的次数

来看个实际例子：

struct sys_memory_pool_stats stats;
k_mem_pool_stats_get(&my_pool, &stats);

printk("总块数: %d\n", stats.total_blocks);
printk("已用块数: %d\n", stats.used_blocks);
printk("最大使用量: %d\n", stats.max_used_blocks);
printk("分配失败次数: %d\n", stats.alloc_failed);

这段代码跑一遍，你就能看到内存池的健康状况。如果 alloc_failed 一直在涨，说明你的块数设少了。如果 max_used_blocks 接近 total_blocks，说明内存池快满了，得考虑扩容。

3.4 实际使用中的几个建议

说了这么多，总结几条我自己的经验：

• 最小块别设太小：比如设成16字节，但实际很少用这么小的内存，那纯属浪费。我一般设成任务里最常用的那个大小。
• 块数要留余量：别卡着上限设。系统运行中可能会有突发请求，留20%的余量比较稳妥。
• 释放要及时：用完了就调用 k_mem_pool_free()。忘了释放？嗯，内存泄漏就是这么来的。
• 考虑用内存切片：如果某个任务只申请固定大小的内存，用 k_mem_slab 可能更高效。内存池更适合大小不固定的场景。

最后说一句，内存池不是万能的。如果你的系统里内存申请模式非常固定，那内存块（memory slab）可能更合适。但如果你需要灵活应对各种大小的请求，内存池绝对是首选。

好了，这一章就到这里。下一章咱们聊聊内存优化的实战技巧，包括怎么分析内存使用、怎么减少碎片。到时候我会分享一个我踩过的坑，保证让你印象深刻。