3. 堆内存管理（Heap）：VxWorks堆管理器（memLib）、堆分配策略（First Fit/Best Fit）、堆碎片问题与诊断
堆内存管理，说白了就是系统在运行时动态给你分配内存的那一套机制。你写程序时用 malloc 或者 VxWorks 里的 malloc（底层就是 memLib），就是从堆里拿内存。这块要是没用好，系统跑着跑着就崩了——我见过太多案例了。
3.1 VxWorks 堆管理器：memLib 的核心机制
VxWorks 的堆管理器叫 memLib，它管理着系统堆（system heap）和用户自定义堆。每个任务都可以有自己的堆，但默认大家共用系统堆。
memLib 的核心数据结构是空闲块链表。每个空闲块头部有个小结构体，记录了块大小和下一个空闲块的指针。分配时，它遍历这个链表，找到合适的块，切一块给你，剩下的放回链表。
关键点：VxWorks 的堆管理器是线程安全的。内部用了互斥锁（mutex）保护链表操作。但这也意味着，高频率的 malloc/free 会导致任务切换和锁竞争，影响实时性。
我个人习惯在系统启动阶段就把大块内存分配好，避免运行时频繁操作堆。你想想看，一个中断服务程序里调 malloc？那基本是给自己挖坑。
3.2 堆分配策略：First Fit vs Best Fit
VxWorks 支持两种分配策略：First Fit（首次适应）和Best Fit（最佳适应）。默认是 First Fit。
| 策略 | 原理 | 优点 | 缺点 |
|---|---|---|---|
| First Fit | 从链表头开始，找到第一个足够大的块就分配 | 速度快，分配时不需要遍历整个链表 | 容易产生碎片，大块内存被切碎 |
| Best Fit | 遍历整个链表，找到最接近请求大小的块 | 碎片更少，内存利用率高 | 分配速度慢，需要遍历所有空闲块 |
我在项目中遇到过一个问题：一个网络协议栈频繁分配 64 字节、128 字节的小块，用 First Fit 跑了几天后，系统报告内存不足，但实际空闲总量还有 40%。这就是典型的碎片问题。
后来我改成 Best Fit，情况好了一些，但分配延迟明显增加。嗯，这里要注意：没有完美的策略，只有适合场景的策略。
我的建议：
- 如果分配大小比较固定，用 First Fit 就够了
- 如果大小变化大，且系统对延迟不敏感，用 Best Fit
- 如果实时性要求高，干脆别用堆，用静态分配或内存池
3.3 堆碎片问题：为什么系统明明有内存却分配失败？
堆碎片分两种：外部碎片和内部碎片。
- 外部碎片：空闲块分散在堆的各处，每个块都不大，但加起来总量很大。你要一个 1KB 的块，但最大的空闲块只有 512 字节，分配失败。
- 内部碎片：分配时块大小向上取整（比如对齐到 8 字节），多出来的那几字节浪费了。
外部碎片是更头疼的问题。我曾经在一个数据采集系统里遇到过：系统跑了 72 小时后，突然报 malloc failed。我查了堆状态，空闲总量还有 2MB，但最大连续块只有 200 字节。这就是典型的碎片风暴。
3.4 堆碎片诊断：如何定位问题？
VxWorks 提供了一些工具来诊断堆状态。最常用的是 memShow() 和 memPartShow()。
// 在 shell 中执行
-> memShow
FREE_LIST: size: 0x1234, num: 45
ALLOC_LIST: size: 0x5678, num: 120
Total free: 0x10000 (65536 bytes)
Largest free block: 0x800 (2048 bytes)
Total allocated: 0x20000 (131072 bytes)
重点关注 Largest free block。如果这个值远小于 Total free，说明碎片严重。
警告：不要在生产环境频繁调用 memShow()。它需要遍历整个链表，会阻塞其他任务的内存操作。我一般只在调试阶段用，或者通过一个低优先级任务定期采样。
还有一个更细粒度的工具：memPartShow()，可以查看指定堆分区的状态。
-> memPartShow sysMemPart
partition: sysMemPart
Total memory: 0x400000 (4194304 bytes)
Free memory: 0x100000 (1048576 bytes)
Number of free blocks: 200
Largest free block: 0x200 (512 bytes)
Number of allocated blocks: 300
Number of failed allocations: 5
看到 Number of failed allocations 了吗？这个值如果持续增长，说明你的系统正在走向内存耗尽。我曾经就因为没注意这个值，导致一个飞行控制器在空中重启——嗯，那次教训很深刻。
3.5 实战建议：如何减少堆碎片？
- 使用内存池（memPool）：对于固定大小的分配，用内存池替代堆。没有碎片问题，分配速度也快。
- 避免频繁分配释放：尽量在初始化阶段分配好，运行时复用。
- 使用分区堆（partition）：把不同用途的内存分到不同堆里。比如网络包用一个堆，文件系统用另一个堆。这样某个堆碎片了，不影响其他模块。
- 定期整理堆：VxWorks 没有自动的堆压缩功能。但你可以自己实现一个整理机制——把堆里的数据搬移到连续区域。不过这个操作很危险，要确保所有指针都更新。
避坑指南：我曾经在一个项目中，为了减少碎片，把所有 malloc 都改成了 memalign（对齐分配）。结果碎片更严重了——因为对齐导致内部碎片增加。后来我才明白，对齐不是万能的，要根据实际数据大小选择对齐粒度。
3.6 总结
堆内存管理是嵌入式系统的核心问题之一。VxWorks 的 memLib 提供了灵活的策略选择，但真正的挑战在于如何避免碎片。我的经验是：能不用堆就不用堆，非用不可就用内存池。如果实在要用堆，记得定期用 memShow 监控碎片情况，别等到系统崩溃才后悔。
下一章我会讲 VxWorks 的内存保护机制——MMU 和 MPU 的配置与调优。到时候我会分享一个我踩过的坑：MMU 页表配置错误导致系统跑飞的故事。