4、内存管理优化：静态内存分配、动态内存分配陷阱、内存碎片整理、三星Exynos Cache一致性

内存管理，说白了就是给程序找地方住。住得好，系统跑得顺；住得乱，死机、卡顿、莫名其妙的问题全来了。我在三星平台摸爬滚打这些年，见过太多因为内存管理不当导致的实时性灾难。今天咱们就把这块硬骨头啃下来。

4.1 静态内存分配：稳，就一个字

我个人习惯，在RTOS项目里，能静态分配就绝不动态分配。为什么？因为静态分配在编译时就定死了，运行时没有分配开销，也没有失败风险。

举个例子，你定义一个任务栈：

// 静态分配任务栈
#define TASK_STACK_SIZE 1024
static StackType_t taskStack[TASK_STACK_SIZE];

// 创建任务时直接使用
xTaskCreateStatic(
    vTaskFunction,
    "MyTask",
    TASK_STACK_SIZE,
    NULL,
    1,
    taskStack,
    &taskBuffer
);

你看，栈空间在编译时就分配好了。运行时创建任务，就是填几个结构体字段，快得很。我在项目中遇到过，有些同事图省事用动态创建，结果系统启动时频繁分配任务栈，导致高优先级任务被阻塞——这其实是可以避免的。

核心原则：实时任务的所有内存，尽量在初始化阶段一次性分配完毕。运行期间只使用，不分配。

4.2 动态内存分配陷阱：你以为的省心，其实是定时炸弹

动态分配不是不能用，但你要知道它的坑在哪。我踩过，所以今天帮你排一排。

陷阱一：分配时间不确定

malloc 或者 RTOS 的 pvPortMalloc，内部都要遍历空闲链表找合适的内存块。如果链表很长，或者碎片很多，这个时间可能从几微秒飙到几百微秒。你想想看，一个硬实时任务要求 100 微秒内响应，结果分配内存就花了 200 微秒——这不就崩了吗？

陷阱二：内存泄漏

动态分配了不释放，或者释放了又用。我在三星 Exynos 4412 上调试过一个多媒体应用，跑着跑着系统就卡死了。查了两天，发现是一个音频解码库每次解码都分配一块缓冲区，但只在特定条件下释放。内存一点点漏完，系统就挂了。

陷阱三：堆碎片化

频繁分配、释放不同大小的内存块，堆空间会变得像蜂窝煤一样。明明总空闲空间够，但连续的大块内存就是没有。这时候再申请一个大缓冲区，直接失败。

避坑指南：我曾经在一个项目中，把所有动态分配都集中到系统初始化阶段。运行期间，所有任务都使用预先分配好的内存池。从那以后，内存相关的实时性问题几乎绝迹。

4.3 内存碎片整理：给内存做一次「搬家」

碎片已经产生了怎么办？整理呗。但注意，碎片整理不是随便能做的。

常用的方法有两种：

  • 内存池（Memory Pool）：把堆分成固定大小的块。比如 32 字节、64 字节、128 字节的池子。申请时按需取块，释放时归还。这样碎片只会在池内产生，不会跨池扩散。
  • 紧凑（Compaction）：把所有已分配的内存块挪到一起，空出连续的大块空间。但这个方法有个致命问题——你得暂停所有任务，更新所有指针。在实时系统里，这几乎不可接受。

我个人推荐内存池方案。在 Exynos 平台上，我习惯这样设计：

// 定义内存池
#define POOL_32_SIZE  100
#define POOL_64_SIZE  50
#define POOL_128_SIZE 20

static uint8_t pool_32[POOL_32_SIZE][32];
static uint8_t pool_64[POOL_64_SIZE][64];
static uint8_t pool_128[POOL_128_SIZE][128];

// 分配函数
void* pool_alloc(size_t size) {
    if (size <= 32) return get_from_pool(pool_32, POOL_32_SIZE, 32);
    if (size <= 64) return get_from_pool(pool_64, POOL_64_SIZE, 64);
    if (size <= 128) return get_from_pool(pool_128, POOL_128_SIZE, 128);
    return NULL; // 太大，不支持
}

这样分配和释放都是 O(1) 的，时间完全确定。碎片？不存在的。

4.4 三星Exynos Cache一致性：别让缓存坑了你

Exynos 平台用的是 ARM 架构，有多级 Cache。Cache 是好东西，能大幅提升性能。但如果你在 DMA 和 CPU 之间共享数据，Cache 一致性就是个大坑。

举个例子：

// 假设有一个 DMA 缓冲区
uint8_t buffer[1024] __attribute__((aligned(32)));

// CPU 写数据到 buffer
buffer[0] = 0xAA;

// 启动 DMA，从外设读数据到 buffer
start_dma(buffer, 1024);

// DMA 完成后，CPU 读 buffer
if (buffer[0] == 0xAA) {
    // 这里可能出问题！
    // CPU 读到的可能是 Cache 里的旧数据，而不是 DMA 写的新数据
}

为什么会这样？因为 CPU 写 buffer 时，数据可能只进了 Cache，还没写回内存。DMA 是直接读写内存的，它看不到 Cache。所以 DMA 写内存后，CPU 读 Cache 还是旧数据。

解决办法？在三星 Exynos 上，我一般用这几招：

方法 操作 适用场景
Cache 刷新 DMA 前，CPU 主动将 Cache 写回内存 CPU 写，DMA 读
Cache 无效化 DMA 后，CPU 主动丢弃 Cache 中的旧数据 DMA 写，CPU 读
非缓存区域 将共享内存映射为 Non-cacheable 频繁共享的场景

在 Exynos 上，ARM 提供了 CP15 协处理器指令来操作 Cache：

// 刷新数据 Cache 行（写回内存）
void clean_dcache_line(void *addr) {
    asm volatile ("mcr p15, 0, %0, c7, c10, 1" : : "r" (addr));
}

// 无效化数据 Cache 行（丢弃缓存）
void invalidate_dcache_line(void *addr) {
    asm volatile ("mcr p15, 0, %0, c7, c6, 1" : : "r" (addr));
}

// 使用示例：DMA 前刷新
clean_dcache_line(buffer);
start_dma(buffer, 1024);

// DMA 完成后无效化
invalidate_dcache_line(buffer);
// 现在读 buffer 就是最新数据了

小技巧：在 Exynos 平台上，我习惯把 DMA 缓冲区定义在非 Cache 的内存区域。比如在链接脚本里单独划一块 Non-cacheable 区域。这样省去了手动刷 Cache 的麻烦，也避免了忘记刷 Cache 导致的 bug。

嗯，内存管理这块，说白了就是「空间换时间，确定性换灵活性」。静态分配、内存池、Cache 一致性处理，这些手段都是为了让系统的实时行为可预测。你在项目中遇到内存相关的问题，不妨从这几个角度去排查——大概率能找到根因。

← 上一章 📖 返回目录 下一章 →