3. 堆与栈的管理机制：栈指针初始化、堆内存分配算法

内存管理，说白了就是给程序里的各种数据找个合适的家。家分两种：一种是栈，规矩多但效率高；另一种是堆，灵活但容易乱。我做了这么多年嵌入式，见过太多因为栈溢出或者堆碎片导致系统神秘重启的案例。今天咱们就把这两块彻底聊透。

3.1 栈指针初始化——系统启动的第一件大事

芯片上电后，PC指针跳转到复位向量，第一件事是什么？不是跑你的main函数，而是先把栈指针（SP）设好。没有栈，连函数调用都做不了，更别提局部变量了。

我个人习惯在启动代码里这样处理：

; ARM Cortex-M 典型启动代码片段
; 栈顶地址由链接脚本提供
LDR R0, =_estack      ; 栈顶地址
MSR MSP, R0           ; 设置主栈指针
BL  SystemInit        ; 时钟、外设初始化
BL  main              ; 跳转到C世界

这里有个关键点：栈是向下生长的。你定义的栈顶其实是内存的高地址，压栈时SP递减。我见过有人把栈顶和栈底搞反，结果一调用函数就把数据写到未初始化的RAM区，系统直接跑飞。

我曾经踩过的坑： 某次项目用了一颗国产MCU，它的RAM只有8KB。我按惯例分配了4KB栈空间，结果程序跑起来后偶尔死机。查了两天才发现——中断嵌套太深，栈把全局变量区给覆盖了。从那以后，我养成了一个习惯：在链接脚本里给栈区前后各加一个“哨兵”区域，运行时周期性检查这些区域是否被改写。

3.2 栈的两种模式——MSP与PSP

在Cortex-M内核里，栈指针其实有两个：主栈指针（MSP）和进程栈指针（PSP）。

特性 MSP（主栈指针） PSP（进程栈指针）
使用场景 中断服务、异常处理、内核代码 用户任务、应用程序代码
默认状态 复位后默认使用 需手动切换（使用SPSEL位）
典型大小 512B ~ 2KB 每个任务独立分配
切换方式 硬件自动切换（进入异常时） 通过修改CONTROL寄存器

为什么要分两个？你想想看，如果中断和任务共用同一个栈，中断一嵌套，任务的栈帧就可能被冲掉。用RTOS的时候，每个任务有自己的PSP，中断用MSP，互不干扰。这个设计其实很巧妙。

3.3 堆内存分配——从“大饼”到“碎片”

堆和栈不一样。栈是编译器帮你管，堆得你自己管。malloc/free用起来爽，但背后的分配算法决定了系统的稳定性和实时性。

嵌入式系统里，堆通常是一块连续的内存区域，起始地址和大小在链接脚本里定义：

/* 链接脚本示例 */
HEAP_SIZE = 4K;

.sram_heap (NOLOAD) : {
    . = ALIGN(8);
    _heap_start = .;
    . += HEAP_SIZE;
    _heap_end = .;
} > RAM

分配算法的核心任务：在堆里找一块足够大的空闲块，切一块给你，剩下的继续留着。听起来简单，但不同的算法对性能和碎片的影响天差地别。

3.4 First Fit——最快找到“够用”的

First Fit的思路很直接：从堆的起始地址开始，挨个检查空闲块，找到第一个大小足够的就分配。

优点： 速度快，尤其堆的前部经常有空闲块时，几乎瞬间完成。
缺点： 容易在堆的前部产生大量小碎片，导致后续大块分配失败。

伪代码实现：

void* first_fit_alloc(size_t size) {
    free_block_t* curr = free_list_head;
    while (curr != NULL) {
        if (curr->size >= size) {
            // 找到合适的块
            if (curr->size > size + MIN_BLOCK_SIZE) {
                // 切分：剩余部分形成新空闲块
                split_block(curr, size);
            }
            remove_from_free_list(curr);
            curr->used = 1;
            return (void*)(curr + 1);  // 返回数据区地址
        }
        curr = curr->next;
    }
    return NULL;  // 分配失败
}

我在一个数据采集项目里用过First Fit。当时堆只有2KB，每次分配的数据包大小在32~128字节之间。跑了一周后，堆的前部全是几十字节的小碎片，后面一大块空闲却因为无法满足一个256字节的连续请求而分配失败。嗯，这就是First Fit的典型问题。

3.5 Best Fit——最省内存，但最慢

Best Fit的理念是：遍历所有空闲块，找到大小最接近你需求的那一块。说白了就是“不浪费”。

优点： 内存利用率高，大块空闲被保留下来给大请求。
缺点： 每次分配都要遍历整个空闲链表，速度慢；而且会产生很多极小的“微碎片”。

伪代码实现：

void* best_fit_alloc(size_t size) {
    free_block_t* curr = free_list_head;
    free_block_t* best = NULL;
    size_t best_size = SIZE_MAX;

    while (curr != NULL) {
        if (curr->size >= size && curr->size < best_size) {
            best = curr;
            best_size = curr->size;
        }
        curr = curr->next;
    }

    if (best != NULL) {
        if (best->size > size + MIN_BLOCK_SIZE) {
            split_block(best, size);
        }
        remove_from_free_list(best);
        best->used = 1;
        return (void*)(best + 1);
    }
    return NULL;
}
我的建议： 如果你的系统里分配的内存块大小比较固定（比如总是128字节或256字节），用Best Fit反而容易产生大量无法合并的微碎片。这时候不如用First Fit配合内存池（Memory Pool），把堆按固定大小切好，分配和释放都是O(1)复杂度，而且零碎片。

3.6 两种算法的对比

对比维度 First Fit Best Fit
分配速度 快（平均O(n/2)） 慢（必须遍历全部）
内存利用率 中等 高（保留大块）
碎片类型 前部小碎片 均匀分布的微碎片
释放合并难度 容易（碎片集中在头部） 困难（碎片分散）
适用场景 实时性要求高、分配频繁 内存紧张、分配次数少

3.7 堆与栈的布局策略

堆和栈在内存里怎么放？常见的有两种布局：

  • 堆在低地址，栈在高地址，相向生长： 经典布局，栈向下、堆向上，中间是未使用的RAM。好处是只要两者不相撞，内存利用率最高。坏处是一旦相撞，系统必挂。
  • 堆和栈各自固定区域： 堆在RAM开头，栈在RAM末尾，中间有明确边界。安全但浪费空间。

我个人更倾向第二种。虽然浪费一点空间，但调试时能明确知道是栈溢出了还是堆耗尽了。第一种布局出问题时，你根本分不清是谁先越界的。

堆与栈典型内存布局 堆区域（低地址 → 高地址） First Fit / Best Fit 分配 堆向上生长 空闲内存（未使用） 堆栈碰撞风险区 栈向下生长 栈区域（高地址 → 低地址） MSP / PSP 管理 堆从低地址向上分配，栈从高地址向下分配，两者相向生长，中间空闲区是安全缓冲

3.8 碎片整理——不得不面对的现实

不管用First Fit还是Best Fit，碎片都是逃不掉的。嵌入式系统里没有虚拟内存，不能像Linux那样做页面迁移。那怎么办？

我常用的几种策略：

  • 内存池（Memory Pool）： 把堆按固定大小（如16、32、64、128字节）切好，每种大小一个链表。分配时直接取，释放时直接还。零碎片，O(1)速度。代价是内部碎片（比如你申请30字节，它给你32字节的块）。
  • 定期检查与告警： 在空闲任务里遍历空闲链表，统计最大连续块大小。如果小于某个阈值（比如总堆大小的20%），就触发告警或重启。
  • 避免频繁分配释放： 能静态分配的就别动态分配。Bootloader里尤其如此——我一般只在加载固件时用堆，加载完就把堆还给系统。
我曾经犯过的错： 在一个Bootloader项目里，我用了标准库的malloc/free来解析固件头。结果某次固件头里有个畸形字段，导致malloc返回NULL后程序没检查，直接往NULL地址写数据。嗯，那批产品在产线上刷了30%就卡死了。从那以后，我所有的Bootloader代码里都自己实现分配器，而且每次malloc后必检查返回值。

3.9 实战建议——Bootloader里的堆栈设计

Bootloader对内存管理的要求其实比应用层更苛刻：

  • 栈大小要保守： Bootloader功能简单，一般512字节到1KB就够。但要注意中断嵌套深度——如果用了USB或以太网，中断服务里可能还有函数调用，栈需求会暴涨。
  • 堆尽量不用： 如果非用不可，建议用内存池代替通用malloc。Bootloader的生命周期很短，分配一次就不释放了，碎片不是问题。
  • 栈溢出检测： 在栈底放一个固定模式（比如0xDEADBEEF），每次进入main循环时检查这个模式是否被改写。被改写了就说明栈溢出了，直接进入错误处理。
← 上一章 📖 返回目录 下一章 →