“内存分段”这四个字很多人第一次见是在操作系统课本的进程管理章节第二次见是在面试题的内存部分但真正能把它和手头正在跑的进程对上号的人不多。这篇是内存管理系列的第二篇我想把“分段”这件事掰开揉碎讲清楚它当初为什么被发明出来具体怎么工作解决了什么问题最后又为什么被分页抢走了主角位置。内容覆盖段选择子、段描述符表、GDT/LDT、特权检查也会带你用 Linux 下的/proc/pid/maps实际观察进程的内存布局。C 语言开发者、准备面试的系统方向候选人、以及想搞清楚程序为什么偶尔崩在“Segmentation Fault”的人都能从里面拿到点有用的东西。1. 程序跑起来之后内存里到底发生了什么1.1 从物理内存直接使用说起早期的程序对内存的使用非常“直接”——编译出来的地址就是物理地址程序装载到哪个位置就从哪个位置开始执行。单道程序时期这没问题因为整个内存都是你的。但多道程序一出现麻烦立刻来了两个程序同时编译到地址0x0000它们怎么共存要么你让其中一个程序别用到这个地址要么就得在加载时把所有地址改一遍也就是“重定位”。重定位听着简单做起来特别恶心。程序里的绝对跳转、数据访问、函数指针到处存在链接完之后要把这些地址全部修正成新的物理地址机器码长度一变所有后续偏移全乱。这就像你搬家之后要把屋子里每一样东西上的便签都重新写一遍地址工作量巨大且极易出错。于是操作系统设计者开始想能不能让程序不感知物理地址能不能每个程序都以为自己独占整个内存这是“地址空间”这个概念诞生的原始动力。1.2 为什么要逐步引入“段”而不是直接弄一个平坦大空间如果给每个进程一个独立的虚拟地址空间最省事的做法当然是把整块地址空间当作一个连续的整体来分配。可是程序这东西天然就不是一整块。它里面装的内容五花八门只读的机器指令、可修改的全局数据、运行时才增长的堆、不断往下压的栈各有各的属性各有各的方向。这些属性合在一起会互相打架。代码段你肯定不想让程序运行中随便改自己代码写错指针去覆盖指令数据崩溃方式极其诡异只读数据被误写最好直接报错而不是沉默地污染内存。可数据段、堆、栈又必须可写栈还要支持向下增长堆要向上增长。如果所有内容挤在一个平坦空间里权限统一设置那只能选最宽松的“可读可写可执行”安全性和稳定性全没了。如果非要手动划分权限边界代码里得写一大堆“哪块地址范围是只读的、哪块是可写的”这种硬编码换一个程序全部重来。顺着这个问题往下想最自然的方案就是把进程的地址空间按照逻辑功能切成若干块每一块有自己的用途、自己的权限、自己的大小和增长方向。这就是“段”的由来。代码段、数据段、栈段、堆段逻辑上互不相干权限上互相隔离。1.3 先把“分段”和“分页”的边界划清楚面试的时候很多人会把分段和分页搞混这里先做一个总纲式的区分分段面向的是程序的“逻辑结构”段的大小是可变的一个段装的是“一类东西”比如代码或数据分页面向的是物理内存的“管理粒度”页大小固定把内存切成统一大小的格子来分配和回收。可以这么理解分段是把一个人的家按房间来划分卧室、厨房、客厅各自独立面积大小不一分页是把内存切成规格统一的货架格子每一样东西不管实际多大都必须平摊到格子里存放。现代操作系统最终选择了分页作为主管理机制但分段的思路依然深深烙印在进程地址空间的整体结构里。你去看 Linux 下任何一个进程的内存映射那些权限不同的区域本质上就是“段”的现代变体。2. 分段的核心机制段选择子、偏移量与段表2.1 一条指令的地址是怎么拆开的分段模式下一个完整的逻辑地址由两部分组成段选择子Segment Selector和段内偏移量Offset。写法经常是段选择子:偏移量比如jmp 0x08:0x1000这表示“跳转到段选择子 0x08 所指向的那个段然后在这个段内偏移 0x1000 的地方取指令”。段选择子和偏移量是怎么配合的先记住一个关键结论段选择子不是一个地址它更像一个“索引”用来在一张表里查到这个段的详细信息。CPU 拿到段选择子之后会去查“段描述符表”找到对应的段描述符从描述符里读出这个段的基址、大小、权限等信息然后把“段基址 偏移量”相加得到线性地址。这个描述其实隐藏了一个重要细节偏移量才是程序员写的地址而基址是操作系统或 CPU 帮你找到的。程序自身不需要关心这个段到底被放到了哪块物理内存它只要使用自己的偏移量就行了。至于逻辑地址到线性地址再到物理地址的完整翻译中间还可能有分页机制介入但分段这一步做的是“段基址 偏移量”。2.2 段描述符表GDT/LDT 和段描述符字段段描述符表有两张全局描述符表 GDT 和局部描述符表 LDT。GDT 是全局的系统中所有进程共享存放内核段、用户段和各类系统段的描述符LDT 可以按进程划分不过现代操作系统几乎不用了。CPU 拿到段选择子后先看选择子里的 TI 位Table Indicator0 表示 GDT1 表示 LDT决定去查哪张表。一张段描述符在 x86 下固定占 8 个字节里面最重要的字段我整理成了表格字段位宽作用段基址32 位段在线性地址空间中的起始位置段限长20 位段的最大允许偏移配合粒度位使用G 位1 位粒度控制0 表示限长单位是字节1 表示单位是 4KBDPL2 位描述符特权级用于权限检查P 位1 位段是否存在为 0 时访问会触发异常S 位1 位区分普通代码/数据段与系统段TYPE4 位段的类型可读/写/执行、向下增长等AVL1 位软件自定义使用硬件不关心注意段限长只有 20 位直接能表达的最大值只有 1MB但配合 G 位之后如果粒度设为 4KB实际最大限长就是(2^20 - 1) * 4KB ≈ 4GB。这意味着一个段的容量最大可以覆盖整个 32 位线性地址空间。现代操作系统正是利用了这一点把段的基址设为 0、段限长设为整个 4GB 空间从而在地址翻译时让“段基址 偏移量”退化成“偏移量本身”逻辑地址等于线性地址。这就是所谓的平坦内存模型也是 Linux 在现代 CPU 上能“无视”分段、完全靠分页做管理的硬件基础。2.3 保护模式下的特权检查别只盯着地址换算分段不光是地址换算还承担了硬件层面的特权保护。CPU 内部有当前特权级 CPL它通常就等于 CS 段选择子里的低 2 位。段选择子的低 2 位是请求特权级 RPL用来和 CPL 一起参与访问校验。段描述符里有 DPL表示这个段要求的最低权限。访问普通数据段时的规则可以简化成一句话max(CPL, RPL) DPL否则触发保护异常。也就是说用户态程序CPL3不能直接访问内核段DPL0它没有这个资格。这种检查是在硬件层面强制完成的比软件里你自己判断要可靠得多因为你无法绕过它。这套特权检查机制在今天依然在发挥余热只不过重点从“段与段之间的隔离”转移到了“分页层面的用户态/内核态隔离”。但最初这种按段做权限隔离的思想直接启发了后来分页页表项的 U/S 位用户/超级visor 访问权限。可以这样理解分段时代的权限是给“一整块逻辑区域”加的锁分页时代则是给“每一页”加的锁后者粒度细得多。2.4 C 语言里的“段”和硬件段不是一回事C 语言开发者在编译输出里经常听到“代码段、数据段、BSS 段、堆、栈”这些词。这里有个特别容易混淆的点这些真的是“段”吗字面意义上确实叫段但它是链接器眼中的“节区”来自编译器生成的.text、.data、.bss、.rodata等 section经过链接之后被合并成可执行文件里的程序头加载时由操作系统映射到进程的虚拟地址空间里。而硬件段是指 CPU 分段机制中的代码段、数据段、栈段由段寄存器 CS、DS、SS 来引用。在现代 Linux 中这两类“段”已经没有一一对应关系了——所有用户态段的基址都是 0整个进程空间是平坦的大家共享同一条线性地址空间。你平时说“这个变量放在数据段”严格来说是“这个变量位于可执行文件的 data section加载后被映射到进程地址空间的某个可写私有区域”而硬件段环节其实没怎么参与。不过理解编译产物里的这些 section 对排查问题依然极其重要。全局变量和静态变量放在数据段或 BSS 段生命周期跟着进程走局部变量在栈上函数结束就失效字符串常量放在只读数据段你往里写就会触发段错误。这些都是 C 语言内存模型的基本盘。3. 分段解决的真问题隔离、共享与权限3.1 进程隔离你的 0x1000 和我的 0x1000在没有地址翻译的年代两个进程如果都用了0x1000这个物理地址那就必须有一方让路。有了分段之后CPU 在取指令和访问数据时会进行“段基址 偏移量”的翻译操作系统可以给进程 A 的代码段设置基址为0x100000给进程 B 的代码段设置基址为0x200000两边程序里的“逻辑地址 0x1000”实际访问的是不同的物理内存区域。这就实现了最核心的收益每个进程都觉得自己独占了一块连续的内存空间不需要关心物理内存里其他进程的位置。之后如果把分段和分页结合进程看到的连续逻辑空间还能被映射到物理上不连续的页框里隔离效果更彻底。进程之间想访问彼此的数据必须走操作系统提供的进程间通信机制而不是直接拿地址去读这就是分段时代就奠定的安全边界。3.2 共享库多个进程共享一份代码段程序里大量代码其实是公共的比如printf、malloc、memcpy这些 libc 函数。如果每个进程都把自己那份 libc 代码加载到内存里浪费极其严重二千个进程就是二千份重复代码。分段模型下共享的实现非常直观把同一个物理区域映射成多个进程的“同一个逻辑段”或者映射到不同进程的不同段基址上但指向同一块物理内存。操作系统的做法是进程地址空间里有一块区域专门用来映射共享库多个进程的这块区域都指向同一份 libc 物理页。这样既节省物理内存又保住了分页时代才有的“写时复制”优势多个进程共享同一份只读代码没问题可如果有谁要写数据分页机制会在物理页真正被修改时才复制一份副本。这种“共享一个库的代码段”的能力在现代系统里已经被文件映射机制完全接管了但如果你回到分段模型里看设计初衷思路是一脉相承的把逻辑上相同的内容聚成一段让多个进程共用。3.3 堆和栈分离除了增长方向还有越界检测写 C 语言的人都知道堆在低地址、栈在高地址堆向上增长栈向下增长。为什么非要一个向上一个向下各占一头的结构因为这样两个区域从两端向中间生长能最有效地利用地址空间理论上可以撞到中间的共享库映射区才会撞车。更深一层分段模型给了堆和栈各自独立的段界限硬件会检查每次内存访问是否越过了本段的限长越界直接触发异常。栈向下增长时如果压栈压过了段的底部边界CPU 就能立刻发现并抛出栈溢出异常不需要等实际破坏到别的数据才察觉。现在的操作系统虽然主要靠分页管理但是进程地址空间里栈的底部仍然会放一个“保护页”一旦访问越过边界就触发段错误。这种“给特定区域设边界”的想法正是从分段模型里继承下来的。4. 一个可实操的观察实验用 /proc/ /maps 看进程内存布局4.1 准备一个能“定住”的程序理论说太多容易飘我建议你亲手做一次观察。Linux 的/proc/pid/maps文件会列出指定进程当前完整的虚拟内存映射每一行表示一个连续映射区域里面能看到代码段、数据段、堆、栈、共享库、vDSO 等。为了让程序不要瞬间跑完我加了一个等待输入的调用让你有时间去查看。#include stdio.h #include stdlib.h #include unistd.h int global_data 42; int global_bss; const char *rodata_str read only string; int main(void) { static int local_static 7; int local_var 1; void *p1 malloc(4096); void *p2 malloc(4096); printf(PID: %d\n, getpid()); printf(main (code/text): %p\n, (void *)main); printf(global_data (.data): %p\n, (void *)global_data); printf(global_bss (.bss): %p\n, (void *)global_bss); printf(rodata_str (.rodata): %p\n, (void *)rodata_str); printf(local_static (.data): %p\n, (void *)local_static); printf(local_var (stack): %p\n, (void *)local_var); printf(heap p1: %p\n, p1); printf(heap p2: %p\n, p2); printf(printf (libc): %p\n, (void *)printf); getchar(); // 暂停等你去另一个终端看 /proc/pid/maps free(p1); free(p2); return 0; }编译和运行很简单gcc -O0 -o memseg memseg.c ./memseg程序启动后会打印出 PID 和所有关键地址。你先把 PID 记下来接着打开另一个终端窗口执行cat /proc/PID/maps如果你嫌 PID 太麻烦也可以直接在程序里加一个system(cat /proc/self/maps)但你手动查看更能体会整个过程。4.2 手把手解析 maps 输出的每一列/proc/PID/maps的每一行格式如下地址范围 权限 偏移 设备 inode 路径 00400000-00401000 r-xp 00000000 08:01 593721 /home/user/memseg 00600000-00601000 r--p 00000000 08:01 593721 /home/user/memseg 00601000-00602000 rw-p 00001000 08:01 593721 /home/user/memseg 7f8b4a2c0000-7f8b4a4a1000 r-xp 00000000 08:01 1048577 /usr/lib/x86_64-linux-gnu/libc.so.6 7f8b4a6a0000-7f8b4a6a1000 r--p 001a0000 08:01 1048577 /usr/lib/x86_64-linux-gnu/libc.so.6 7f8b4a6a1000-7f8b4a6a4000 rw-p 001a1000 08:01 1048577 /usr/lib/x86_64-linux-gnu/libc.so.6 7f8b4b8d9000-7f8b4b8fa000 rw-p 00000000 00:00 0 [heap] 7ffcd0a00000-7ffcd0c00000 rw-p 00000000 00:00 0 [stack]第一列是这段映射在虚拟地址空间里的范围第二列是权限位r 可读、w 可写、x 可执行、p 是私有映射、s 是共享映射。第三列是文件偏移量对文件映射而言指示这段映射对应文件里的哪个位置匿名映射通常为 0。第四、五列是设备号和 inode匿名映射为 0。最后一列是映射背后的文件路径见不到路径的就是系统内部区域比如堆、栈、vDSO。对照我的程序main的地址一定落在带r-xp权限的可执行映射里那是代码段。global_data和local_static在可写的私有映射区里对应.data段。global_bss也在可写私有映射区通常在.data之后。rodata_str指向的字符串字面量通常在只读映射区现代编译器和加载器经常把它和只读数据放在r--p段。local_var的地址落在[stack]范围内而且你多跑几次会发现它每次都变这是 ASLR 的作用。p1、p2落在[heap]附近第一次 malloc 可能会先向上扩展堆所以启动初期看到的堆结尾地址比p1低也是正常的。实际输出会因为系统版本和 ASLR 而略有不同但相对位置几乎不变低地址是可执行文件往上走是共享库再往上是堆栈在接近地址空间顶部的位置。4.3 在 macOS 和 Windows 下的对应观察方式经常有人问我在 macOS 或 Windows 上能不能也这样看答案是可以只是工具不同。macOS 上vmmap PID是最接近/proc/pid/maps的命令vmmap -summary PID还能给出各类内存的汇总统计。macOS 的地址空间布局没有 Linux 那种严格的低地址可执行文件、顶部栈的模式但你能看到__TEXT、__DATA、MALLOC、STACK等区段概念上一一对应。Windows 上最常用的工具是 Sysinternals 的 VMMap它能按类型展示进程内存区域包括 Image、Private、Heap、Stack、Mapped File 等。相比之下Linux 的 maps 文件最简单直接这也是我建议初学者从 Linux 入手观察内存的最主要原因——没有 GUI 可依赖更容易看到本质。5. 分段的短板外部碎片、段长限制与替换5.1 可变大小分配带来的外部碎片分段最大的结构性缺陷是段的大小不统一随之而来的就是“外部碎片”。假设物理内存装了一个 200KB 的进程和一个 300KB 的进程剩下一个 500KB 的空洞。这时候又来一个 400KB 的新进程你会发现内存总量明明够却因为空洞被拆得零零碎碎一块 400KB 连续区域都凑不出来。这就像停车场只划了大小各异的大车位车停得七零八落之后地面空着一堆小缝但再也停不进一辆大车。解决方案是内存紧凑把已分配的段全部搬到一起腾出一个连续大块但进程 swap 和重新定位的成本极高运行中的程序不能随便动它的基址紧凑操作通常意味着极大的停顿。分段的外部碎片问题在需要频繁加载、卸载进程的系统里尤其致命。一个长期运行的服务器内存被分割成大量不连续的小洞可用率持续下降系统性能劣化明显。这促使设计者们思考如果分配单元是固定大小的是不是就没这么痛苦了5.2 为什么分页最终胜出分页的思路是把物理内存切成一页一页的固定大小单元在常见的页表配置下通常是 4KB。进程的虚拟地址空间也被切成同样大小的页通过页表把虚拟页映射到物理页框。页与页之间不需要连续物理内存里的任何空闲页框都可以分配给任何虚拟页。这样带来的直接好处是分配内存时只需要找出足够的“任意”页框而不是找足够大的连续空洞外部碎片基本消失了。碎片最多发生在页内部也就是一个进程最后一页用不满产生所谓“内部碎片”但一个页面最大浪费也只有 4KB 左右比段那种“凑不出大块连续内存”的灾难要好处理得多。分页还带来一个极具价值的副产品按需调页。因为映射粒度足够小操作系统不需要把一个进程的全部代码和数据一次性加载到物理内存可以等 CPU 真正访问到某个虚拟页时才去磁盘读取通过缺页中断完成加载。段的大小通常较大按段换入换出会造成大量无效 I/O而按页调度就灵活多了。上面这些优势叠加在一起让分页成为现代操作系统内存管理的绝对主流。Linux 在 32 位时代后期已经完成了向分页的完全迁移而 x86 硬件上虽然依然保留分段机制内核却用平坦模型把它“架空”了。5.3 FS/GS 段寄存器的现代用途线程局部存储说分段在现代系统中“彻底退场”并不准确。在 64 位长模式下绝大部分段寄存器的基址被强制为 0CPU 不再用它们做地址翻译但FS和GS这两个段寄存器是例外它们仍然允许通过模型专属寄存器MSR设置非零基址。线程局部存储就是靠这个特性实现的。每个线程需要一组独立的数据比如errno、线程栈的某些元数据如果全局数据是共享的线程 A 改了errno就会污染线程 B 的值。glibc 的做法是把每个线程的 TLS 区域放在线程栈附近然后把FS段基址设置为属于当前线程的 TLS 区域基址线程内访问“基于 FS 的变量”时就自动定位到当前线程自己的那份数据。线程切换时内核或运行时只要换掉FS的基址所有基于 FS 的访问就落到新线程的 TLS 区域里。现代系统里分段本来最核心的“基址 界限”翻译作用已经被分页取代但它留下了两个遗产一是按逻辑分组、按权限隔离的思维二是 FS/GS 这种针对特殊数据段的硬件支持。去深挖 TLS 和getcontext这类底层机制时你会发现硬件段的历史痕迹依然清晰可见。6. 内存布局优化从分段思想讲到 Julia 性能调优6.1 分配器也在“分段”size-class 思想分段的思想其实不止存在于 CPU 硬件里现代内存分配器同样在用按逻辑分组、按大小分级的方案对抗碎片化。glibc 的 malloc、Google 的 tcmalloc、Facebook 的 jemalloc都采用了“size-class”思路把请求大小按区间分组比如 8 字节、16 字节、32 字节……同一分组的内存块放在同一个空闲列表里管理。这种做法和分段的直观联系是它把对象按“尺寸”这种逻辑属性分成不同集合每个集合拥有独立的空闲链表把对象按使用逻辑分组后小块不和大块混在一起碎片率显著降低分配释放的效率也高很多。大对象达到一定阈值之后malloc 会直接走mmap从内核映射一整块独立区域释放时直接归还给内核这也是现代内存管理的经典套路不同特性的对象分组管理。6.2 Julia 性能优化里的“段”思维类型稳定与数据布局Julia 是很重视性能的现代语言它的优化思路里内存布局的地位比大多数人想象中高得多。Julia 文档里最著名的警告之一就是要保证函数类型稳定否则变量会被装箱成抽象类型的盒装对象产生一堆零散堆分配GC 压力和缓存损耗同时上来性能断崖式下跌。让你定义一个粒子结构struct Particle x::Float64 y::Float64 vx::Float64 vy::Float64 end particles [Particle(rand(), rand(), rand(), rand()) for _ in 1:100_000]这是一个“结构体数组”AoS 的写法每个粒子是连续对象遍历时访问particles[i].x实际上是在每个 32 字节对象里跳过 24 个字节取 8 个字节CPU 缓存利用率不理想。如果改成“数组结构体”SoAstruct ParticleSystem xs::Vector{Float64} ys::Vector{Float64} vxs::Vector{Float64} vys::Vector{Float64} end四个数组分别是连续内存块遍历xs[i]时就是在连续地址上顺序读每次缓存行都能装下八到十六个有效数据性能通常会有明显提升。这背后用的还是分段思维把属性相同的元素聚合到同一块连续空间让访问模式与内存布局对齐。6.3 优化之前先“看见”内存分布不少人在优化内存布局时容易凭感觉下手改半天代码发现性能没变甚至更差。我的经验是优化之前先做个量化观察用 perf 看 cache miss、用 heaptrack 或 valgrind 看堆分配热点、用pahole看结构体对齐和填充。比如你怀疑某个循环慢是因为缓存那就先用 perf stat 看cache-misses比例确认是缓存问题再动手改布局。如果再往底层一点写 C 的人可以用gdb的info files查看程序的段映射或者用readelf -l /bin/ls看 ELF 文件里的程序头表。这些工具都能让你直观看到“段”在可执行文件和进程空间里的真实存在方式。没有数据支撑的优化大概率只是自我安慰。我个人的体会是内存管理最折磨人的地方不是概念多而是理论归理论、现象归现象。很多朋友遇到Segmentation Fault就以为是“段”出了问题可在 Linux 的平坦模型下段早就没有存在感了真正出问题的要么是访问了未映射区域要么是越过权限访问要么是越界写坏了堆内存。建议你有空把本机随便一个服务的/proc/pid/maps拉出来看看对照着代码里的变量地址把每一行映射读过去。见过一次真实的内存布局很多概念就自动串起来了之后再谈优化也好、排查崩溃也好心里都有了底。 
长河君 · 2026/10/4 2:35:20 · 阅读 1.2k 内存分段机制全解析：从段选择子到进程内存布局
“内存分段”这四个字很多人第一次见是在操作系统课本的进程管理章节第二次见是在面试题的内存部分但真正能把它和手头正在跑的进程对上号的人不多。这篇是内存管理系列的第二篇我想把“分段”这件事掰开揉碎讲清楚它当初为什么被发明出来具体怎么工作解决了什么问题最后又为什么被分页抢走了主角位置。内容覆盖段选择子、段描述符表、GDT/LDT、特权检查也会带你用 Linux 下的/proc/pid/maps实际观察进程的内存布局。C 语言开发者、准备面试的系统方向候选人、以及想搞清楚程序为什么偶尔崩在“Segmentation Fault”的人都能从里面拿到点有用的东西。1. 程序跑起来之后内存里到底发生了什么1.1 从物理内存直接使用说起早期的程序对内存的使用非常“直接”——编译出来的地址就是物理地址程序装载到哪个位置就从哪个位置开始执行。单道程序时期这没问题因为整个内存都是你的。但多道程序一出现麻烦立刻来了两个程序同时编译到地址0x0000它们怎么共存要么你让其中一个程序别用到这个地址要么就得在加载时把所有地址改一遍也就是“重定位”。重定位听着简单做起来特别恶心。程序里的绝对跳转、数据访问、函数指针到处存在链接完之后要把这些地址全部修正成新的物理地址机器码长度一变所有后续偏移全乱。这就像你搬家之后要把屋子里每一样东西上的便签都重新写一遍地址工作量巨大且极易出错。于是操作系统设计者开始想能不能让程序不感知物理地址能不能每个程序都以为自己独占整个内存这是“地址空间”这个概念诞生的原始动力。1.2 为什么要逐步引入“段”而不是直接弄一个平坦大空间如果给每个进程一个独立的虚拟地址空间最省事的做法当然是把整块地址空间当作一个连续的整体来分配。可是程序这东西天然就不是一整块。它里面装的内容五花八门只读的机器指令、可修改的全局数据、运行时才增长的堆、不断往下压的栈各有各的属性各有各的方向。这些属性合在一起会互相打架。代码段你肯定不想让程序运行中随便改自己代码写错指针去覆盖指令数据崩溃方式极其诡异只读数据被误写最好直接报错而不是沉默地污染内存。可数据段、堆、栈又必须可写栈还要支持向下增长堆要向上增长。如果所有内容挤在一个平坦空间里权限统一设置那只能选最宽松的“可读可写可执行”安全性和稳定性全没了。如果非要手动划分权限边界代码里得写一大堆“哪块地址范围是只读的、哪块是可写的”这种硬编码换一个程序全部重来。顺着这个问题往下想最自然的方案就是把进程的地址空间按照逻辑功能切成若干块每一块有自己的用途、自己的权限、自己的大小和增长方向。这就是“段”的由来。代码段、数据段、栈段、堆段逻辑上互不相干权限上互相隔离。1.3 先把“分段”和“分页”的边界划清楚面试的时候很多人会把分段和分页搞混这里先做一个总纲式的区分分段面向的是程序的“逻辑结构”段的大小是可变的一个段装的是“一类东西”比如代码或数据分页面向的是物理内存的“管理粒度”页大小固定把内存切成统一大小的格子来分配和回收。可以这么理解分段是把一个人的家按房间来划分卧室、厨房、客厅各自独立面积大小不一分页是把内存切成规格统一的货架格子每一样东西不管实际多大都必须平摊到格子里存放。现代操作系统最终选择了分页作为主管理机制但分段的思路依然深深烙印在进程地址空间的整体结构里。你去看 Linux 下任何一个进程的内存映射那些权限不同的区域本质上就是“段”的现代变体。2. 分段的核心机制段选择子、偏移量与段表2.1 一条指令的地址是怎么拆开的分段模式下一个完整的逻辑地址由两部分组成段选择子Segment Selector和段内偏移量Offset。写法经常是段选择子:偏移量比如jmp 0x08:0x1000这表示“跳转到段选择子 0x08 所指向的那个段然后在这个段内偏移 0x1000 的地方取指令”。段选择子和偏移量是怎么配合的先记住一个关键结论段选择子不是一个地址它更像一个“索引”用来在一张表里查到这个段的详细信息。CPU 拿到段选择子之后会去查“段描述符表”找到对应的段描述符从描述符里读出这个段的基址、大小、权限等信息然后把“段基址 偏移量”相加得到线性地址。这个描述其实隐藏了一个重要细节偏移量才是程序员写的地址而基址是操作系统或 CPU 帮你找到的。程序自身不需要关心这个段到底被放到了哪块物理内存它只要使用自己的偏移量就行了。至于逻辑地址到线性地址再到物理地址的完整翻译中间还可能有分页机制介入但分段这一步做的是“段基址 偏移量”。2.2 段描述符表GDT/LDT 和段描述符字段段描述符表有两张全局描述符表 GDT 和局部描述符表 LDT。GDT 是全局的系统中所有进程共享存放内核段、用户段和各类系统段的描述符LDT 可以按进程划分不过现代操作系统几乎不用了。CPU 拿到段选择子后先看选择子里的 TI 位Table Indicator0 表示 GDT1 表示 LDT决定去查哪张表。一张段描述符在 x86 下固定占 8 个字节里面最重要的字段我整理成了表格字段位宽作用段基址32 位段在线性地址空间中的起始位置段限长20 位段的最大允许偏移配合粒度位使用G 位1 位粒度控制0 表示限长单位是字节1 表示单位是 4KBDPL2 位描述符特权级用于权限检查P 位1 位段是否存在为 0 时访问会触发异常S 位1 位区分普通代码/数据段与系统段TYPE4 位段的类型可读/写/执行、向下增长等AVL1 位软件自定义使用硬件不关心注意段限长只有 20 位直接能表达的最大值只有 1MB但配合 G 位之后如果粒度设为 4KB实际最大限长就是(2^20 - 1) * 4KB ≈ 4GB。这意味着一个段的容量最大可以覆盖整个 32 位线性地址空间。现代操作系统正是利用了这一点把段的基址设为 0、段限长设为整个 4GB 空间从而在地址翻译时让“段基址 偏移量”退化成“偏移量本身”逻辑地址等于线性地址。这就是所谓的平坦内存模型也是 Linux 在现代 CPU 上能“无视”分段、完全靠分页做管理的硬件基础。2.3 保护模式下的特权检查别只盯着地址换算分段不光是地址换算还承担了硬件层面的特权保护。CPU 内部有当前特权级 CPL它通常就等于 CS 段选择子里的低 2 位。段选择子的低 2 位是请求特权级 RPL用来和 CPL 一起参与访问校验。段描述符里有 DPL表示这个段要求的最低权限。访问普通数据段时的规则可以简化成一句话max(CPL, RPL) DPL否则触发保护异常。也就是说用户态程序CPL3不能直接访问内核段DPL0它没有这个资格。这种检查是在硬件层面强制完成的比软件里你自己判断要可靠得多因为你无法绕过它。这套特权检查机制在今天依然在发挥余热只不过重点从“段与段之间的隔离”转移到了“分页层面的用户态/内核态隔离”。但最初这种按段做权限隔离的思想直接启发了后来分页页表项的 U/S 位用户/超级visor 访问权限。可以这样理解分段时代的权限是给“一整块逻辑区域”加的锁分页时代则是给“每一页”加的锁后者粒度细得多。2.4 C 语言里的“段”和硬件段不是一回事C 语言开发者在编译输出里经常听到“代码段、数据段、BSS 段、堆、栈”这些词。这里有个特别容易混淆的点这些真的是“段”吗字面意义上确实叫段但它是链接器眼中的“节区”来自编译器生成的.text、.data、.bss、.rodata等 section经过链接之后被合并成可执行文件里的程序头加载时由操作系统映射到进程的虚拟地址空间里。而硬件段是指 CPU 分段机制中的代码段、数据段、栈段由段寄存器 CS、DS、SS 来引用。在现代 Linux 中这两类“段”已经没有一一对应关系了——所有用户态段的基址都是 0整个进程空间是平坦的大家共享同一条线性地址空间。你平时说“这个变量放在数据段”严格来说是“这个变量位于可执行文件的 data section加载后被映射到进程地址空间的某个可写私有区域”而硬件段环节其实没怎么参与。不过理解编译产物里的这些 section 对排查问题依然极其重要。全局变量和静态变量放在数据段或 BSS 段生命周期跟着进程走局部变量在栈上函数结束就失效字符串常量放在只读数据段你往里写就会触发段错误。这些都是 C 语言内存模型的基本盘。3. 分段解决的真问题隔离、共享与权限3.1 进程隔离你的 0x1000 和我的 0x1000在没有地址翻译的年代两个进程如果都用了0x1000这个物理地址那就必须有一方让路。有了分段之后CPU 在取指令和访问数据时会进行“段基址 偏移量”的翻译操作系统可以给进程 A 的代码段设置基址为0x100000给进程 B 的代码段设置基址为0x200000两边程序里的“逻辑地址 0x1000”实际访问的是不同的物理内存区域。这就实现了最核心的收益每个进程都觉得自己独占了一块连续的内存空间不需要关心物理内存里其他进程的位置。之后如果把分段和分页结合进程看到的连续逻辑空间还能被映射到物理上不连续的页框里隔离效果更彻底。进程之间想访问彼此的数据必须走操作系统提供的进程间通信机制而不是直接拿地址去读这就是分段时代就奠定的安全边界。3.2 共享库多个进程共享一份代码段程序里大量代码其实是公共的比如printf、malloc、memcpy这些 libc 函数。如果每个进程都把自己那份 libc 代码加载到内存里浪费极其严重二千个进程就是二千份重复代码。分段模型下共享的实现非常直观把同一个物理区域映射成多个进程的“同一个逻辑段”或者映射到不同进程的不同段基址上但指向同一块物理内存。操作系统的做法是进程地址空间里有一块区域专门用来映射共享库多个进程的这块区域都指向同一份 libc 物理页。这样既节省物理内存又保住了分页时代才有的“写时复制”优势多个进程共享同一份只读代码没问题可如果有谁要写数据分页机制会在物理页真正被修改时才复制一份副本。这种“共享一个库的代码段”的能力在现代系统里已经被文件映射机制完全接管了但如果你回到分段模型里看设计初衷思路是一脉相承的把逻辑上相同的内容聚成一段让多个进程共用。3.3 堆和栈分离除了增长方向还有越界检测写 C 语言的人都知道堆在低地址、栈在高地址堆向上增长栈向下增长。为什么非要一个向上一个向下各占一头的结构因为这样两个区域从两端向中间生长能最有效地利用地址空间理论上可以撞到中间的共享库映射区才会撞车。更深一层分段模型给了堆和栈各自独立的段界限硬件会检查每次内存访问是否越过了本段的限长越界直接触发异常。栈向下增长时如果压栈压过了段的底部边界CPU 就能立刻发现并抛出栈溢出异常不需要等实际破坏到别的数据才察觉。现在的操作系统虽然主要靠分页管理但是进程地址空间里栈的底部仍然会放一个“保护页”一旦访问越过边界就触发段错误。这种“给特定区域设边界”的想法正是从分段模型里继承下来的。4. 一个可实操的观察实验用 /proc/ /maps 看进程内存布局4.1 准备一个能“定住”的程序理论说太多容易飘我建议你亲手做一次观察。Linux 的/proc/pid/maps文件会列出指定进程当前完整的虚拟内存映射每一行表示一个连续映射区域里面能看到代码段、数据段、堆、栈、共享库、vDSO 等。为了让程序不要瞬间跑完我加了一个等待输入的调用让你有时间去查看。#include stdio.h #include stdlib.h #include unistd.h int global_data 42; int global_bss; const char *rodata_str read only string; int main(void) { static int local_static 7; int local_var 1; void *p1 malloc(4096); void *p2 malloc(4096); printf(PID: %d\n, getpid()); printf(main (code/text): %p\n, (void *)main); printf(global_data (.data): %p\n, (void *)global_data); printf(global_bss (.bss): %p\n, (void *)global_bss); printf(rodata_str (.rodata): %p\n, (void *)rodata_str); printf(local_static (.data): %p\n, (void *)local_static); printf(local_var (stack): %p\n, (void *)local_var); printf(heap p1: %p\n, p1); printf(heap p2: %p\n, p2); printf(printf (libc): %p\n, (void *)printf); getchar(); // 暂停等你去另一个终端看 /proc/pid/maps free(p1); free(p2); return 0; }编译和运行很简单gcc -O0 -o memseg memseg.c ./memseg程序启动后会打印出 PID 和所有关键地址。你先把 PID 记下来接着打开另一个终端窗口执行cat /proc/PID/maps如果你嫌 PID 太麻烦也可以直接在程序里加一个system(cat /proc/self/maps)但你手动查看更能体会整个过程。4.2 手把手解析 maps 输出的每一列/proc/PID/maps的每一行格式如下地址范围 权限 偏移 设备 inode 路径 00400000-00401000 r-xp 00000000 08:01 593721 /home/user/memseg 00600000-00601000 r--p 00000000 08:01 593721 /home/user/memseg 00601000-00602000 rw-p 00001000 08:01 593721 /home/user/memseg 7f8b4a2c0000-7f8b4a4a1000 r-xp 00000000 08:01 1048577 /usr/lib/x86_64-linux-gnu/libc.so.6 7f8b4a6a0000-7f8b4a6a1000 r--p 001a0000 08:01 1048577 /usr/lib/x86_64-linux-gnu/libc.so.6 7f8b4a6a1000-7f8b4a6a4000 rw-p 001a1000 08:01 1048577 /usr/lib/x86_64-linux-gnu/libc.so.6 7f8b4b8d9000-7f8b4b8fa000 rw-p 00000000 00:00 0 [heap] 7ffcd0a00000-7ffcd0c00000 rw-p 00000000 00:00 0 [stack]第一列是这段映射在虚拟地址空间里的范围第二列是权限位r 可读、w 可写、x 可执行、p 是私有映射、s 是共享映射。第三列是文件偏移量对文件映射而言指示这段映射对应文件里的哪个位置匿名映射通常为 0。第四、五列是设备号和 inode匿名映射为 0。最后一列是映射背后的文件路径见不到路径的就是系统内部区域比如堆、栈、vDSO。对照我的程序main的地址一定落在带r-xp权限的可执行映射里那是代码段。global_data和local_static在可写的私有映射区里对应.data段。global_bss也在可写私有映射区通常在.data之后。rodata_str指向的字符串字面量通常在只读映射区现代编译器和加载器经常把它和只读数据放在r--p段。local_var的地址落在[stack]范围内而且你多跑几次会发现它每次都变这是 ASLR 的作用。p1、p2落在[heap]附近第一次 malloc 可能会先向上扩展堆所以启动初期看到的堆结尾地址比p1低也是正常的。实际输出会因为系统版本和 ASLR 而略有不同但相对位置几乎不变低地址是可执行文件往上走是共享库再往上是堆栈在接近地址空间顶部的位置。4.3 在 macOS 和 Windows 下的对应观察方式经常有人问我在 macOS 或 Windows 上能不能也这样看答案是可以只是工具不同。macOS 上vmmap PID是最接近/proc/pid/maps的命令vmmap -summary PID还能给出各类内存的汇总统计。macOS 的地址空间布局没有 Linux 那种严格的低地址可执行文件、顶部栈的模式但你能看到__TEXT、__DATA、MALLOC、STACK等区段概念上一一对应。Windows 上最常用的工具是 Sysinternals 的 VMMap它能按类型展示进程内存区域包括 Image、Private、Heap、Stack、Mapped File 等。相比之下Linux 的 maps 文件最简单直接这也是我建议初学者从 Linux 入手观察内存的最主要原因——没有 GUI 可依赖更容易看到本质。5. 分段的短板外部碎片、段长限制与替换5.1 可变大小分配带来的外部碎片分段最大的结构性缺陷是段的大小不统一随之而来的就是“外部碎片”。假设物理内存装了一个 200KB 的进程和一个 300KB 的进程剩下一个 500KB 的空洞。这时候又来一个 400KB 的新进程你会发现内存总量明明够却因为空洞被拆得零零碎碎一块 400KB 连续区域都凑不出来。这就像停车场只划了大小各异的大车位车停得七零八落之后地面空着一堆小缝但再也停不进一辆大车。解决方案是内存紧凑把已分配的段全部搬到一起腾出一个连续大块但进程 swap 和重新定位的成本极高运行中的程序不能随便动它的基址紧凑操作通常意味着极大的停顿。分段的外部碎片问题在需要频繁加载、卸载进程的系统里尤其致命。一个长期运行的服务器内存被分割成大量不连续的小洞可用率持续下降系统性能劣化明显。这促使设计者们思考如果分配单元是固定大小的是不是就没这么痛苦了5.2 为什么分页最终胜出分页的思路是把物理内存切成一页一页的固定大小单元在常见的页表配置下通常是 4KB。进程的虚拟地址空间也被切成同样大小的页通过页表把虚拟页映射到物理页框。页与页之间不需要连续物理内存里的任何空闲页框都可以分配给任何虚拟页。这样带来的直接好处是分配内存时只需要找出足够的“任意”页框而不是找足够大的连续空洞外部碎片基本消失了。碎片最多发生在页内部也就是一个进程最后一页用不满产生所谓“内部碎片”但一个页面最大浪费也只有 4KB 左右比段那种“凑不出大块连续内存”的灾难要好处理得多。分页还带来一个极具价值的副产品按需调页。因为映射粒度足够小操作系统不需要把一个进程的全部代码和数据一次性加载到物理内存可以等 CPU 真正访问到某个虚拟页时才去磁盘读取通过缺页中断完成加载。段的大小通常较大按段换入换出会造成大量无效 I/O而按页调度就灵活多了。上面这些优势叠加在一起让分页成为现代操作系统内存管理的绝对主流。Linux 在 32 位时代后期已经完成了向分页的完全迁移而 x86 硬件上虽然依然保留分段机制内核却用平坦模型把它“架空”了。5.3 FS/GS 段寄存器的现代用途线程局部存储说分段在现代系统中“彻底退场”并不准确。在 64 位长模式下绝大部分段寄存器的基址被强制为 0CPU 不再用它们做地址翻译但FS和GS这两个段寄存器是例外它们仍然允许通过模型专属寄存器MSR设置非零基址。线程局部存储就是靠这个特性实现的。每个线程需要一组独立的数据比如errno、线程栈的某些元数据如果全局数据是共享的线程 A 改了errno就会污染线程 B 的值。glibc 的做法是把每个线程的 TLS 区域放在线程栈附近然后把FS段基址设置为属于当前线程的 TLS 区域基址线程内访问“基于 FS 的变量”时就自动定位到当前线程自己的那份数据。线程切换时内核或运行时只要换掉FS的基址所有基于 FS 的访问就落到新线程的 TLS 区域里。现代系统里分段本来最核心的“基址 界限”翻译作用已经被分页取代但它留下了两个遗产一是按逻辑分组、按权限隔离的思维二是 FS/GS 这种针对特殊数据段的硬件支持。去深挖 TLS 和getcontext这类底层机制时你会发现硬件段的历史痕迹依然清晰可见。6. 内存布局优化从分段思想讲到 Julia 性能调优6.1 分配器也在“分段”size-class 思想分段的思想其实不止存在于 CPU 硬件里现代内存分配器同样在用按逻辑分组、按大小分级的方案对抗碎片化。glibc 的 malloc、Google 的 tcmalloc、Facebook 的 jemalloc都采用了“size-class”思路把请求大小按区间分组比如 8 字节、16 字节、32 字节……同一分组的内存块放在同一个空闲列表里管理。这种做法和分段的直观联系是它把对象按“尺寸”这种逻辑属性分成不同集合每个集合拥有独立的空闲链表把对象按使用逻辑分组后小块不和大块混在一起碎片率显著降低分配释放的效率也高很多。大对象达到一定阈值之后malloc 会直接走mmap从内核映射一整块独立区域释放时直接归还给内核这也是现代内存管理的经典套路不同特性的对象分组管理。6.2 Julia 性能优化里的“段”思维类型稳定与数据布局Julia 是很重视性能的现代语言它的优化思路里内存布局的地位比大多数人想象中高得多。Julia 文档里最著名的警告之一就是要保证函数类型稳定否则变量会被装箱成抽象类型的盒装对象产生一堆零散堆分配GC 压力和缓存损耗同时上来性能断崖式下跌。让你定义一个粒子结构struct Particle x::Float64 y::Float64 vx::Float64 vy::Float64 end particles [Particle(rand(), rand(), rand(), rand()) for _ in 1:100_000]这是一个“结构体数组”AoS 的写法每个粒子是连续对象遍历时访问particles[i].x实际上是在每个 32 字节对象里跳过 24 个字节取 8 个字节CPU 缓存利用率不理想。如果改成“数组结构体”SoAstruct ParticleSystem xs::Vector{Float64} ys::Vector{Float64} vxs::Vector{Float64} vys::Vector{Float64} end四个数组分别是连续内存块遍历xs[i]时就是在连续地址上顺序读每次缓存行都能装下八到十六个有效数据性能通常会有明显提升。这背后用的还是分段思维把属性相同的元素聚合到同一块连续空间让访问模式与内存布局对齐。6.3 优化之前先“看见”内存分布不少人在优化内存布局时容易凭感觉下手改半天代码发现性能没变甚至更差。我的经验是优化之前先做个量化观察用 perf 看 cache miss、用 heaptrack 或 valgrind 看堆分配热点、用pahole看结构体对齐和填充。比如你怀疑某个循环慢是因为缓存那就先用 perf stat 看cache-misses比例确认是缓存问题再动手改布局。如果再往底层一点写 C 的人可以用gdb的info files查看程序的段映射或者用readelf -l /bin/ls看 ELF 文件里的程序头表。这些工具都能让你直观看到“段”在可执行文件和进程空间里的真实存在方式。没有数据支撑的优化大概率只是自我安慰。我个人的体会是内存管理最折磨人的地方不是概念多而是理论归理论、现象归现象。很多朋友遇到Segmentation Fault就以为是“段”出了问题可在 Linux 的平坦模型下段早就没有存在感了真正出问题的要么是访问了未映射区域要么是越过权限访问要么是越界写坏了堆内存。建议你有空把本机随便一个服务的/proc/pid/maps拉出来看看对照着代码里的变量地址把每一行映射读过去。见过一次真实的内存布局很多概念就自动串起来了之后再谈优化也好、排查崩溃也好心里都有了底。