17、加载与运行时：程序加载过程，进程地址空间布局
说实话，搞了这么多年C语言，我觉得最迷人的时刻，就是看着一个编译好的ELF文件，被操作系统一把拽进内存，然后活生生变成一个进程。这个过程，就像给一堆冰冷的机器指令注入了灵魂。
今天我们就来聊聊，程序是怎么从磁盘上的一个文件，变成内存里一个活蹦乱跳的进程的。我个人习惯把这件事分成两半来看：前半段是加载器的工作，后半段是进程地址空间的布局。
程序加载：谁把代码搬进内存的？
你写了一个 hello.c，编译链接后得到了 a.out。然后你在终端敲下 ./a.out，回车。这时候发生了什么？
嗯，这里要注意，不是CPU直接去读磁盘上的 a.out 文件。磁盘太慢了，CPU根本等不起。真正干活的是操作系统内核里的加载器（Loader）。
加载器的工作流程，我总结为三步：
- 读取文件头：内核先读ELF头，确认这是个合法的可执行文件。我记得刚入行时，有一次手贱改了ELF头的魔数，结果系统直接报"无法执行"，折腾了半天才反应过来。
- 建立进程映像：根据程序头表（Program Header Table），把各个段（Segment）映射到虚拟内存的对应位置。
- 设置启动环境：初始化栈、寄存器，最后跳转到入口点（
_start）。
关键点：加载器不是把整个文件都读进内存。它用的是"懒加载"策略——只有真正访问到某个页面时，才会触发缺页中断，然后从磁盘读入。说白了，就是按需加载。
进程地址空间布局：你的程序住在哪？
当一个进程被创建后，操作系统会给它一个完整的虚拟地址空间。在Linux上，典型的32位进程地址空间布局是这样的：
你想想看，这个布局其实挺有意思的。代码段在最底下，数据段和BSS段紧挨着，然后堆往上长，栈往下长。为什么这么设计？说白了就是为了让堆和栈能共享中间的空白区域，最大化利用虚拟内存。
各段详解：代码段、数据段、BSS段
咱们一个一个来看。
代码段（.text）
这里存放的是你的机器指令。在Linux上，代码段通常从 0x08048000 开始（32位）。这个段是只读的，你没法在运行时修改它。我曾经见过一个新手，试图用指针去改代码段里的数据，结果直接段错误——嗯，保护机制起作用了。
数据段（.data）
存放已经初始化了的全局变量和静态变量。比如你写了 int global = 42;，这个42就躺在数据段里。加载器会直接从可执行文件中把这段数据拷贝过来。
BSS段（.bss）
存放未初始化的全局变量和静态变量。比如 int global_uninit;。有意思的是，BSS段在可执行文件里其实不占空间——它只记录了一个大小。加载器在内存里给它分配空间，然后全部清零。我记得有一次面试，面试官问"BSS段在磁盘上占多大"，我脱口而出"0"，他点了点头。
小技巧：如果你用 size 命令查看一个可执行文件，会看到 text、data、bss 三列。你会发现 bss 那一列的数字往往不小，但文件本身却不大——这就是因为 BSS 段不占磁盘空间。
堆与栈：运行时的主角
堆和栈是程序运行时最活跃的两个区域。它们俩的脾气完全不一样。
| 特性 | 栈（Stack） | 堆（Heap） |
|---|---|---|
| 分配方式 | 自动分配/释放 | 手动分配/释放（malloc/free） |
| 速度 | 极快（一条指令） | 较慢（系统调用） |
| 大小 | 固定（通常8MB） | 可扩展（受限于物理内存） |
| 生命周期 | 函数调用期间 | 直到手动释放 |
| 典型问题 | 栈溢出 | 内存泄漏、碎片化 |
我个人习惯把栈想象成一个弹簧床垫——你往上放东西（压栈），拿掉东西（弹栈），它自动恢复原状。而堆就像一片荒地，你得自己挖坑（malloc），自己填坑（free），稍不注意就留下一个坑（内存泄漏）。
避坑指南：我曾经在一个嵌入式项目里，递归调用太深，直接把栈给撑爆了。程序跑着跑着就莫名其妙地挂了，查了半天才发现是栈溢出。从那以后，我写递归函数都会先估算一下栈深度。
加载过程中的重定位
这里有个细节很多人会忽略。你编译出来的可执行文件，里面的地址是虚拟地址。但加载器在把程序塞进内存时，需要处理一些重定位问题。
对于动态链接的可执行文件，情况更复杂。共享库的加载地址是不固定的——因为多个进程可能加载同一个共享库，但每个进程的地址空间布局不同。这时候就需要用到位置无关代码（PIC，Position Independent Code）。
说白了，PIC 就是让代码里的地址都变成相对地址，不管加载到哪个基地址，都能正确运行。我当年第一次接触这个概念时，觉得这简直是魔法。后来看了 GOT（全局偏移表）和 PLT（过程链接表）的实现，才恍然大悟——原来是通过一层间接跳转来解决的。
进程地址空间的保护机制
操作系统不是吃干饭的。它给每个段都设置了访问权限：
- 代码段：可读、可执行，但不可写。
- 数据段：可读、可写，但不可执行。
- 栈：可读、可写，但不可执行（NX位保护）。
- 堆：可读、可写，但不可执行。
这种权限分离，就是为了防止缓冲区溢出攻击。你想想看，如果栈是可执行的，那攻击者往栈里塞一段恶意代码，然后跳转过去执行，那不就完蛋了？
核心思想：进程地址空间不是一块大平地，而是一个精心规划的园区。每个区域有各自的用途和权限，谁也不能越界。这就是现代操作系统稳定性的基石。
一个简单的例子：看看你的程序怎么布局
我们来写个简单的程序，然后用 readelf 和 pmap 看看它的地址空间：
#include <stdio.h>
#include <stdlib.h>
int global_init = 100; // 数据段
int global_uninit; // BSS段
static int static_var = 200; // 数据段
int main() {
int local_var = 300; // 栈
int *heap_var = malloc(4); // 堆
*heap_var = 400;
printf("代码段地址: %p\n", main);
printf("全局初始化变量: %p\n", &global_init);
printf("全局未初始化变量: %p\n", &global_uninit);
printf("静态变量: %p\n", &static_var);
printf("局部变量: %p\n", &local_var);
printf("堆变量: %p\n", heap_var);
free(heap_var);
return 0;
}编译运行后，你会看到类似这样的输出（地址因系统而异）：
代码段地址: 0x400566
全局初始化变量: 0x601040
全局未初始化变量: 0x601044
静态变量: 0x601048
局部变量: 0x7ffd5c3b4a2c
堆变量: 0x1a7b010看到了吗？代码段在低地址（0x400000附近），数据段和BSS段紧挨着（0x601000附近），局部变量在栈上（0x7ffd开头的高地址），堆变量在中间（0x1a7b010）。这个布局和咱们前面画的图完全吻合。
嗯，到这里，加载与运行时的大致脉络就清楚了。从磁盘上的ELF文件，到内存里的进程映像，再到各个段的布局和权限——每一步都藏着操作系统的精巧设计。搞懂了这些，你写代码时就会多一份底气，少一份迷茫。
公众号:蓝海资料掘金营，微信deep3321