3. 堆内存分配器剖析

在 VxWorks 中，malloc() 与 free() 并不是简单的“向系统要一块内存、再还回去”。它们背后是一条从应用层到堆管理器的完整调用链，链路上每一层都会引入额外开销。理解这条路径，是定位内存性能问题的第一步。

一、从应用调用到堆管理器：实现路径

VxWorks 的 malloc() 通常由 C 运行库提供，最终落到内核的堆管理例程。以常见的 VxWorks 6.x/7 为例，调用链大致如下：

应用代码
  └─ malloc(size)
       └─ C 库 malloc 包装（可能含线程安全/重入处理）
            └─ memPartAlloc(partId, size)
                 └─ 堆管理器：查找空闲块 → 分割 → 返回用户指针
                      └─ 若空闲块不足：memPartGrow / 扩展堆区

其中 memPartAlloc() 是核心。VxWorks 的堆由“内存分区”（memory partition）管理，每个分区维护一条空闲块链表。分配时，堆管理器需要：

• 根据请求大小加上块头（block header）开销，得到实际需要的字节数；
• 在空闲链表中查找第一个足够大的块（首次适配或最佳适配策略）；
• 若块大于需求，将其分割为“已分配块 + 剩余空闲块”；
• 从链表中摘除已分配块，返回用户数据区指针。

释放时，free() 调用 memPartFree()，把块重新挂回空闲链表，并尝试与相邻空闲块合并，以减少碎片。

二、分配粒度：不是你要多少就给多少

VxWorks 堆分配存在两个关键粒度概念：对齐粒度和块头开销。

多数架构要求返回指针按 8 字节或 16 字节对齐。因此，即使你请求 1 字节，实际占用的用户区也可能被向上取整到对齐边界。此外，每个已分配块前面有一个块头，用于记录块大小、状态和链表指针，通常占用 8～16 字节（取决于架构和配置）。

这意味着：请求 malloc(20)，在 8 字节对齐、块头 8 字节的典型配置下，实际消耗可能为：

块头 8 字节 + 用户区向上取整到 24 字节 = 32 字节

也就是说，20 字节的请求实际占用了 32 字节堆空间，开销率约 60%。小对象频繁分配时，这种“粒度放大”会显著降低堆利用率。

三、性能开销定位：时间花在哪里

一次 malloc() 的时间开销主要来自三部分：

1. 链表遍历：空闲块越多、碎片越严重，查找合适块的时间越长；
2. 块分割与合并：分割产生新块头，合并需要检查前后相邻块；
3. 并发保护：若堆被多任务共享，需要信号量或中断锁保护，带来竞争和上下文切换开销。

在 VxWorks 中，可以用 memPartShow() 查看分区状态，观察空闲块数量、最大空闲块和碎片情况。若空闲块数量持续增长而最大空闲块变小，说明碎片在恶化，分配路径会变长。

四、如何定位分配开销

定位堆分配性能问题，建议按以下顺序排查：

1. 统计分配频率与大小分布：在关键路径上记录 malloc/free 的调用次数和请求大小，判断是否存在大量小对象分配。
2. 查看分区状态：调用 memPartShow(memPartId, 0)，观察空闲块数量、最大空闲块、已分配块数。若空闲块数量远大于预期，说明碎片严重。
3. 测量单次分配耗时：用 sysTimestamp() 或示波器打点，测量 malloc/free 前后时间差，区分是分配本身慢还是锁竞争导致。
4. 检查并发竞争：若多个高优先级任务频繁分配同一分区，考虑为不同任务使用独立分区，或改用内存池减少锁争用。

五、优化方向

基于上述路径和开销分析，常见优化手段包括：

• 内存池：对固定大小对象使用 memPartCreate() 创建专用分区，或使用 poolLib，消除分割与合并开销；
• 减少小对象分配：将多个小对象合并为一次大分配，或使用对象缓存；
• 分区隔离：为不同任务或模块分配独立内存分区，降低锁竞争；
• 预分配：在系统初始化阶段一次性分配足够内存，运行期只做池内分配，避免堆扩展。

理解 malloc/free 在 VxWorks 中的真实路径和粒度开销，才能把“内存慢”从模糊感受转化为可定位、可量化的工程问题。