Linux SLUB 分配器深度拆解:malloc 背后内核在干什么?

读完本文，你会搞懂：你每次调用 malloc() 时，Linux 内核从哪个 slab 缓存里给你切出一块内存，SLUB 和 SLAB、SLOB 有什么区别，以及为什么说 SLUB 是当前内核的主流之选。

每个写过 C 语言的工程师都知道 malloc()。但很少有人问：当你在用户态调用 malloc(64) 时，内核那一层究竟发生了什么？

用户态的 malloc()（glibc ptmalloc / jemalloc / tcmalloc）已经是一套复杂的缓存体系——但最终，当你分配大块内存或 arena 耗尽时，它还是会通过 mmap() 或 brk() 向内核要内存。

而内核拿到这些物理页面后，如何管理大大小小的内核对象——进程描述符 task_struct、inode、dentry、网络 socket 缓冲区？这些对象尺寸小（几十到几百字节）、创建销毁频繁，直接用页分配器（buddy system）来管？太浪费了——一个 task_struct 不到 2KB，却要占用一整个 4KB 页面。

这就是 slab 分配器 的由来。

先说一个关键事实：内核不能有外部碎片。

用户态的内存碎片，大不了进程退出就释放了。内核不同——内核对象生命周期差异巨大，有的存活几微秒，有的伴随系统整个运行周期。如果用页分配器直接切，很快就会出现「有足够空闲页，但没有连续空间能满足一个请求」的死局。

slab 的思想非常简单：把同一类对象放在一起。

每个「slab 缓存」只服务于一种固定大小的对象。比如 kmalloc-64 这个缓存只分配 64 字节的块，kmalloc-128 只分配 128 字节的块。从 buddy system 申请的物理页面被切成等尺寸的 slot，分配时直接取一个 slot，释放时还回去。

SLAB（1994 年引入） 是 SunOS 的发明，包含三个概念：

• cache：一类对象的缓存（如 task_struct_cache）
• slab：一个或多个连续的物理页，被切成等尺寸的 object
• object：一个可分配的内存块

SLAB 的问题是：它维护了一个复杂的每 CPU 对象队列、着色（coloring）机制来提高缓存命中率，代码量巨大（~4000 行），而且在大 NUMA 系统上维护开销极高。

SLUB（2007 年合入 2.6.22） 的出现就是为了干掉 SLAB 的过度设计。Christoph Lameter 在提交时说了一句话：

"SLUB 将 SLAB 的复杂性减少了约 60%，同时性能在大多数场景下相当或更好。"

现在的 Linux 内核里：

• SLUB：默认分配器（几乎所有主流发行版）
• SLAB：历史遗留，可选
• SLOB：针对极小内存系统（嵌入式），2024 年已被移除

SLUB 之所以简练，是因为它只用三个核心数据结构就描述了全部状态：

struct kmem_cache {      ← 一种类型的 slab 缓存
    struct slab *cpu_slab;  ← 当前 CPU 正在用的 slab
    struct kmem_cache_node *node[MAX_NUMNODES]; ← 每 NUMA 节点的管理结构
    ...
};

struct slab {             ← 一组连续的物理页面
    struct list_head list;  ← 在 partial/full 链表中
    unsigned long objects;  ← slab 中的对象总数
    void *freelist;         ← 指向第一个空闲对象的指针
    ...
};

关键的概念只有一个指针：freelist。

每个 slab 的空闲对象通过 freelist 指针串成一个单向链表。分配时，取 freelist 头部的对象，freelist 指向下一个空闲对象。释放时，把对象放回 freelist 头部。

就这么简单。没有 SLAB 里复杂的每 CPU 对象队列、没有着色数组。

#### 三种 slab 状态

一个 kmem_cache 管理的所有 slab 被分成三个链表：

┌─────────────────────────────────────────────────┐
│  kmem_cache                                       │
│                                                   │
│  partial  ──→ [slab] → [slab] → [slab]  ← 快分配 │
│  full     ──→ [slab] → [slab]           ← 不能分 │
│  (partial)└── 只有部分 object 被占用               │
└─────────────────────────────────────────────────┘

• full：所有 object 已被占用，不能分配新对象
• partial：部分 object 空闲，可分配——这是分配性能的命脉
• empty（没有单独链表，释放后自动放到 partial 末尾）：全空闲的 slab，但 SLUB 倾向于保留它
• 
  

当你调用 kmalloc(64, GFP_KERNEL) 时，内核从 kmalloc-64 这个 cache 里分配。让我们追踪 kmem_cache_alloc() 的完整路径（简化版）：

// mm/slub.c - 极度简化，保留核心逻辑

void *kmem_cache_alloc(struct kmem_cache *s, gfp_t gfpflags)
{
    void *object;
    struct slab *slab;
    unsigned long flags;

    local_irq_save(flags);          // 关中断，防抢占

    slab = s->cpu_slab;             // 1. 拿当前 CPU 正在用的 slab

    if (unlikely(!slab || !slab->freelist)) {
        // 2. 当前 slab 满了 → 从 partial 链表拿一个新的
        slab = get_partial(s, node);
        if (!slab) {
            // 3. partial 也空了 → 从 buddy 系统申请新页
            slab = new_slab(s, gfpflags);
        }
        s->cpu_slab = slab;
    }

    object = slab->freelist;                // 4. 取出 freelist 头部对象
    slab->freelist = get_freepointer(s, object); // 5. freelist 指向下一个

    local_irq_restore(flags);

    return object;
}

性能关键路径只有 4 步：

1. 读 cpu_slab——当前 CPU 正在用的 slab，这个 slab 大概率在 L1 cache 里
2. 检查 freelist——唯一需要的分支预测
3. 取出对象，更新指针——两条内存操作
4. 返回

在热路径上，这只需要 ~50-80 条 CPU 指令。这就是为什么 kmalloc() 在内核态如此之快——大多数情况下不涉及加锁，不涉及链表遍历，甚至不走 buddy system。

#### 关键函数：get_partial()

static struct slab *get_partial(struct kmem_cache *s, int node)
{
    struct slab *slab;

    // 先看当前 NUMA 节点的 partial 链表
    slab = get_partial_node(s, &s->node[node]);
    if (slab)
        return slab;

    // 当前节点没有 → 从其他节点偷（内存访问代价高但可接受）
    return get_any_partial(s, node);
}

这个「先本节点，再远程节点」的策略保证了 NUMA 亲和性——进程在哪颗 CPU 上跑，就从哪个 NUMA 节点分配内存，避免跨节点访问的延迟惩罚。

释放比分配更简单：

void kmem_cache_free(struct kmem_cache *s, void *object)
{
    struct slab *slab;
    unsigned long flags;

    local_irq_save(flags);

    slab = virt_to_slab(object);            // 1. 从虚拟地址反查 slab
    set_freepointer(s, object, slab->freelist); // 2. 指向当前 fre
    slab->freelist = object;                // 3. 对象成为新的 freelist 头

    // 4. 如果 slab 从 full 变成 partial，移入 partial 链表
    if (unlikely(slab_free_hook(s, slab, object)))
        discard_slab(s, slab);

    local_irq_restore(flags);
}

唯一的「重量级」操作是第一步 virt_to_slab()——需要通过 struct page 的 slab_cache 字段反查。但因为内核页表是直接映射的，virt_to_page() 只是一次数组索引查找，开销极小。

这就是为什么从 2007 年起，所有主流 Linux 发行版都默认使用 SLUB。它的设计哲学非常马斯克——质疑每一步存在的必要性，然后删掉所有不必要的东西。

你可以用 slabtop 命令实时查看系统 slab 使用情况：

$ slabtop -o

重点关注这几列：

• ACTIVE：正在使用的对象数
• TOTAL：总对象数
• SIZE：每个对象大小
• CACHE NAME：缓存名称

常见故障排查场景：

1. dentry/inode 缓存疯涨 → 文件句柄泄漏
2. 
   

   # 查看 dentry 和 inode 缓存
   slabtop -s c | grep -E "dentry|inode"

如果 dentry 占用持续增长不回落，大概率是某个进程没有 close fd。

1. kmalloc-128 暴涨 → 可能是内核模块内存泄漏

  对比 slabtop 两次快照，看哪个 cache 的 TOTAL 在持续增长。

1. 清理可回收 slab 缓存
2. 
   

   echo 2 > /proc/sys/vm/drop_caches

  但注意：这只能清理完全空闲的 slab，partial slab 不会被回收。

总结三点：

1. SLUB 是默认选择——内核里跑着 SLUB，你日常的 malloc → brk → 页分配器 → SLUB 是一条完整链路
2. 核心设计极简——一个 freelist 指针搞定分配和释放，没有多余的复杂性
3. 调试也不难——slabtop + drop_caches + 对比分析，基本能搞定 90% 的 slab 问题

下一篇预告：我们讲 Page Cache——你 read() 一个文件，内核怎么从磁盘读到内存、page cache 如何避免重复 I/O、以及 dirty page 回写的完整路径。关注别错过。

你在工作中遇到过 slab 相关的 OOM 吗？或者排查过哪些诡异的内存问题？留言说说，我选 3 条置顶。 👇