2、进程地址空间：用户空间与内核空间、栈与堆的布局、代码段与数据段
好，咱们今天聊聊进程地址空间。这东西说白了，就是操作系统给每个进程画的一个「虚拟地盘」。你写代码时用的指针、变量、函数，全在这个地盘里活动。我当年刚入行时，总觉得这玩意儿太抽象，直到有一次线上服务莫名其妙崩溃，查了三天才发现是栈溢出把关键数据给踩了……嗯，从那以后，我每次写代码都会在心里默默过一遍地址空间的布局。
2.1 用户空间与内核空间：那道不可逾越的墙
32位系统下，整个虚拟地址空间是4GB。这4GB怎么分？通常高地址的1GB给内核用，低地址的3GB给用户程序用。64位系统地址空间更大，但道理一样——内核和用户程序各占一块，中间有严格的界限。
核心要点：用户态程序不能直接访问内核空间的数据。你想想看，要是随便一个用户程序都能改内核的数据结构，那系统还不得乱套？
为什么会这样？因为CPU有特权级保护。用户程序运行在Ring 3，内核运行在Ring 0。你从用户态调用系统调用（比如read、write），CPU会切换特权级，从用户栈切到内核栈，执行完再切回来。这个切换是有代价的——上下文切换的开销就在这里。
我在项目中遇到过一个问题：一个高并发的网络服务，每秒要处理几万个请求，每个请求都涉及系统调用。结果性能上不去，一查火焰图，发现大量CPU时间花在了用户态和内核态的切换上。后来我们用epoll + 非阻塞IO，减少了系统调用次数，性能直接翻倍。
个人建议：写高性能程序时，尽量批量处理系统调用。比如用readv/writev一次读写多个缓冲区，而不是一个个地调read/write。
2.2 栈与堆的布局：一个向上，一个向下
栈和堆是进程地址空间里最常用的两个区域。它们的生长方向是相反的——栈从高地址向低地址生长，堆从低地址向高地址生长。这样设计的好处是：两个区域可以共享中间的「空闲区」，最大化利用地址空间。
栈（Stack）
栈是自动管理的。你调用一个函数，参数、局部变量、返回地址就被压入栈帧；函数返回，栈帧自动弹出。速度快，但空间有限——默认栈大小通常是8MB（Linux下可以用ulimit -s查看）。
我曾经犯过一个错误：在递归函数里定义了一个大数组，结果递归深度一深，栈就爆了。程序直接段错误，连个提示都没有。后来我改成用堆分配，或者把递归改成迭代，问题就解决了。
避坑指南：不要在栈上分配大对象。超过几KB的缓冲区，请用堆或全局数组。我曾经见过有人把1MB的图片数据直接定义成局部变量……嗯，那画面太美我不敢看。
堆（Heap）
堆是手动管理的。你用malloc/new分配，用free/delete释放。堆空间大得多，但管理开销也大——分配和释放都需要系统调用或内存管理器的介入。
堆的布局其实挺有意思。现代malloc实现（比如glibc的ptmalloc）会维护多个空闲链表，根据请求大小选择不同的分配策略。小对象用bins，大对象用mmap。我建议你了解一下tcmalloc或jemalloc，它们在多线程场景下性能更好。
| 特性 | 栈 | 堆 |
|---|---|---|
| 管理方式 | 自动（编译器管理） | 手动（程序员管理） |
| 生长方向 | 高地址→低地址 | 低地址→高地址 |
| 速度 | 快（寄存器操作） | 慢（系统调用+锁） |
| 空间大小 | 有限（通常8MB） | 大（取决于物理内存） |
| 典型问题 | 栈溢出 | 内存泄漏、碎片 |
2.3 代码段与数据段：程序的身躯与灵魂
一个可执行文件加载到内存后，会形成几个关键段：
- 代码段（.text）：存放你的机器指令。只读的，防止程序意外修改自己。我见过有人想用指针改代码段里的数据，结果直接段错误——嗯，保护机制起作用了。
- 数据段（.data）：存放已初始化的全局变量和静态变量。比如你写的
int global = 42;，这个42就存在.data段里。 - BSS段（.bss）：存放未初始化的全局变量和静态变量。程序加载时，这块区域会被自动清零。比如
static int x;，x的初始值就是0。 - 只读数据段（.rodata）：存放字符串常量、const变量等。比如
const char* s = "hello";，这个"hello"就存在.rodata里。
你想想看，为什么代码段要只读？因为如果代码段可写，病毒就可以修改你的程序逻辑。现代操作系统都支持ASLR（地址空间布局随机化），每次加载程序时，这些段的基地址都会随机化，增加攻击难度。
重要概念：代码段和数据段在编译时就已经确定了大小和内容。而栈和堆是在运行时动态变化的。这就是「静态」和「动态」的区别。
2.4 一张图看懂进程地址空间
下面我用SVG画一张典型的进程地址空间布局图。你仔细看看，每个区域的位置和生长方向都标出来了。
这张图里，从上到下依次是：内核空间、栈、空闲区、堆、数据段、代码段。栈向下生长，堆向上生长，中间的空闲区就是它们「打架」的地方。如果栈和堆撞上了，程序就崩了——这叫栈堆碰撞。
2.5 实战中的注意事项
说了这么多理论，来点实际的。我总结了几条经验：
- 检查栈大小：写递归或分配大局部变量前，用ulimit -s看看栈上限。不够就调大，或者改用堆。
- 避免内存碎片：频繁分配释放小对象会导致堆碎片。我建议用对象池或内存池来管理。
- 理解段错误：访问空指针、越界、写代码段，都会触发SIGSEGV。用gdb的bt命令看调用栈，定位问题很快。
- 利用工具：valgrind检查内存泄漏，perf分析性能，pmap看进程内存映射。这些工具我几乎天天用。
一个小技巧：在Linux下，你可以用 cat /proc/<pid>/maps 查看某个进程的完整地址空间布局。每一行对应一个映射区域，包括地址范围、权限、偏移量等。调试时特别有用。
好了，进程地址空间就聊到这儿。记住一句话：理解地址空间，就是理解程序在内存中的「活法」。你写代码时，心里要有这张图，知道每个变量、每个函数调用在哪个区域活动。这样出了问题，你才能快速定位。
可可精品资料库