Linux内核内存管理：SLAB、SLUB与SLOB分配器解析与排障指南

搞内核这段时间，我最大的一个感受是：内存管理这摊水，表面看是伙伴系统加页表的事，但真正把内核日常跑起来的，其实是 slab 那套小对象机制。你打开的每个文件、创建的每个进程、发的每个网络包，背后都有各种内核对象在 slab 缓存里反复进出。SLAB、SLUB、SLOB 这三个名字，学内核的朋友基本都听过，可真到了项目里，很多人一聊就含糊：现在默认用的到底是哪个？三者什么关系？能随便切换吗？为什么我服务器的 Slab 内存一直涨？

这篇文章我打算把这些事一次说透。不会去逐行粘贴源码，而是把三种分配器的设计思路、取舍逻辑、实际配置和排障手法串起来。适合刚接触内核内存管理的人，也适合那些已经会敲 slabtop、但在问题面前不知道往哪查的工程师。

1. 三种分配器要解决的同一个问题

在聊 SLAB、SLUB、SLOB 之前，得先搞清楚一个前提：它们解决的是同一个问题，只是解题思路完全不同。换个说法，这三兄弟争的是同一块地盘，只是有的选择“精装修”，有的选择“极简风”。

1.1 从伙伴系统说起：为什么内核非要搞一套小对象机制

Linux 物理内存管理的地基是伙伴系统，分配物理内存的最小单位是一个页，通常 4KB。伙伴系统很适合分配整页内存，因为它按 2 的幂次拆分合并，外部碎片控制得不错，而且分配路径非常直接。

问题在于，内核里真正高频分配的内存对象，并不是整页，而是几十字节、几百字节的小结构体。随便举几个例子：task_struct 进程描述符、dentry 目录项、inode 文件索引节点、socket 结构、文件描述符，这些对象会随着文件操作和进程调度疯狂创建和销毁。如果每次都向伙伴系统要一个 4KB 页，哪怕对象本身只有几百字节，剩下的空间也全部浪费掉。而且每次分配页、释放页都要走页表映射、zone 锁、页标志位维护，这个开销即使是机器也很难扛住。

更关键的是初始化成本。很多内核对象分配之后不是直接用，而是要执行构造函数去设置初始值，或者至少要把关键字段清一遍。如果每次都从伙伴系统拿到一个全新页面，那么这个初始化操作也得跟着做一次。可如果对象被放到一个缓存里，分配几次之后对象已经被初始化过了，后边的分配就可以跳过构造阶段，只需要把对象从空闲链表上摘下来就行。

这就是 slab 分配器存在的根本原因：把同尺寸、同类别的对象集中缓存在一起，减少对伙伴系统的打扰，同时降低初始化和内存碎片成本。

1.2 直接感受一下：不做缓存会亏多少

我举个直观的例子帮助你理解。假设一个内核对象真实大小是 180 字节，如果不经过 slab 层，直接从伙伴系统分配内存，你拿到的是一整页 4KB，180 字节用掉，剩下 4012 字节全浪费。换句话说，这一页的内存利用率只有 4% 出头。

但如果你建了一个 dedicated cache，按 180 字节去切分这个页，一页里能切出 22 个对象，利用率立刻升到 98% 左右。再加上内部碎片控制、per-CPU 缓存、对象复用，整体的内存效率和分配吞吐完全是另一个数量级。

这其实就是 slab 类分配器最底层的收益公式：大内存（伙伴系统）负责“批发”，小对象缓存负责“零售”。内核不可能每次买一斤米都开一辆卡车去粮库，slab 层相当于在楼下开了个小卖部。

1.3 三兄弟定位对比一张表说清

在往下深入之前，先摆一张对比表，把 SLAB、SLUB、SLOB 的整体气质说清楚。后面每个我都会单独展开。

我个人的看法：SLAB 像一个精装修的老房子，每个细节都打磨过，但管线复杂；SLUB 是推倒重来后的现代公寓，省掉了很多花哨设计，结果住起来反而更舒服；SLOB 则是个临时板房，能遮风挡雨，但别指望它有多舒服。

2. SLAB 分配器：传统派的精细与代价

SLAB 是最早进入 Linux 内核的通用对象缓存方案，设计思想来自 Solaris。在很长一段时间里，它就是 Linux 内核的默认分配器，很多老工程师提到 “slab” 时，其实指的就是这个 SLAB 实现本身。

2.1 三个队列加 per-CPU 缓存，SLAB 的核心调度

SLAB 里一个 kmem_cache 对应一类对象。每个 cache 下面挂着若干 slab，每一个 slab 本质上就是一块连续物理页，被切成多个大小相同的对象。

SLAB 给每个 cache 维护了三类 slab 队列：完全空闲的 empty 队列、部分使用的 partial 队列、完全用光的 full 队列。分配对象时优先从 partial 里拿，拿不到再考虑新建 slab；释放对象时如果 slab 变为 empty，则根据水位策略决定是归还给伙伴系统，还是继续留在 cache 里备用。

这套三队列本身没什么稀奇的，真正精妙的是它加了 per-CPU 缓存。每个 CPU 都有一个 array_cache，里面缓存了一批刚刚释放出来的对象。分配时先看本 CPU 的 array_cache，有就直接拿，完全不碰全局锁；没有再去 partial 队列里批量搬一批到本 CPU 缓存。释放时同理，对象先回到 array_cache，积累到一定水位再批量还给 slab。

你看到这应该就明白了，SLAB 在该省锁的地方非常舍得花心思。array_cache 的存在让同一个 CPU 上的分配释放操作绝大部分时间不需要跨核通信，也不会触发锁竞争。这在单核、小规模多核时代简直是降维打击。

2.2 cache coloring：为了硬件缓存命中玩的偏移手段

SLAB 一个容易被忽略但很有意思的设计是着色。这里说的着色不是给 slab 刷颜色，而是为了躲开 CPU 硬件 cache 的 set 冲突。

现代 CPU 的硬件缓存，尤其是 L2/L3，并不是简单的全关联。它把内存地址映射到固定的 cache set 上，不同物理地址如果落进同一个 set，那么它们会互相驱逐。如果内核把多个 slab 都从页面的同一偏移开始放第一个对象，这些 slab 的第一个对象很可能映射到同一个 cache set，你在一个 slab 上频繁访问对象时，另一个 slab 上的热点数据就会被反复挤出硬件缓存，造成性能抖动。

SLAB 的做法是给不同的 slab 设置不同的首个对象偏移量，也就是一组“颜色”。每个新的 slab 从颜色表里取一个颜色，让对象在物理页面里错开位置，尽量分散硬件缓存的集合冲突。这个优化在远古 CPU 缓存很小、关联度很低的年代效果很显著。但现代 CPU 缓存关联度已经高了很多，着色带来的收益越来越弱，SLUB 最终干脆放弃了这个功能。

2.3 构造器、回收和 shrink 机制

SLAB 的另一个传统是支持对象构造函数。创建缓存时可以通过 kmem_cache_create 传入构造函数，之后每次分配对象时执行；销毁对象时也可以执行析构函数。听起来很美好，但在现代内核里，构造函数用得很少了，因为内核普遍倾向于“用哪个字段就初始化哪个字段”，没必要让每个对象都经过一遍全量构造。SLUB 虽然也保留了这个参数，但大多数情况传入 NULL。

SLAB 对内存回收也做了不少工作。部分缓存会被标记为可回收，比如 dentry、inode 这类缓存。内核在内存紧张时会优先扫描这些可回收 slab，把它们占用的内存让给更紧迫的用途。同时 SLAB 还提供了 kmem_cache_shrink 这样的接口，用于压缩缓存里空闲的 slab。实际运维中你要注意，看到/proc/meminfo里 Slab 数值偏高，不一定是内存泄漏，也可能是正常的文件系统缓存，只是没有达到回收阈值。

3. SLUB 分配器：一场教科书级的去复杂化实践

SLUB 是在 2.6.23 前后合入内核的，设计初衷非常直接：嫌 SLAB 太复杂。它保留了 SLAB 的所有核心收益，但把数据结构和管理路径大幅简化。现代主流发行版基本都是 SLUB，你要在 2020 年之后的服务器上跑 uname 看内核，十有八九用的就是它。

3.1 SLUB 到底简化了什么

SLAB 里，每个 slab 的状态必须靠复杂的队列管理，还要维护空闲对象链表、着色偏移、per-CPU array_cache 等一整套状态。SLUB 最大的变化在于，它把“slab 本身的元数据”直接塞到了页结构里，不再需要额外维护一套 slab 描述符的链表和状态机。

分配时，SLUB 从页结构里拿到空闲对象链表的头指针，直接摘一个对象出来；释放时，把对象重新挂回空闲链表。一个 slab 要么是 partial，要么是 full，不再有 SLAB 那么复杂的 empty/full/partial 三态管理。当一个 slab 的所有对象都被释放后，页面直接归还给伙伴系统，没有那么多过渡状态需要维护。

这种设计带来的收益很实在：代码路径更短，锁更少，数据结构占用的内存更小。尤其是对大内存、多核、NUMA 架构的服务器来说，SLUB 的扩展性比 SLAB 明显好。你想象一下，一个大型数据库服务器上有几十个核同时做内存分配，SLUB 的锁开销比 SLAB 低很多，最终体现出来的就是吞吐量和延迟的差距。

3.2 per-CPU partial 列表与远程释放的巧妙处理

SLUB 虽然砍掉了 SLAB 的 array_cache，但它引入了 per-CPU partial 列表。每个 CPU 持有一部分 partial slab，只属于它自己，别的 CPU 不会来抢。这样本 CPU 的对象分配和释放很多情况下连一个全局锁都不用碰，只有在本 CPU partial 列表耗尽或者过多时，才会去访问节点级的 partial 列表。

这里有个很容易被忽略的细节：远程释放。假设 CPU0 分配了一个对象，后来 CPU2 把它释放了。SLUB 的处理方式是，先看看这个对象原来属于哪个 slab 的 freelist，根据 slab 的归属关系来决定放到哪个节点列表。如果非要跨节点访问，则走锁路径。但因为有 per-CPU partial 列表兜底，大多数释放操作都不需要跨 CPU 找锁，这在多核场景下威力巨大。

SLUB 还引入了几个重要的调控参数：slub_min_order、slub_max_order、slub_min_objects、cpu_partial。比如 slub_min_objects 表示每个 slab 至少要放多少个对象，系统计算 slab 的阶数时会拿这个值去换算，避免为了凑一个大的 slab 而浪费内存。cpu_partial 则限制每个 CPU 上最多暂存多少个 partial slab，防止某个 CPU 上对象堆积过多。这些参数都可以作为内核启动参数传入，生产环境中一般不需要动，但调优时它们就是最直接的抓手。

3.3 SLUB 的调试能力，比想象中强得多

很多人以为 SLAB 调试功能丰富，SLUB 简化了所以调试差，事实正好相反。SLUB 在保持简单结构的同时，提供了非常强大的排障手段。

内核编译时如果开启 CONFIG_SLUB_DEBUG，重启时可以在引导参数里加 slub_debug。常见选项有 F（做完整性检查）、Z（红区保护，探测越界写）、P（毒化对象，释放后写入固定字节，再次分配时如果值不对就说明有野指针）、O（对象跟踪，记录每个对象的分配与释放调用栈）、U（用户态调用栈跟踪）、T（trace）。组合起来常用 slub_debug=FZPOU，相当于把 slab 调试的常见手段全开。

启动之后，/sys/kernel/slab 下面会出现每个缓存的目录。你可以看到一个缓存里有多少对象、每个对象多大、每个 slab 里放多少对象、使用的 order 是多少、per-CPU partial 数量等。像 kmalloc-256 这种通用缓存，也能在它的 alloc_calls、free_calls 文件里看到造对象时内核栈的统计信息。我遇到过一个内存泄露问题，就是靠 SLUB 的 alloc_calls / free_calls 定位到是某个网卡驱动在收包路径上反复分配 skb 但不释放。SLAB 时代想做到这种粒度，你得自己打 patch，SLUB 直接把工具给你备齐了。

4. SLOB 分配器：极限小内存场景的取舍

SLOB 全称是 Simple List Of Blocks，它对标的场景和 SLAB/SLUB 完全不一样。SLAB 和 SLUB 是为了解决性能和碎片问题，而 SLOB 的目标非常单纯：尽量少占内存。它存在的意义就是把整个 slab 机制本身的内存开销降到最低。

4.1 工作原理：抛弃缓存，回归最原始的链表

SLOB 不按对象大小划分独立的 slab 缓存，至少不像 SLAB/SLUB 那样为每个对象类别维护一套复杂状态。它直接把物理页面当成一块块内存块，按实际请求的大小区分，塞进一个简单链表里。分配时采用 next-fit 策略，沿着链表找第一个足够大的块，拆出来给请求方；释放时把内存块放回链表，必要时做前后合并。

这种设计几乎没有任何额外开销。没有 kmem_cache 描述符，没有 per-CPU 缓存，没有 slab 状态机，没有着色。内核里的对象直接从一个共享内存池里切，你要 70 字节它就给你切一个 70 字节的块，多了也不管理。这样一来，SLOB 占用的元数据内存被压缩到极致，非常适合内存只有几 MB 到十几 MB 的嵌入式设备，比如老式路由器、开发板、微控制器系统。

4.2 省了内存，代价是什么

SLOB 省内存省得痛快，但绝不是免费的午餐。它最大的问题有两个：碎片和性能。

因为没有按对象大小做隔离，各种各样的对象会互相穿插地出现在同一个页面上。今天分配一个 task_struct，明天释放一个 socket 缓冲区，后天再分配一个 skb，这块内存就会被打得七零八落，产生大量没法利用的外部碎片。碎片积累到一定程度，可能连一个连续大块都分配不出来，触发内核回收、甚至直接分配失败。

性能问题更明显。next-fit 策略在对象数量少的时候无所谓，可一旦缓存里对象成千上万，每次分配都要在链表里走一圈，复杂度就是 O(n)。在服务器上随便跑一个并发稍高的服务，每秒分配的 skb 和 dentry 数以万计，SLOB 的线性扫描直接能成为新的性能瓶颈。我在一个 64MB 内存的 MIPS 小板上试过 SLOB，纯粹内存占用确实低，但一旦跑起业务流量，CPU 占用立刻飙升，得不偿失。

4.3 什么场景下 SLOB 才值得用

SLOB 的适用面非常窄，只适合那种内存小到 SLUB 的开销都嫌浪费、且对性能要求不高的场景。比如一个 8MB RAM 的工业控制器、一个跑 busybox 的极简系统。在这种环境里，你省下的那几百 KB 内核内存，可能比什么都珍贵。

但我要提醒一句：如果你的设备内存已经能到 32MB、64MB，我都建议直接上 SLUB，别用 SLOB。省下的内存有限，调试能力却几乎归零，以后出了问题你会非常痛苦。SLOB 连 /proc/slabinfo 都提供不了，你想查每个对象占了多少内存都无从下手。

5. 如何查看当前用的是哪种分配器

聊了这么多理论，该落地了。实际工作中你遇到的第一件事往往是：我这台机器到底是 SLAB 还是 SLUB？甚至是不是 SLOB？判断方式其实很简单。

5.1 一条命令快速判断分配器类型

最直接的方法就是看内核编译配置。如果内核开启了 CONFIG_IKCONFIG_PROC，可以直接看压缩配置：

zcat /proc/config.gz | grep CONFIG_SLUB

大多数发行版没有开放这个接口，那就去 /boot 下看：

grep -E 'CONFIG_(SLAB|SLUB|SLOB)' /boot/config-$(uname -r)

输出结果里通常只有一个 Y。比如CONFIG_SLUB=y就说明当前内核编译时选的是 SLUB。

如果没开 CONFIG_SLUB_DEBUG，你还可以用文件系统特征来判断。SLUB 会在 /sys/kernel/slab 下导出缓存目录，而 SLOB 系统里通常没有 /proc/slabinfo。所以：

ls /sys/kernel/slab | head -20

如果这个目录存在且内容很多，基本就是 SLUB；如果你在 /proc/slabinfo 能看到内容，说明至少是 SLAB 或 SLUB；如果 /proc/slabinfo 根本没有，那大概率是 SLOB。

5.2 slabtop 应该怎么看

确认分配器之后，日常监控用 slabtop 就够了。它的输出是从 /proc/slabinfo 读取并处理后展示出来的。

slabtop -o

你会看到一个表格，默认按对象数量排序，列出缓存名、活动对象数、总对象数、对象大小、每 slab 对象数、页数、内存占比等信息。实际看的过程中，我建议先按内存占用排序，比如：

slabtop -s c

其中 -s c 表示按缓存大小排序。看到 dentry、inode、kmalloc-*、skbuff_head_cache 这类缓存排在前面，是正常现象。但如果发现某个专用缓存占用异常高、对象数持续增长不回落，就要警惕了，这往往是泄漏或异常扩大化的信号。

配合 /proc/meminfo 里的 Slab 字段，你能快速判断内核对象缓存占用的总内存：

grep Slab /proc/meminfo

5.3 内核选型不是随便改的

SLAB、SLUB、SLOB 是编译期决定的，不是运行时可以热切换的配置项。内核编译时在 Kconfig 里选择，对应的配置项是：

• CONFIG_SLAB
• CONFIG_SLUB
• CONFIG_SLOB

如果你真的想切换，得重新编译内核。现在主流发行版默认都是 SLUB，我个人不建议你为了“试试 SLAB 的效果”去随便切换。SLUB 的简单路线在绝大多数场景下都更有优势，SLAB 的复杂度换来不了多少额外收益。只有在你明确复现某个 SLUB 行为异常、且确认 SLAB 能规避时，才值得去编译测试。

6. 实战排障：Slab 内存膨胀与定位

理论知识再多，最终都要落到排障上。这些年处理了不少 slab 相关的问题，最常见的就两类：一类是 Slab 内存持续上涨看着像泄漏，另一类是明确怀疑某个内核对象类型在异常分配。下面分享几个我实操中反复用到的思路。

6.1 场景一：Slab 总内存居高不下

这大概是群里问得最多的问题：“服务器 /proc/meminfo 里 Slab 占了几个 G，是不是内存泄漏了？”很多朋友一看到 Slab 大就慌了，其实要先判断是正常缓存还是异常增长。

第一步做快照对比。间隔一分钟分别执行两次：

slabtop -o > /tmp/slab_1.log sleep 60 slabtop -o > /tmp/slab_2.log diff /tmp/slab_1.log /tmp/slab_2.log

如果绝大多数缓存的名字没变，总内存也基本稳定，那就说明只是缓存水位高，不是泄漏。dentry、inode 这类缓存大，往往是因为系统里文件总数多、目录层级深，容量本身是物理内存的反映。

如果确认某个缓存的对象数持续单调上涨，就进入下一步。先看这个缓存的 active_objs 和 num_objs 比例。active_objs 是正在被使用的对象数，num_objs 是缓存里总对象数。如果 active_objs 很小，num_objs 很大，说明空闲对象积压，可能只是缓存没收缩；如果 active_objs 也和 num_objs 一起涨，那就有真实对象没释放。

常见原因是文件系统相关。比如 dentry 缓存异常，你可以尝试触发回收：

sync echo 2 > /proc/sys/vm/drop_caches

这会清掉 dentry 和 inode 缓存。注意生产环境上执行前必须确认业务能接受缓存被清空带来的短时性能抖动，尤其是文件服务场景。

6.2 场景二：定位对象泄漏的源头

如果确认不是单纯缓存水位问题，对象在真实泄漏，就要上调试手段了。

SLUB 环境下最有效的方案就是用 slub_debug 重启。在引导参数里加上：

slub_debug=FZPOU

然后等问题复现。复现后去 /sys/kernel/slab/<出问题的缓存>/ 目录查看 alloc_calls 和 free_calls。前者会告诉你这些对象都是在内核栈的哪些路径上被分配的，后者告诉你释放路径。如果 alloc_calls 里某个函数路径占比异常高、free_calls 里几乎不出现对应路径，那基本就是泄漏点。

比如我曾经定位一个问题，看到 alloc_calls 里全是 tcp_sendmsg 路径，free_calls 却空空如也，最后发现是某个版本内核 TCP 错误路径里没有释放 skb，导致发送队列里的对象全部累积。这个结论拿到后，问题解决窗口直接缩小到那个错误分支。

另一个可用的工具是 kmemleak。需要内核开启 CONFIG_DEBUG_KMEMLEAK：

echo scan > /sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak

它会扫描内存中孤儿对象，报告疑似未释放的内核内存块。kmemleak 的缺点是误报不少，但它给出的调用栈信息在做第一轮粗筛时非常有价值。

6.3 场景三：SLOB 系统下没法用 slabinfo 怎么办

如果你管理的是嵌入式设备，而且内核确实用的是 SLOB，那么很多 slab 查询手段都失效了。因为 SLOB 没有 /proc/slabinfo，也没有 /sys/kernel/slab 目录。你只能从整体内存增长趋势去推断，非常被动。

这时候我建议你重新评估内核配置。如果设备内存还够，尽量切到 SLUB。SLUB 虽然多一点元数据开销，但换来的是可观测性。嵌入式系统调试本来就难，再砍掉 slab 调试手段，出了问题只能抓瞎。有一些 buildroot 老工程喜欢默认选 SLOB，作为一种“省内存”的软配置，这里我得泼盆冷水：省的那点内存可能还没你一次内存泄漏浪费的多。

6.4 常见问题速查表

7. 几个值得记住的底层细节

很多朋友在看完前面这些内容后，可能会问：那我到底该记住哪些东西？我觉得有几条经验是可以长期用的。

第一，slab 不是只有 SLAB。SLAB 是具体的一种实现，slab 这个词已经泛化成“内核对象缓存机制”的意思。你日常说“查一下 slab”，大概率在查的是 SLUB 分配器还在正常工作的状态。

第二，per-CPU 缓存是现代内核高性能分配的灵魂。无论 SLAB 的 array_cache 还是 SLUB 的 per-CPU partial，本质上都是把分配频率高的对象留在本 CPU 手里，尽量避免锁和缓存一致性开销。理解这一点，你就能看懂为什么某些场景下绑核之后分配性能会提高。

第三，slab 可回收不代表会及时回收。内核有个 vfs_cache_pressure 参数控制 dentry/inode 缓存的回收倾向，默认值 100。如果你的系统内存紧张但文件缓存还占着一堆内存，可以适当调高这个参数，比如 200。但别调到太高，否则每次文件操作都会频繁重建缓存，性能反而下降。

还有一个我踩过的坑：不要在生产环境轻易开启 slub_debug=FZPOU 长期运行。开启后每个对象都会加红区、毒化、调用栈记录，内存开销和 CPU 开销都不可忽略。我曾经在一台 128GB 内存的机器上开全量 SLUB 调试跑了一周，Slab 直接多占了接近 2GB 内存，业务延迟也有明显抖动。正确做法是：让问题先复现，再开调试抓现场，问题定位完立刻恢复正常内核启动。

这套东西其实没有太多玄学。它背后就是一个朴素的道理：内核把最常用的工具放在最顺手的地方，尽量少打扰别人。SLUB 之所以能成为默认选择，靠的也正是这种“少做无用功”的克制。如果你正在排查一个诡异的内存问题，别急着怀疑上层应用，先到 slab 里看一眼，很多时候答案就写在对象数量曲线里。