2、C语言内存布局：代码段、数据段、BSS段、堆、栈的详细解析与地址映射

嵌入式开发中，内存布局是绕不开的核心话题。我见过不少新手，代码写得很溜，一遇到内存问题就抓瞎。说白了，你连变量放在哪儿都不知道，怎么指望程序稳定跑上几年？

今天咱们就把内存布局这层窗户纸捅破。我会结合自己踩过的坑，把每个段的作用、地址映射关系讲清楚。

2.1 五大内存区域概览

一个C程序编译后，在内存里会分成五个区域。我习惯把它们比作一个公司的不同部门：

区域 英文名 存储内容 生命周期
代码段 Text 机器指令、常量字符串 程序运行期间
数据段 Data 已初始化的全局/静态变量 程序运行期间
BSS段 BSS 未初始化的全局/静态变量 程序运行期间
堆 Heap 动态分配的内存 手动分配到释放
栈 Stack 局部变量、函数参数 函数调用期间

嗯，这里要注意：代码段和数据段在编译时就确定了大小。堆和栈则是在运行时动态变化的。

2.2 代码段（Text Segment）

代码段存的是啥？就是你的程序指令。我举个例子：

const char* str = "Hello";  // 字符串常量放在代码段
void func(void) {
    // 函数指令也放在代码段
    int a = 10;
}

代码段有几个特点：

  • 只读：防止程序意外修改指令。我在项目中遇到过有人试图通过指针修改字符串常量，结果直接触发硬件异常。
  • 共享：多个进程运行同一个程序时，代码段可以共用。这在RTOS里很常见。
  • 地址固定：编译时就确定了起始地址。比如STM32的Flash起始地址通常是0x08000000。
避坑指南：我曾经在调试一个Bootloader时，发现程序跳转后跑飞了。查了半天，原来是代码段地址配置错了。记住：链接脚本里的代码段起始地址，必须和硬件实际映射地址一致。

2.3 数据段（Data Segment）

数据段存放的是已经初始化的全局变量和静态变量。你想想看：

int global_var = 100;        // 放在数据段
static int static_var = 200; // 也放在数据段

数据段在程序启动时从Flash拷贝到RAM。为什么？因为Flash是只读的，而变量需要读写。我个人习惯在链接脚本里明确指定数据段的加载地址和运行地址。

举个例子，在STM32的链接脚本中：

/* 加载地址在Flash */
.data : AT ( _sidata )
{
    _sdata = .;
    *(.data)
    _edata = .;
} > RAM

这里有个关键点：数据段的大小直接影响RAM占用。我见过有人把大数组定义为全局变量，结果RAM不够用。嗯，这时候就该考虑用堆了。

2.4 BSS段（Block Started by Symbol）

BSS段存放未初始化的全局变量和静态变量。说白了，就是那些你声明了但没赋值的变量：

int uninit_global;      // 放在BSS段
static int uninit_static; // 也放在BSS段

BSS段在程序启动时会被清零。为什么？因为C标准规定未初始化的全局变量默认值为0。我记得有一次，同事在代码里直接用了未初始化的局部变量，结果每次运行结果都不一样。这就是没搞懂BSS段和栈的区别。

关键区别：BSS段不占用Flash空间，只占用RAM空间。因为初始值都是0，没必要存到Flash里。启动代码里用memset清零即可。

2.5 堆（Heap）

堆是动态内存分配的区域。你用malloc、calloc、realloc申请的内存都来自这里。我建议嵌入式开发中慎用堆，原因有三：

  1. 碎片化：频繁分配释放会导致内存碎片。我曾经在一个长期运行的设备上，因为堆碎片导致malloc失败，系统直接重启。
  2. 不确定性：分配时间不确定，实时性要求高的场景不适用。
  3. 泄漏风险：忘记free会导致内存泄漏。在资源紧张的MCU上，泄漏几KB就可能出问题。

堆的地址通常从BSS段之后开始，向高地址增长。在FreeRTOS中，堆的实现方式有heap_1到heap_5五种，各有优劣。我个人习惯用heap_4，它支持合并相邻空闲块，能有效减少碎片。

2.6 栈（Stack）

栈是函数调用的核心。每次调用函数，系统会分配一个栈帧，存放局部变量、函数参数和返回地址。函数返回时，栈帧自动释放。

void func1(void) {
    int local = 10;  // 放在栈上
    func2();
}

void func2(void) {
    int local2 = 20; // 放在栈上
}

栈的特点：

  • 自动管理：不需要手动分配释放。
  • 速度快：比堆快得多，因为栈操作就是SP指针的加减。
  • 大小有限：MCU的栈大小通常在几KB到几十KB。递归调用太深会栈溢出。
避坑指南：我曾经在项目中遇到一个诡异的问题——函数调用到第三层时，局部变量莫名其妙被修改。查了两天才发现是栈溢出了，局部变量覆盖了全局变量。从那以后，我每个项目都会在链接脚本里给栈加上保护边界。

2.7 地址映射关系

在典型的ARM Cortex-M3/M4 MCU中，内存地址映射大致如下：

地址范围 区域 说明
0x08000000 - 0x080FFFFF Flash（代码段+只读数据） 程序指令、常量
0x20000000 - 0x2001FFFF SRAM 数据段、BSS段、堆、栈
0x40000000 - 0x400FFFFF 外设寄存器 GPIO、UART等

在SRAM内部，布局通常是：

低地址
+------------------+
| 数据段（.data）   | 已初始化全局变量
+------------------+
| BSS段（.bss）     | 未初始化全局变量
+------------------+
| 堆（Heap）        | 向高地址增长
|     ↓            |
|     ↑            |
| 栈（Stack）       | 向低地址增长
+------------------+
高地址

为什么堆和栈要相向生长？说白了，是为了最大化利用有限的RAM空间。堆向上增长，栈向下增长，中间的空闲区域可以灵活分配。

个人经验：我习惯在启动代码里添加栈和堆的边界检查。比如在FreeRTOS中，使用uxTaskGetStackHighWaterMark()函数监控栈使用情况。一旦发现栈使用率超过80%，就触发告警。这招帮我提前发现了不少潜在问题。

2.8 实战建议

最后，给你几个实用的建议：

  • 优先用栈：能用局部变量就别用全局变量，能用静态分配就别用动态分配。
  • 明确大小：在链接脚本里明确指定堆和栈的大小。不要依赖默认值。
  • 监控使用：定期检查栈和堆的使用情况，尤其是在压力测试时。
  • 避免递归：嵌入式开发中尽量不用递归，或者严格控制递归深度。

嗯，内存布局这块就讲到这里。下一章咱们聊聊指针和数组的内存管理，那才是真正容易出问题的地方。

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