嵌入式 C++ 教程——静态存储与栈上分配策略

最近感冒了，休息了好长一段时间。。。

在嵌入式系统里，内存资源稀缺且分布不均（Flash、SRAM、特殊高速 SRAM 等）。选择把数据放在 静态区（全局、静态变量、常量）还是 栈上（函数局部变量、临时对象）直接关系到程序的可靠性、启动时间、代码可维护性与实时性。本篇博客从概念、实现、常见问题到实战建议，给出工程可用的策略与示例代码。

---

什么是静态存储和栈上分配（快速定义）

静态存储（Static storage）：编译期/链接期分配的位置，包括 .text（代码 + rodata）、.data（已初始化的全局/静态变量，运行时拷贝到 RAM）、.bss（未初始化全局/静态变量，运行时清零）。这些变量在程序整个生命期或直到被显式改变才存在。

栈上分配（Stack allocation）：函数调用时由栈指针分配的内存，用于局部变量、返回地址、寄存器保存等。随着函数返回，栈空间释放。

---

为什么在嵌入式要慎重选择？

• 可预测性：静态存储大小可在链接时可见；栈增长与运行路径相关，难以静态保证不会溢出。
• 实时性：动态分配/大栈帧可能导致不可预测延迟。中断上下文对栈的使用需要特别注意。
• 内存分布：ROM/Flash 与不同等级的 SRAM（片上/外部）在速度与容量上差异大，静态数据可以放到合适的区域（例如把大只读表放在 Flash）。
• 重入性与线程安全：全局/静态变量默认非线程安全；在 RTOS 环境下需额外同步。栈上数据本质上对当前线程安全（每个线程独立栈）。

---

所以哪一些是静态存储的？

• 只读常量（const）：在 ARM/GCC 常见情况下放到 Flash 的 .rodata，运行时不占 RAM（如果没被强制复制）。使用 const 放查表、固件版本字符串等是节省 RAM 的好方式。
• 已初始化静态变量（.data）：编译器生成初始化数据在 Flash，启动时会被拷贝到 RAM，因此占用 RAM。
• 未初始化静态变量（.bss）：在启动时会被清零，占用 RAM，但不在 Flash 留大块初始化数据。
• 放置控制：可以用链接脚本和 __attribute__((section("..."))) 控制数据放置到特殊段（如快速 SRAM、非初始化段 .noinit 等）。
• 避免的问题：
• 大数组、缓冲区静态化会永久占用内存，若未正确规划会浪费或导致不可用内存短缺。
• 静态可变变量需考虑并发访问（中断、线程），使用 volatile/互斥/原子操作等。

示例：把大查表放到 Flash

// foo.cpp
static const uint16_t sine_table[256] = {
    // ... 256 entries ...
};

如果需要显式放到 .rodata / Flash 的特定段：

const uint16_t lookup[] __attribute__((section(".rodata.lookup"))) = { ... };

---

链接器脚本范例

在嵌入式工程，我们通常会改链接脚本来将段放到合适的内存区域

MEMORY
{
  FLASH (rx)  : ORIGIN = 0x08000000, LENGTH = 512K
  RAM   (rwx) : ORIGIN = 0x20000000, LENGTH = 128K
  FASTRAM(rwx) : ORIGIN = 0x20020000, LENGTH = 32K
}

SECTIONS
{
  .text : { *(.text*) *(.rodata*) } > FLASH

  .data : AT(ADDR(.text) + SIZEOF(.text)) {
    __data_start = .;
    *(.data*)
    __data_end = .;
  } > RAM

  .bss : {
    __bss_start = .;
    *(.bss*)
    __bss_end = .;
  } > RAM

  /* 自定义段放在 FASTRAM */
  .fastdata : {
    *(.fastdata*)
  } > FASTRAM
}

这个事情在UBoot里非常的常见，在代码里用 __attribute__((section(".fastdata"))) 把性能敏感的数据放到 FASTRAM。

---

栈上分配的风险与用法

• 大局部变量容易触发栈溢出。例如：

void foo() {
    uint8_t big_buf[64*1024]; // 很可能超出单个线程/中断栈
    // ...
}

• 递归：多数嵌入式系统应避免递归（难以估算最大深度）。
• 可变长度数组（VLA）/alloca：这类在运行时改变栈占用的特性在嵌入式里风险极高，尽量禁用或谨慎使用。
• 函数内临时对象：小对象优先放栈，大对象应放静态或堆（若允许）。

替代做法：将大缓冲静态化或放入任务专属内存池。

---

C++ 相关细节（构造、析构、placement new）

• 静态对象构造顺序：全局静态对象的构造顺序在不同文件间不保证（“静态初始化顺序 Fiasco”）。在嵌入式启动阶段，尽量把关键初始化显示写在 main() 或 init 函数里。
• placement new：可以在静态/栈/特定内存区域上显式构造对象（常用于无堆系统）：

alignas(MyType) static uint8_t buffer[sizeof(MyType)];
MyType* p = new (buffer) MyType(args...);  // placement new
p->~MyType(); // 手动析构

这在无 malloc 场景下非常有用，但要管理好对象生命周期。

---

无 malloc 时的策略（很多嵌入式项目要求）

• 使用固定大小对象池（object pool）或者是 环形缓冲区来替代堆。
• 通过模板或手写池实现类型安全的分配接口。
• 所有长期存在的缓冲区（比如网络包缓冲）优先考虑静态分配并放在合适段。

简单的 ring buffer（示意）：

template<size_t N>
class RingBuffer {
  uint8_t buf[N];
  size_t head = 0, tail = 0;
public:
  bool push(uint8_t v) { size_t n = (head+1)%N; if (n==tail) return false; buf[head]=v; head=n; return true; }
  bool pop(uint8_t &out) { if (head==tail) return false; out = buf[tail]; tail=(tail+1)%N; return true; }
};

最后

在嵌入式 C++ 开发中，静态存储带来可预测性与可控的长期内存占用，栈带来局部性与线程隔离。选择时要结合：缓冲大小、访问模式（并发/中断）、性能（速度/访问延迟）与可测性（栈使用可测）。实践中，优先将大对象、查表、DMA 缓冲放到静态区域或专用 RAM；将短小、生命周期局限的临时对象放到栈；严控动态分配，必要时使用对象池或 placement-new 管理内存。