从一次凌晨崩溃说起你必须吃透的内存五大分区先讲个真实的事。前几年我维护的一个网关服务上线不到一周每天凌晨准时崩一次日志里只留下一个莫名其妙的 signal 11SEGV。排查了一整天最后 gdb 加载 core 文件bt 一打发现是某个 SDK 底层库把字符串常量直接拿去当缓冲区改了。整个服务进程直接段错误退出连带调用方也断了。那次事故之后我带着组里的新人把所有内存分区的细节通读了一遍大家才真正意识到内存分区不是面试要背的八股而是每一行 C/C、嵌入式代码跑起来时脚下的地基。栈、堆、全局/静态区、常量区、代码区这五大分区决定了变量能活多久、能不能写、越界会发生什么。这篇笔记就是把我这几年踩过坑、画过图、调过 crash 后的理解完整梳理一遍适合刚开始学 C/C 的读者也适合 Redis、Nginx、嵌入式固件等底层系统方向的同学查漏补缺。1. 先建立整体认知五大分区到底是什么1.1 程序运行时内存长什么样不考虑操作系统内核占据的高地址空间一个普通进程的用户空间内存从高地址到低地址大致排布成下面这个样子栈区Stack向下增长存放函数调用过程中的局部变量、函数参数、返回地址。共享映射区mmap 区域在堆和栈之间用于动态库、mmap 映射面试时通常不单独算作“五大分区”。堆区Heap向上增长由程序员用 malloc/new 申请用 free/delete 释放。全局/静态存储区Data/BSS 段放全局变量、静态变量。其中已初始化的在 Data 段未初始化的在 BSS 段。常量区只读数据段通常叫 .rodata放字符串常量、const 修饰的全局常量等。代码区Text 段放编译后的机器指令。很多教材习惯把常量区并入“全局区”合称“五大分区”时则单独列出来因为常量区的只读属性和全局变量有本质区别。而代码区存的是指令凡是指针函数、函数名指向的就是这块区域。这么说可能还是抽象我换个方式把这六个区域想成一栋写字楼。代码区是物业的管理制度手册只读谁都不能改常量区是楼里公告栏上贴的通知大家都能看但不能撕全局/静态区是大楼公共储物间分配好了就一直在栈区是每家公司的临时工位进去就分配离开自动回收堆区则是仓库里的租用货架你要多大租多大用完必须自己还回去。这个类比后面讲每个分区时会反复用到。1.2 为什么要折腾分区一个大水桶不行吗这是新人最容易问的问题所有变量都塞在一块大内存里不行吗不行代价非常大。分区本质上是在回答三个问题什么时候分配内存什么时候回收内存这块内存能不能写先说生命周期。如果一个进程只有一块“全部内存”那局部变量用完该怎么回收谁来记录“这块内存现在没人用了”没有分区要么全部手动管理、复杂度爆炸要么等进程退出才统一回收、内存占用高得离谱。分区之后栈区天然支持函数调用嵌套退出函数自动回退栈指针零成本完成回收堆区则把“确切的释放时机”交给程序员灵活但危险并存。然后是权限。CPU 的 MMU 给每一页内存都打上了可读、可写、可执行的权限位。代码区的指令如果在栈区那攻击者往栈上塞一段 shellcode跳过去就执行了这就是臭名昭著的栈溢出攻击的根源。把代码区设置为只读可执行、栈堆设置为可读写不可执行是现代操作系统安全的基础。最后是编译器与 CPU 的优化。分区让编译器清楚哪些数据一定是局部的、生存期只在函数内从而放心地把它优化到寄存器里哪些数据是全局的、可能被任意函数修改就必须每一处访问都真真切切地读内存。理解了分区你才能真正看懂编译器的产物而不是当一个只会抄代码的“API 调用工”。1.3 静态内存和动态内存的分界从编译期到运行期另一个很关键的视野是这五区里栈、堆是运行期动态变化的全局/静态区、常量区、代码区在编译链接时就已经确定大小和位置。所以你会听到 people 说“静态内存分配”“动态内存分配”——静态指的是编译期就固定下来动态指的是程序运行期间才决定。分区分配时机释放时机是否可写栈区函数调用时函数返回时可读写堆区malloc/new 时free/delete 时可读写全局/静态区程序加载时程序退出时可读写常量区程序加载时程序退出时只读代码区程序加载时程序退出时只读静态区的“静态”不代表量的不变BSS 段大小是编译期算好的但它的内容可以在运行期随意读写。这个区分后面理解 static 变量时很关键。2. 栈区自动化程度最高的区域也最容易无声无息地崩2.1 栈的工作机制压栈、弹栈、栈帧栈区是五大分区里“最好用”的一个因为它完全由编译器介入管理不需要程序员动手。每次函数调用系统会在栈上划出一块区域叫栈帧stack frame用于存放这个函数调用的局部变量、参数、返回地址、保存的寄存器值等。函数返回时栈帧整体作废栈指针回退效果等价于“清空”。需要特别强调的是栈是向下增长的也就是从高地址往低地址涨。这一点和堆正好相反。我见过不少新手画内存图时画错方向结果分析递归嵌套时越分析越糊涂。x86 下有专门的栈指针寄存器rsp/esppush 指令让栈指针减小pop 指令让它增大。生活化类比自助餐厅的托盘架。你拿走一个托盘调用函数再拿走一个嵌套调用用完之后放回去一个函数返回再放回去一个。后拿的先放整齐利落。由于限定了“只能从顶部弹出”栈天然匹配函数调用的后进先出LIFO特性。2.2 栈溢出——最常见的崩溃原因讲栈区绕不开栈溢出。最常见的两个触发点我都踩过。第一个是无限递归。递归函数没有正确终止条件一层层往深处调每一层都压一个栈帧栈空间耗尽直接段错误。有一次我写的二分查找在“未找到”时递归调用自身而不是返回 -1最终以 stack overflow 收场。排查方法是用 gdb 跑bt 命令打出来看到的全是同一函数的重复地址一切都清楚了。第二个是局部大数组。有一个典型坑在函数里写char buf[1024 * 1024 * 10]也就是栈上申请 10 MB。Linux 下线程默认栈大小只有 8 MB在主线程可能侥幸够用但在线程池等工作线程里直接崩。这类问题很隐蔽因为编译能过小数据跑起来也正常数据量一上去就随机段错误。实操建议是大缓冲区、大结构体一律上堆。栈是拿来放小东西、放指针的。什么叫大我的经验阈值是单块超过 64 KB 就慎重考虑超过 1 MB 基本必须用堆。另外线上排查时可以用ulimit -s查看栈上限在 Linux 下临时调大也能应急但治标不治本。2.3 栈与多线程每个线程都有一块独立的栈多线程编程时很多人的内存观还是“一个进程一块栈”这是错的。现代操作系统里每个线程都有自己的独立栈区默认大小在 Linux 上通常就是 8 MBWindows 上主线程默认 1 MB子线程可以设置。所以线程内递归过深、局部变量过大只炸这个线程不会直接炸整个进程……但如果这个线程恰好在持有锁或者崩溃时这个线程是主线程那整个进程依旧逃不掉。我排查过一个诡异问题某服务在压测时每隔一段时间出现主线程栈溢出后来发现是测试脚本设置线程栈大小为 512 KB而某条业务链路里有一个巨大的临时结构体放在栈上平时压测少没事压测一高就崩。改法很简单把结构体改到堆上同时对线程栈大小设置了相对合理的下限。2.4 你不可不知的栈边界检测为了避免栈越过边界破坏其他数据操作系统在栈底设置了不可读写的保护页guard page。栈指针一碰到保护页CPU 触发缺页异常表现为段错误。好消息是这个机制让栈溢出不至于立刻静默破坏数据而是能尽早暴露崩溃点。坏消息是如果是递归爆栈你看到的是 stack overflow 而非直接告诉你“第几层有问题”排查路径会绕一些。3. 堆区程序员权力最大的区域也最容易翻车3.1 堆的工作原理手动分配手动释放堆区是所有分区里唯一完全由程序员控制生命周期的区域。无论 C 的malloc/free、realloc还是 C 的new/delete都在堆上进行。堆由低地址向高地址增长操作系统在底层通过brk系统调用扩展堆的结束地址或者通过mmap映射一块匿名内存来提供大块内存。打个比方栈是自助餐厅的托盘架堆就是仓库里的租用货架。你用malloc(100)租了一个格子用完之后必须free归还。不归还格子就一直被你占着还了再用就是“悬挂指针”也就是你手里的钥匙已经失效了再开门就是事故。3.2 堆区三大经典事故泄漏、悬挂指针、内存碎片内存泄漏申请了堆内存但没释放而且指针丢了或者存活时间过长又不该这么长。短期运行看不出来长期运行的服务器、嵌入式设备最容易出问题内存占用只涨不降最后 OOM 被内核杀死。有一次我排查一个缓存服务指标上 RSS 每 12 小时涨 20%查了两天才发现某个回调路径里new出来的对象在异常分支忘了delete。这种问题用肉眼基本看不出来得上工具后面第 6 节会细讲。悬挂指针 / 野指针内存释放之后指针里的地址值还在你往里面写数据实际上写的是已经归还给内存分配器的内存可能破坏其他正在使用的对象。更麻烦的是“双重释放”同一块内存被 free 两次glibc 的分配器直接检测到并 abort报double free or corruption。C 里智能指针的出现就是为了根治这几类问题后面展开讲。内存碎片频繁地申请和释放大小不一的内存堆上出现很多“补丁状”的空闲小块导致明明总空闲内存足够却分配不出一块连续的大内存。这像仓库里散落着一堆小板子拼不成一块大板子。长期运行的服务器如果频繁 malloc/free 不同大小的对象碎片问题会越来越明显表现就是 RSS 大了但malloc大块内存依然失败。3.3 为什么堆的分配比栈慢很多当年我学操作系统时有个疑问栈上定义一个局部变量编译后就是一条指令调整栈指针几乎零成本堆上malloc一次却感觉慢了一个量级。这不只是感觉背后有真实原因。malloc 大多数时候不是直接调用系统调用而是先从用户态的内存池glibc 的 arena 等里找一块合适的空闲块。这个过程要加锁多线程下还要避免全局锁竞争、要遍历空闲链表、要切分或合并块可能还要触发brk或者mmap真正向内核申请内存后者意味着进入内核态、切换上下文。基于这个认知你会自然理解不是所有东西都必须上堆如果生命周期和栈匹配放栈上更合适。堆是“放不下/生命周期要跨函数/大小运行时才确定”时的选择不是偷懒时随手一拍的选择。3.4 RAII 与智能指针堆上开发的救命稻草我用 C 写服务端代码这几年最强烈的建议就是能用 RAII 就一定要用 RAII。RAII 的本质是“把资源获取放在对象构造里把资源释放在对象析构里”利用栈对象的确定性析构来管理堆内存。具体到代码层面就是智能指针std::unique_ptr独享所有权std::shared_ptr共享所有权std::weak_ptr观察但不持有。用它们之后函数里即使抛出异常、提前 return析构函数也会保证动释放。写 C 的话没有编译器帮忙只能靠纪律每个 malloc/free 配对、错误分支处理清楚或者用goto cleanup统一收尾。两种思路都行但别只用“记得手动释放”当作策略。3.5 大对象优先走堆但不要频繁申请有一个实操原则是大对象放堆小对象尽量复用。这里的大不是指 100 字节而是指 KB 级以上的缓冲区、结构体、图片帧数据。拿到堆上后并不是每次用都要重新申请。很多性能敏感的系统会用对象池/内存池一次性申请一大块内部自己分配小对象用完放回池子从根本上规避内存碎片和频繁 malloc 的系统调用开销。我自己写过一个小型的固定大小对象池预分配 N 个对象空闲对象串成链表用的时候弹一个用完放回去。实测下来在高频创建的路径上单次分配耗时从几百纳秒降到了几十纳秒碎片问题也没了。这种“池化”思想在 Nginx 的 pool 机制、Redis 的 zmalloc 里都能看到影子。4. 全局/静态存储区生命周期最长的区域多线程的“雷区”4.1 谁住在这个区里全局/静态存储区Data BSS用来放全局变量和 static 修饰的变量。它的生命周期最直白程序加载时分配程序正常退出时才回收。所以它的优点是灵活任何函数都能访问全局的并且始终存在缺点是难管理、难测试、多线程下极易出竞态问题。注意区分两个概念Data 段里放的是“已初始化的全局变量/静态变量”初值在编译时就写进了可执行文件程序加载时直接拷贝进内存BSS 段放的是“未初始化的全局变量/静态变量”C/C 标准要求它们初始化为 0在加载时直接把这整段内存清零不占磁盘上的可执行文件大小。你写一个int g_cnt 0和一个int g_cnt;编译器很可能就把前者放 Data 段值虽然是 0但显式初始化了后者放 BSS。这个细节在计算 ELF 文件大小时非常关键尤其是嵌入式场景——BSS 不占 flash所以大数组尽量别显式初始化为 0省 flash 空间。4.2 static 关键字的“两副面孔”static 在不同位置含义完全不同这也是面试高频题。第一副面孔修饰函数内的局部变量。它让这个变量的生命周期从“函数内一次调用”变成“整个程序运行期”但作用域不变仍然只在这个函数内可见并且只在第一次执行到声明处时初始化一次。典型用途是计数器、缓存、单例实现。void count_calls(void) { static int calls 0; calls; printf(calls: %d\n, calls); }这段代码每次调用都能输出递增的 calls 值。若去掉 static每次进入函数都会重新初始化为 0。原理并不玄普通局部变量在栈上每次调用重新创建static 局部变量在全局/静态存储区程序加载时就存在了函数返回也不会消失。第二副面孔修饰全局变量/函数。它表示“只在当前编译单元内可见”相当于给符号加了文件级 private 属性。大型项目里如果某个全局变量不想被其他 .c 文件直接 extern 引用就加上 static。这在 C 语言里是标准的最佳实践。4.3 跨编译单元初始化顺序的坑C 程序员会遇到的经典雷区是 “static initialization order fiasco”不同 .cpp 文件里的全局/静态对象它们的构造顺序在 C 标准里是未定义的链接顺序决定的但析构顺序是构造顺序的严格逆序。如果一个全局对象的构造函数依赖另一个全局对象已经构造完成程序就可能崩在 main 之前。我自己踩过一次项目里两个全局单例A 在构造时使用 B 的某个接口。某次调整了链接顺序程序启动即崩溃gdb bt 显示在 main 之前的全局构造阶段就出错了。这类问题的稳妥解法是“函数内 static 局部对象”——C11 开始静态局部变量的初始化是线程安全的且只在首次执行到时初始化class Config { public: static Config instance() { static Config cfg; return cfg; } };这叫 Meyers Singleton用“首次调用时初始化”替代了“启动时初始化”从根上规避了初始化顺序问题。4.4 多线程访问全局变量必须有同步全局/静态区所有线程共享这既是优点也是“雷区”。如果多个线程同时读写一个全局计数变量即便只是g_cnt也不是原子的——它会编译成读取、加一、写回三条指令两个线程可能同时读到旧值都加一写回最终结果少加了一次。更简单的说法竞态条件。对策有几种按优先级早知道会共享就尽量不用全局变量改成显式传参或者注入依赖避免不了时用互斥锁std::mutex、pthread_mutex保护如果是计数器这类简单场景用原子变量std::atomic。这里有我的经验规则先考虑能不能设计成无共享再考虑原子操作最后才上锁。锁的上限是性能下限是死锁能不用就不用。5. 常量区和代码区只读只读还是只读5.1 常量区字符串常量为什么不能改常量区.rodataRead-Only Data存放字符串常量、const 修饰的全局变量、以及各种只读字面量。它的只读特性来自操作系统的页权限这一页内存的 PTE 被标记为只读任何写入操作都会触发段错误。经典的教材例子char *p hello; p[0] H; // 错误写入了常量区段错误hello这个字符串字面量在编译期被放到常量区p指向它的首地址。运行时试图写入p[0]就是写入只读内存内核直接送信号终止进程。这里要特别强调一个最常见的面试纠错点char *p hello和char p[] hello看着一样底层完全不同。第一种p是栈上的指针变量指向只读常量区的字符串第二种p[]是栈上的字符数组内容在运行时被拷贝到了栈上是可读写的。所以char p[] hello; p[0] H; // 正确写的是栈上的字符数组我多年面试别人的经验问第一遍“这两种定义有什么区别”很多人能答上来。再追问“哪个可以修改字符串内容”就会有一批人开始犹豫。这个知识点搞混了后面写底层网络协议解析、操作缓冲区时迟早要出事。还有一点C 标准里字符串字面量的类型是char[]也就是理论上“应该能写”但事实上现代编译器都会把字面量放进只读段试图改写属于未定义行为。报错方式可能不是崩溃而是静默无效或者逻辑错乱潜藏危害更大。C 里则是const char[]类型系统层面直接禁止写入这种设计明显更合理。这也是我建议 C 项目开启-Wwrite-strings警告的原因。5.2 const 变量是否一定在常量区不一定C/C 的 const 不是绝对的“放常量区”得看对象类型和创建位置。const 全局变量通常放 .rodata只读应用程序别尝试改。const 局部变量通常就在栈上编译器主要负责编译期检查限制程序员通过它的名字去写它。但如果你用指针绕过检查强转掉 const 再写很可能成功——因为栈页本身是可写的。这是“const 保护是编译期契约不是运行时安全壁垒”。const 成员变量对象里具体在堆还是栈由对象本身决定但构造后不能改。所以 const 的主要价值是让编译器帮你拦截“不该做的修改”而非强制只读。不少新人以为 const 等于“安全只读”这是认知偏差。5.3 代码区可执行指令为什么也不能写代码区Text 段存放函数编译后的机器指令。它也是只读的并且可执行。为了保证程序行为的确定性也为了防止运行时修改指令导致的安全攻击自修改代码操作系统把代码段页权限设置为只读可执行。说个有趣的细节程序的函数名本质上是这个函数的入口地址指向的就是代码区的某个位置。你定义一个函数指针并调用其实是在做“跳转进代码区执行指令”。CPU 会有一个指令指针寄存器PC / RIP按顺序取指、执行、跳转整个过程都在代码区进行。如果 PC 被改成指向数据区比如栈上的数组而恰好那页内存又是可执行的就构成了 ROP 攻击的利用链。现代系统普遍启用 NXNo-eXecute位让数据页不可执行这正是为了防这个。5.4 数据段和代码段的隔离不只是安全还有共享代码区还有一个现实优势它由多个进程共享。你打开 10 个终端跑的是同一个二进制的程序物理内存里代码段只有一份各个进程通过虚拟内存映射到同一块物理页可以节省大量内存。动态库.so的代码段也是同理被多个进程共享。这类优化的副作用在于如果你尝试用调试器修改进程的指令或者程序想在自己的代码段写入信息都会失败原因就是页权限只读。嵌入式开发里如果要在运行期更新程序逻辑通常不会直接改代码段而是用函数指针跳转到 RAM 里的新代码区并且要确保对应 RAM 页被标记为可执行否则照样段错误。6. 实战问题排查当内存分区出问题时6.1 段错误Segmentation Fault的排查定位段错误是所有内存问题里最高发的本质是程序访问了“不可访问”的内存空指针解引用、越界访问、写只读页、跳转到非法地址。定位手段最重要的一步是core dump gdbulimit -c unlimited让崩溃时产生 core 文件。用 gdb 加载程序和 coregdb ./your_program core。输入bt查看崩溃时函数调用栈。栈顶往往就是“出事的函数”。有一次崩溃栈显示程序在memcpy里段错误再看参数发现源地址是一个野指针目标地址也不对。追问下去才发现是某个结构体被 free 之后再没有置空被后续逻辑拿去用了。这类问题除非你能用 ASan/Valgrind 在开发阶段抓到否则线上只能靠克制的指针管理习惯来防。我的习惯是释放完指针之后立刻置 NULL或者保证该指针不再被引用虽然不能根治但能明显缩短排查路径。6.2 栈溢出与堆内存异常的常见症状对照症状可能原因排查手段无限递归后崩溃栈溢出gdb bt 看重复栈帧检查递归终止条件局部大数组崩溃栈溢出把大对象移堆ulimit -s查上限memcpy 崩溃/数据被改越界访问/野指针ASan检查缓冲区大小和 memcpy 长度free 时 abort 提示 corruption双重释放/越界写Valgrind memcheckRSS 只增不减内存泄漏Valgrind leak-check代码 review 找未释放路径malloc 大块失败但内存充足内存碎片对象池/内存池改用 jemalloc 等分配器写入字符串常量崩溃修改常量区改用字符数组开启 -Wwrite-strings这张表建议截图保存或者抄进自己的笔记。遇到内存问题先按症状归类再决定用什么工具而不是每次从零开始猜。6.3 Valgrind 和 AddressSanitizer开发期的“内存照妖镜”线下开发时我强烈建议把内存检测工具纳入常规流程。Valgrindmemcheck能检测非法读写、使用未初始化值、泄漏、双重释放AddressSanitizerASan则是编译期插桩速度和内存开销比 Valgrind 小很多适合 CI 集成。ASan 用法很简单编译时加-fsanitizeaddress -g运行时只要问题路径被触发它会精确定位到是哪一行代码、哪个地址越界、越界发生在多少字节之后。这些工具无法完全替代你对内存分区的理解但它们能把“幽灵问题”转化为“具体位置”大幅降低排查成本。唯一要注意的是ASan 会显著提升内存占用和运行时开销线上千万别开。7. 关于内存分区的深刻教训与后续扩展方向最后说点我自己的体会。很多 C/C 新手以为把语法背熟、把 STL 容器用好就算会写代码了但内存分区的知识决定的是代码能不能在真实环境里稳运行。我见过太多案例本地跑得好好的灰度一上就雪崩写嵌入式固件的同事把一个大临时数组放在栈上跑几天 Random 崩一次谁都猜不到是栈在作怪。这套知识学完之后我建议你去做一件事动手查看一个编译好的 ELF 文件的分段情况。Linux 下执行readelf -S ./your_program你会亲眼看到.text、.data、.bss、.rodata这几个名字再执行size ./your_program能看到各段大小。把这些和本文说的分区对应起来比单纯背概念牢固得多。再往后如果你对性能有更高追求可以深入 glibc malloc 的实现ptmalloc、阅读 Nginx 的 ngx_pool_t 内存池源码、了解 jemalloc 的分区设计它们都是“内存管理”这座大山上的进阶景点。扎实的地基永远是走得远的前提。