企业官网建设流程全解析

你有没有碰到过这种情况：服务器内存明明还剩几个GB，free -h看着也够，但某个进程一申请一块比较大的内存，内核却直接报page allocation failure: order:4，紧接着进程被 OOM Killer 干掉。如果你查过日志，大概率会看到Node 0 DMA32 free:...那一串数字，然后一头雾水：剩余内存不少，为什么就分配不出来？

问题多半出在内存碎片上。而要讲清楚内存碎片以及系统到底怎么处理它，就绕不开一个经典设计——伙伴系统（Buddy System）。这是一套在现代操作系统内存管理里沿用了几十年的算法，从 Unix 时代一路走到今天的 Linux，依然是物理内存分配的核心支柱。这篇就把伙伴系统的来龙去脉、数据结构和实际运作讲透，讲完你再去看buddyinfo，就不会觉得那是天书了。

1. 内存碎片到底从哪里来：困扰每个内存分配器的根本难题

1.1 先分清两种碎片：内部碎片与外部碎片

内存碎片说起来是一个词，实际上包含两种完全不同的东西，很多人没分清就开始讨论，结果方向全偏了。

内部碎片指的是：系统把一个内存块分配出去了，但程序真正用到的部分比这个块小，剩余那部分被“锁”在块里，谁也拿不走。举个最直白的例子：假设内存按 4KB 的页为单位分配，程序只用了 1KB，那剩下的 3KB 就是内部碎片。内部碎片是“分配粒度”造成的，解决思路是缩小分配单位，或者让分配器支持更细的粒度。

外部碎片指的是：系统里有很多分散的空闲小块，每个都小，但加起来的空闲总量很大，却凑不出一个足够大的连续块。就好比你钱包里全是零钱，总额有一百块，但想付一张五十块的整钞时，拿不出来——零钱还是那些零钱，但就是凑不成整。

伙伴系统要解决的核心矛盾，是外部碎片。

1.2 为什么外部碎片这么难搞

在一个长期运行的系统里，内存会被反复分配、释放。如果每次分配和释放的内存块大小不一、地址交错，时间一长，底层物理内存就会像一块被啃过的奶酪，到处是洞。

举个例子。假设起始有一块连续 64 页的物理内存，系统依次分配了 8 页、16 页、4 页、8 页，图形化大概长这样：

[8页][16页][4页][8页][剩余28页连续]

随后，16 页和 8 页（第一个8页）被释放：

[8页空闲][16页空闲][4页占用][8页空闲][28页空闲]

现在你把 8 页空闲和 16 页空闲加一起是 24 页，但它们不连续，中间隔着一个 4 页的占用块。此时如果有人申请一个 32 页的连续块，系统只能拒绝，虽然空闲总量仍有 48 页。

这就是外部碎片的杀伤力：可用总量充足，但最大连续块不够。而且这个过程是动态的，系统不能提前预知程序什么时候释放哪块内存，所以只能靠分配算法来“对冲”这种不确定。

1.3 分页机制并没能一劳永逸地解决碎片

有人会问：虚拟内存不是有分页机制吗？进程看到的是连续虚拟地址，底层物理页可以分散，为什么还需要物理连续的大块？

分页确实把“进程视角的连续”和“物理的分散”解耦了，但内核自己很多场景依然硬性要求物理连续，比如：

• DMA 设备直接访问内存时，无法经过 MMU 做页表翻译，要求物理地址连续；
• 内核页表本身需要连续物理页存储；
• 各种硬件驱动、固件交互用的内存块常常要求连续；
• 启停大页内存（HugeTLB）时，需要物理连续的 2MB 或 1GB 块。

所以物理内存分配器必须尽量让空闲块“完整而连续”。在 Linux 之前和早期 Unix 时代，有人试过按任意大小做动态分区分配，类似用户态malloc的 first-fit、best-fit 思路，但问题是：分配器需要维护空闲区间的复杂结构，分配释放都得查表、切分、合并，性能差且碎片同样严重。于是伙伴系统登场了，用一套极其简单的规则，把外部碎片控制在一个“可接受的范围内”。

2. 伙伴系统的核心思想：2的幂次拆分与伙伴合并规则

2.1 一条最关键的规则：伙伴的定义

伙伴系统的全部核心，可以浓缩成一句话：把内存按照 2 的幂次方切成块，每个块的大小必须是 2^order 个连续页；分配时，把一个大块不断对半拆，直到刚好满足需求；释放时，检查相邻的同大小块是否空闲，如果空闲就合并，然后继续向上检查。

这里最关键的概念是“伙伴（buddy）”。两个块互为伙伴，必须满足三个条件：

1. 大小相等；
2. 物理地址相邻；
3. 两个块合并之后，仍然是一个大小为 2^(order+1) 的合法块。

举个例子：大小为 4 页的块 A 起始地址是 0，大小为 4 页的块 B 起始地址是第 4 页，那么 A 和 B 就是伙伴，它们合并成 8 页的块，起始地址 0。但如果 B 起始地址是第 8 页，虽然也相邻，A 和 B 合并后是 12 页，不是 2 的幂次，所以它们不是伙伴关系，不能合并。

再换一种直观说法：任何一个大小为 2^order 的块，它的伙伴的起始地址，是把该块起始地址的第 order 位翻转之后得到的。所以代码里可以用一个异或操作直接算出来。

static inline unsigned long buddy_pfn(unsigned long pfn, unsigned int order) { return pfn ^ (1 << order); }

pfn是页框号（page frame number），1 << order是当前块大小。这个异或操作就是伙伴系统里最优雅的“暗号”：一按开关，就能找到失散多年的兄弟。

2.2 分配时怎么拆：大块一分为二，右半块进低阶链表

假设系统现在只有一个大小为 8 页的空闲块，有人申请 2 页（order=1），分配器会这样做：

1. 在 order=1 的空闲链表里找，发现没有空闲块；
2. 往上找 order=2、order=3，在 order=3 找到那个 8 页块；
3. 把 8 页块拆成两个 4 页块，左半块继续拆成两个 2 页块；
4. 把其中一个 2 页块返回给申请者，剩下的 2 页块挂到 order=1 链表；
5. 另一个 4 页块挂到 order=2 链表。

整个过程可以把所有没分配出去的“半块”放到相应 order 的链表中等待下次使用。也就是说：申请大块时拆出来的小块不会浪费，都会被规整地收纳到对应的档位。这有点像你去银行换零钱：你拿一张 100 元说要换 20 元，柜员为了凑出 20 元可能先拆成 50+50，再拆出 20+30，但最终多余的 50 和 30 都还会作为现金留在系统里，而不是扔掉。

2.3 释放时怎么并：从下往上递归合并

释放过程正好反过来。还拿上面的例子：现在释放那个 2 页块，释放时需要找到它的伙伴（另一个相邻的 2 页块）。如果伙伴也是空闲的，就把两者从各自链表中摘下来，合并成一个 4 页块；然后继续看这个 4 页块的伙伴是否空闲，如果空闲继续合并成 8 页块，一路向上，直到无法合并为止。

这就是伙伴系统名字的由来：每个块都在找自己的“搭档”，搭档凑齐了就合并升级。这个合并机制保证了系统空闲内存会不断“聚拢”，大块数量尽量被恢复，从而抑制外部碎片的恶化。

2.4 为什么说它“优雅”：简单规则 + 稳定复杂度

如果你头一次接触伙伴系统，可能会觉得这也没啥了不起。但它的优雅体现在三个层面：

第一，规则极其简单。整个系统只需要维护若干个空闲链表和一个伙伴计算公式，分配和释放各自只有两条核心逻辑：拆、合。

第二，性能稳定。分配和释放的时间复杂度都是 O(log N)，N 是系统内存按页数计算的总量。每次分配最多向上翻到 11 层（MAX_ORDER 通常是 11，对应最大连续块 2^10 = 1024 页，在常见页大小下是 4MB），所以无论内存多大，查找次数都是个位数级别的常数。

第三，对碎片是“主动抑制”而不是“事后补救”。系统里任何空闲块都尽量保持完整大块的状态，小的碎片只可能出现在分配出去的块里，空闲区总能维持较大的连续面。

3. 从数据结构到分配算法：伙伴系统是怎么“跑”起来的

3.1 free_area[order]：一维数组，一堆空闲链表

伙伴系统的核心数据结构是一个数组free_area[MAX_ORDER]，数组的下标就是 order。每个free_area[order]内部挂一个链表，链上所有节点代表大小为 2^order 个页的空闲块。

如果把 order 和块大小对应起来，大概是这张表：

在这个 table 里，越靠上的 order 代表块越小，越靠下代表块越大。系统在初始化阶段会把整块物理内存分成若干个大小为 2^10 的“最高档”块挂到最下面，或者按实际连续情况挂到不同 order 上。

每个内存节点（node）又分成若干个内存域（zone），比如 ZONE_DMA、ZONE_DMA32、ZONE_NORMAL，每个 zone 都有自己的free_area数组，所以你在/proc/buddyinfo里会看到多行，一行对应一个 zone。

3.2 怎么快速判断伙伴是否空闲：PageBuddy 标志与位图

伙伴系统效率的关键，在于释放时能够“瞬间”判断伙伴是否空闲。如果每次释放都去遍历链表找伙伴，那复杂度就没法看了。这里有两个常用方案：

早期内核用一张位图来记录“一对伙伴块是否有伙伴空闲”，每次分配和释放时维护位图状态。现代内核则更直接：每个物理页的struct page里有一个PageBuddy标志位，如果这个页是空闲块的首页，就会置上该标志，同时它的_mapcount会被复用为 order 值。

所以释放时的伙伴检查逻辑变成：

static inline int page_is_buddy(struct page *page, unsigned int order) { if (!PageBuddy(page)) // 伙伴页必须也是空闲块 return 0; if (buddy_order(page) != order) // 伙伴大小必须与自己相等 return 0; return 1; }

再加上用异或计算伙伴地址，释放一个块时只需要做常数级别的检查，不用遍历任何链表。

3.3 分配路径拆分：拿到一个空闲大块后怎么切

当申请 order 的内存量时，分配器先从free_area[order]拿一个块。如果没有，就往free_area[order+1]找，再没有继续往上找，直到最高的MAX_ORDER-1。找到一块之后，用expand函数逐级拆分。

下面的 C 伪代码示意了 Linux 中expand的核心逻辑，注意我做了大量简化，只保留拆分思想：

static inline void expand(struct zone *zone, struct page *page, int low, int high, struct free_area *area) { unsigned long size = 1 << high; // 当前大块大小 while (high > low) { // 进入下一阶（更小的 order） area--; high--; size >>= 1; // 大块右半部分挂到下一阶空闲链表 list_add(&page[size].lru, &area->free_list[MIGRATE_MOVABLE]); // 设置右半部分的 order 值 set_page_order(page + size, high); } }

其中page是大块的起始页，low是要拆到的目标 order，high是当前大块的 order。每循环一次，就把大块的右半部分“挂账”，左半部分继续往下拆，直到达到目标 order。拆完之后，目标 order 的左半块返回给调用者。

3.4 释放路径合并：向上合并直到撞到“非空闲”

释放时核心函数叫__free_one_page。它的循环逻辑非常干净：

while (order < MAX_ORDER - 1) { // 计算出伙伴的起始页框号 buddy_pfn = pfn ^ (1 << order); buddy = page + (buddy_pfn - pfn); // 伙伴不在该 order 的空闲链表上，停止合并 if (!page_is_buddy(buddy, order)) break; // 把伙伴从空闲链表中摘掉 list_del(&buddy->lru); // 合并后起始 pfn 取左块 pfn &= ~(1 << order); order++; } // 最终把合并后的块挂到 free_area[order] list_add(&page->lru, &zone->free_area[order].free_list[migratetype]); set_page_order(page, order);

这段代码巧妙的地方在于：伙伴只需要一行异或就算出来；合并之后的起始地址直接把当前 order 对应的位清零即可。不需要记录额外信息，数据结构本身就已经隐含了合并路径。

3.5 一个 5 分钟的模拟：从 order=3 分配会发生什么

我们假设系统里有一块 8 页的连续内存，初始化后它作为一个 order=3 的空闲块挂在free_area[3]上。

现在进程申请 1 页（order=0）：

• rmqueue找free_area[0]，空；上到free_area[1]，空；上到free_area[2]，空；上到free_area[3]，找到一个 8 页块。
• 8 页块拆成两个 4 页块，右半块（order=2）挂到free_area[2]；
• 左 4 页块再拆成两个 2 页块，右半块（order=1）挂到free_area[1]；
• 左 2 页块再拆成两个 1 页块，右半块（order=0）挂到free_area[0]；
• 左 1 页返回给进程。

此时系统的空闲状态是：free_area[0]有 1 块，free_area[1]有 1 块，free_area[2]有 1 块，free_area[3]空了。

等到这块内存释放，合并过程会逆着拆分的路径，一步步把 1 页并成 2 页、2 页并成 4 页、4 页并成 8 页，最终恢复为 order=3 的大块。这也是为什么伙伴系统能“自动修复”内存：你拆出去的块，只要全都还回来，最终一定能合并回原来的大块，中间状态全部被空闲链表有序收纳。

4. 一次完整的内存旅程：以 Linux 内核为例看伙伴系统的工作细节

4.1 从 memblock 到 buddy：物理内存初始化

Linux 启动初期，物理内存管理用的是memblock，一个非常简单的分配器，专门服务启动阶段的内核镜像、页表等。等到内核内存管理子系统初始化完毕，free_page_init()会把 memblock 里没被占用的物理页一个个释放给伙伴系统。

每个页释放进伙伴系统的时候，都会执行一次完整的“释放页并向上合并”流程。初始阶段内存全连续，所以最终伙伴系统里会形成大量的 order=10（4MB 大小）的整块，直到内存被切完。此时查看/proc/buddyinfo，你会看到每个 zone 里最高 order 的块数量比较大，低 order 基本是 0。这就是一台刚重启、内存管理干干净净的机器的状态。

4.2 一次 malloc 背后，到底怎么触达伙伴系统

用户态程序调用malloc(3000)，glibc 可能直接从内存池里分配，不涉及系统调用。如果申请特别大或者内存池不够，glibc 会用mmap或者brk向内核申请内存。这时内核才会通过缺页异常（page fault）触发真正的物理页分配。

缺页处理函数最终会调用alloc_pages，然后走get_page_from_freelist、rmqueue等核心路径，从伙伴系统里取出物理页，再建立页表映射。也就是说：伙伴系统面对的是内核内部和各种驱动，用户态程序说到底是间接消费者。

4.3 一个不能忽略的现实问题：锁竞争与 per-CPU pageset

理论上伙伴系统很完美，但真实世界有并发。多个 CPU 同时要分配内存，如果每次都去抢同一个 zone 的free_area锁，性能就是灾难。Linux 的做法是在每个 CPU 上维护一个小小的“页缓存”pageset，里面存放一部分热页。分配内存时优先从本 CPU 的 pageset 拿，不用加锁；pageset 空了再向伙伴系统批量“进货”。

这样兄弟系统在高并发下依然能保持不错的性能，但也带来一个有趣的副作用：/proc/buddyinfo里看到的 low-order 空闲块数量，经常会有波动，因为这些块可能暂时被某个 CPU 缓存走了。所以读这个文件时不要只看一两次的数，应多采样观察趋势。

4.4 教你看懂 /proc/buddyinfo：用文件判断碎片程度

机器上执行cat /proc/buddyinfo，输出类似这样：

Node 0, zone DMA 1 0 1 0 2 1 1 0 1 1 3 Node 0, zone DMA32 5673 412 109 21 35 17 8 5 4 2 0 Node 0, zone Normal 12830 2670 1285 874 402 155 67 29 11 4 2

从左到右分别是 order 0 到 order 10 的空闲块数量。

怎么看碎片严不严重？核心是看低 order 块多不多、高 order 块有没有。如果一个 zone 里 order 0 有几千块、但 order 9、order 10 是 0，说明内存碎片化已经比较严重了；如果 order 9、order 10 还有一定数量，说明仍然存在大块连续内存，安全性高很多。

比如上面示例的 Normal zone，order 9 有 4 块（每块 2MB，共 8MB），order 10 有 2 块（每块 4MB，共 8MB）。这表示 16MB 连续内存仍然拿得出来，很多要求苛刻的驱动都没问题。真正危险的状态是 order 8 以上全空、低 order 却高居不下，那才是典型的“空闲但碎片化”。

4.5 一个我踩过的坑：不要被 free 命令骗了

有次线上机器报内存分配失败，我上去一看free -h：Mem 总共 64G，available 还有 20 多 G。直觉上不应该失败。后来查/proc/buddyinfo才看到，DMA32 和 Normal 的高阶 order 几乎为 0，低阶 order 全部爆满，剩余内存全是碎片。那次是因为一个业务容器在反复创建和销毁线程，产生大量页缓存和内核对象的分配释放，把内存搅成了“细沙”。不看 buddyinfo 的话，光看free永远找不到真凶。

所以排查内存问题的顺序我建议是：先 free 看总量，再 budddyinfo 看分布，最后才决定怎么优化。如果碎片严重但总量不高，最简单快捷的方式是重启业务并观察低阶 order 是否会持续堆积；如果内存总量充足但碎片严重，则可以手动触发 compaction（见后面第 6 章）。

5. 现实世界的伙伴系统：迁移类型、页缓存与防碎片策略

5.1 为什么 Linux 要给它打补丁：引入迁移类型

纯朴的伙伴系统有一个致命伤：它把所有空闲块都混在一起用，完全不关心这些页面未来会怎么被使用。有些页面一旦分配出去，物理位置就永远固定了（比如内核代码、某些驱动内存）；有些页面则可以随时迁移（比如用户态进程的匿名页、页缓存里的文件页）。

当不可迁移的页和可迁移的页在物理地址上交错分布时，即使可迁移页允许搬走，也会因为中间夹着不可迁移页而无法合并出大块。于是 Linux 在伙伴系统之上引入了迁移类型（migratetype），每个空闲链表不再是一条，而是按迁移类型分成多条：

• MIGRATE_UNMOVABLE：不可迁移，内核映像、驱动内存等；
• MIGRATE_MOVABLE：可迁移，用户态内存、页缓存等；
• MIGRATE_RECLAIMABLE：可回收，某些内核缓存；
• MIGRATE_CMA：给 CMA 预留的可迁移区域；
• MIGRATE_HIGHATOMIC：给紧急原子分配预留。

分配页面时，系统会按迁移类型去对应的链表里找块；如果当前类型的空闲块不足，会去其他类型“借”。这个机制把不同生命周期的内存大致分开，大大降低了它们互相“染色”导致碎片的风险。

5.2 反碎片技术：把可移动页赶一大块去

有了迁移类型之后，内核还提供“内存规整（memory compaction）”机制。它的核心思路是：

1. 找到一片碎片较多的区域；
2. 把其中的MIGRATE_MOVABLE页向区域的一端迁移；
3. 迁移结束后，区域的另一端就腾出了一整块连续物理内存。

你可以手动触发全系统规整：

echo 1 > /proc/sys/vm/compact_memory

执行之后再去cat /proc/buddyinfo，大概率能看到中高阶 order 的空闲块数量明显上升。这块机制是生产环境处理碎片最高效的“手工操作”之一，尤其适合那种跑了几十天、内存分布混乱的常驻服务机器。

5.3 伙伴系统 vs 内核里被扩展后的多链表结构

拿原始设计对比 Linux 里的实际实现，差别还是很大的，整理成表格更直观：

一句话：教科书版本是骨架，Linux 在骨架上长满了肌肉和血管，让它更适应真实世界的复杂场景。

5.4 迁移类型不是万能的：借来借去也会产生新问题

迁移类型机制也有副作用。比如某台机器上不可迁移的内存特别多，UNMOVABLE 类型的空闲链表被耗尽了，内核就不得不从 MOVABLE 链表“借块”。借完之后，MOVABLE 区域里就混入了 UNMOVABLE 的页，并且这些页不会自动还回来，会永久性降低该区域的迁移能力。

内核里有一种机制叫borrow和“fallback”统计，如果你去查看/sys/kernel/debug/extfrag/unusable_index，就能看到每个 zone 在每档 order 下“不可用指数”有多高。指数越高，说明该区域越难凑出对应大小的大块。正常健康的机器，unusable_index 应该很低；如果某个 order 的指数长期接近 0.5 或更高，就需要考虑机器是不是该重启或者迁移业务了。

6. 伙伴系统的天花板：何时它不够用，后续又是怎么补的

6.1 天生只处理页粒度：小于一页的请求不归它管

伙伴系统管理的最小单位是一页，也就是 4KB。但内核内部大量对象只有几十字节或几百字节，比如task_struct、inode、dentry等。如果都用伙伴系统分配一页，浪费率会惨不忍睹。所以内核在伙伴系统之上又实现了一个slab分配器（以及后来的slub、slob），它从伙伴系统中申请一大块页作为“原料”，然后切成大小相等的对象，供内核频繁分配小对象。

可以这么理解：伙伴系统是批发商，slab 是零售商。伙伴系统保证批发环节的大块连续，slab 负责把批发来的块切成细料卖给内核里的零散买家。两者配合，既解决了外部碎片，又把内部碎片控制在很小的范围内。

6.2 大页内存（HugeTLB）：碎片问题的“放大器”

需要特别留意的是，大页内存是对伙伴系统碎片最敏感的场景之一。2MB 大页对应 order=9，1GB 大页对应 order=20（需要 CONFIG_ARCH_HAS_SET_DIRECT_MAP 等支持，但伙伴系统本身 MAX_ORDER 通常只有 11，有些架构专门做了扩展）。如果你的机器运行一段时间后 order=9 的连续块数量变成 0，那么即使内存总空闲量很大，echo 20 > /proc/sys/vm/nr_hugepages也无法成功预留大页。

这也是为什么很多数据库、虚拟化宿主机都建议启动时预留大页：趁内存还干净的时候把大块锁住，而不是运行几天后再去向碎片化严重的内存“乞讨”。如果你必须做什么，echo 1 > /proc/sys/vm/compact_memory之后再试会更有戏，但仍不能保证 100% 成功。

6.3 面对高位 order 分配失败，内核和运维各自能做什么

当分配 order 比较大的内存块失败时，内核并不会立刻放弃，而是会依次尝试：

1. 慢路径分配，唤醒 kswapd 回收可回收页；
2. 执行 direct reclaim，尝试直接回收页缓存；
3. 执行内存规整（compaction），迁移可移动页腾出大块；
4. 如果还不行，才会调用 OOM Killer。

作为运维/应用侧能做的，除了上面说的主动触发 compact，还可以通过drop_caches清掉页缓存，这在很多碎片场景下立竿见影：

echo 3 > /proc/sys/vm/drop_caches

清完缓存后，大量页缓存对应的物理页会归还给伙伴系统，碎片空间变多，大块连续内存的机会也会变大。但是要说明白，这只适合页缓存占比高的场景，如果碎片主要是不可迁移页造成，效果有限。

6.4 跳出内核看伙伴系统：这套思想到处都是

伙伴系统的应用远不止操作系统。很多用户态内存分配库、网络协议栈的内存池、文件系统的块分配器，都在借鉴它的思想：把资源按 2 的幂次分档管理，维护一组空闲链表，释放时尝试合并相邻同档空闲块。这种“同类合并、大块优先”的思路，本质上是一种优秀的资源管理降碎片的通用模式。

比如一些网络设备的包缓冲区，采用 ring buffer 和固定档位分池；分布式系统里的内存池、线程池，也常用最小堆和分桶的方式管理空闲项。只要你有“资源会被反复申请和释放，且时间不可控”的场景，都可以想想类比伙伴系统的方案：给资源分档、记录相邻关系、释放时主动合并。

回到开头那个问题。当你再看到page allocation failure: order:4的报错，别再对着free -h发呆了。先cat /proc/buddyinfo，看看对应 zone 的高阶 order 是不是已经空了；再判断能不能用compact_memory或drop_caches把碎片空间挤出来；最后才考虑业务调整或者大页预留策略。伙伴系统不是魔法，它只是把一个很复杂的问题，用一条简单的“伙伴合并规则”约束到了可控范围。弄懂它之后，你会觉得内存碎片没那么可怕——至少你能看出它来了，也大概知道往哪个方向去治它。