分配器与碎片

• boundary tag 的组成（size + prev_size）
• 向前/向后合并
• 合并的时空开销权衡

dlmalloc 在每个内存块（chunk）的头部和尾部存放边界标记（beginning tag 和 end tag），包含块大小和空闲标志。利用这些标记，分配器可以快速判断相邻块是否空闲：释放一个块时，可检查其前、后相邻块的 tag，若空闲则合并成大块，从而减少外部碎片。end tag 的存在使分配器无需遍历即可找到前一个块，实现 O(1) 的向后合并。这是经典的"双向边界标记"（boundary tag）优化。

boundary tag 的价值是"以少量元数据换取 O(1) 合并"：释放时能立即知道相邻块是否空闲并合并，避免碎片积累。这也是 dlmalloc 及其后继（ptmalloc）的基础设计。

• arena 的划分与线程关联
• NUMA 本地内存分配
• 减少跨 NUMA 访问

jemalloc 将堆划分为多个 arena，每个线程默认绑定到 arena（通过线程局部变量分配 arena，或按 CPU 数创建 arena），从而减少线程间的全局锁竞争。在 NUMA 架构下，jemalloc 可感知 NUMA 节点，将 arena 与本地节点关联，使线程优先从本地节点的内存分配（避免跨内存总线访问），从而降低延迟和带宽损耗。通过 --disable-numa 或配置可关闭，但默认情况下尽力让分配贴近线程所在 CPU 的 NUMA 节点。

arena 的核心理念是"分区 + 线程本地"，NUMA-awareness 让每个线程主要使用本地物理内存，减少跨节点访问，这是 jemalloc 在 Redis、MySQL 等大量并发分配场景下性能优秀的原因之一。

• jemalloc 的 arena 设计
• mimalloc 的 free list 与分段
• 各平台适配与性能侧重

jemalloc 以 arena 和 size class 为设计核心，强调多线程下的可扩展性与低碎片，成熟稳定，在服务端（Redis、MySQL、Facebook）广泛使用。mimalloc 采用"free list 寻址 + 就地更新 + 分段（segment）"设计，用 NUMA 感知和 eager-free 等机制，强调低延迟与高吞吐，在 Microsoft 和加速器场景使用，且内存占用更小、cache 更友好。跨平台方面，两者都支持 Windows 和 Linux，但 jemalloc 在 Linux 生态更成熟，mimalloc 是微软为 Windows 优化并逐渐扩展到 Linux。实现细节（如页大小、系统调用）在不同平台有差异。

差异的本质是设计哲学：jemalloc 重可扩展性与碎片控制，mimalloc 重分配/释放的极低延迟与缓存友好。选择取决于工作负载（多线程并发 vs 低延迟）。

• size class 的粒度与对齐
• 小 vs 大对象的分界
• 碎片与内存浪费的权衡

jemalloc 将对象大小划分为一系列固定的 size class（size class），小对象按 8B 起步、16B、32B、48B、64B、80B 等递增，采用"规定对齐"（如 8 对齐、16 对齐、随大小增大对齐放宽）以减少元数据并控制碎片。size class 通常按 2 的幂次与线性间隔混合设计（如 8,16,32,48,64,80,96,...），让对齐与间隔匹配，降低内部碎片。大于某个阈值（如 4KB）的对象走大对象/大页路径，直接 mmap 或按页分配。每个 size class 有独立的缓存（bin），分配时无需搜索不同大小。

size class 的划分是"对齐粒度与内部碎片"的权衡：粒度太细元数据多，太粗内部碎片多。jemalloc 的 8/16/32/48/64/80 序列在 64 位指针下兼顾了对齐与碎片率。

• slab 的同 size 对象缓存
• 减少碎片与初始化开销
• 友好于内核高频分配

slab allocator 将内核中常用的同 size 对象（如 task_struct、inode、page 等）集中到 slab（缓存），每个 slab 是一块连续内存划分为若干固定大小的对象。优势：1）同 size 固定分配，无外部碎片，利用率高；2）对象复用，避免重复初始化构造开销（可在缓存中保持构造状态）；3）分配 O(1) 快速，减少内核高频路径的分配成本；4）云缓存友好，对象对齐。配合 per-CPU 缓存减少锁竞争。它是 Linux 内核对象缓存的标准机制。

slab 的核心是"同 size 对象专用池"，把"通用分配器的碎片与初始化"转为"固定大小专用的高速缓存"，是内核性能的关键。

• tcache 的 per-thread 缓存
• double-free 检测的 key 字段
• 安全与性能权衡

glibc ptmalloc 为每个线程维护 tcache（thread-local cache），将释放的小块（默认 <1024B）缓存到线程本地的单向链表中，分配时先查 tcache，命中则 O(1) 返回，避免触及全局锁和 bins，极大加速小对象分配释放。为检测 double-free，tcache 块中存放 key 字段（指向 tcache 自身的指针）。释放时若检测到 key 指向 tcache，则怀疑是 double-free，触发安全检查（遍历 tcache 链表确认是否已存在），从而拦截 double-free 攻击。这是 glibc 对 tcache poisoning 类漏洞的加固。

tcache 用"线程本地缓存"消除锁竞争，key 字段用"释放时验证"拦截 double-free。但这仍是可被绕过（如 tcache poisoning）的防御，说明了安全需要多层加固。

• per-thread cache 的本地缓存
• central cache 的锁
• 高通配与均衡

tcmalloc 为每个线程维护 per-thread cache（本地缓存），分配小对象时优先从本地缓存获取，无锁、极快，消除了大多数线程间的争用。当本地缓存不足（分配）或过满（释放）时，才与 central cache（中央缓存）交互，central cache 需要加锁，但通过批量传输（一次取/还多个对象）降低锁频率。高并发下，central cache 的锁仍是少数瓶颈，但 per-thread cache 的命中率通常很高，整体争用被大幅摊薄。tcmalloc 还通过补偿机制平衡各线程的缓存大小。

tcmalloc 的两级缓存设计是"以本地缓存为主、中央缓存兜底"：per-thread cache 吸收多数分配，central cache 用批量操作降低锁竞争，是典型的分层降锁策略。

• 三种搜索策略的语义
• 时间与碎片权衡
• 各自的适用场景

best-fit 选择满足需求的最小空闲块，碎片最小但需遍历整个空闲链表，时间开销大；first-fit 选择第一个满足需求的空闲块，速度快但易产生小而碎的空闲块；next-fit 从上次分配位置继续搜索，减少遍历，但碎片可能更差。dlmalloc 实际采用 best-fit 的变体并结合分离空闲链表（segregated bins）来兼顾时间与碎片。三种策略的本质是"搜索时间 vs 碎片率"的权衡。

没有绝对最优策略：best-fit 碎片少但慢，first-fit 快但碎片多，next-fit 折中。现代分配器通过分离链表（按大小分桶）把 best-fit 的搜索成本降到 O(1) 附近。

• 各分配器的设计重点
• 线程模型与锁
• 适用场景

dlmalloc 是单线程时代的基础分配器，用边界标记和分离空闲链表，无并发支持。ptmalloc2 是 glibc 基于 dlmalloc 的多线程扩展，用 arena 和 per-thread 机制（含 tcache），是 Linux 默认分配器，兼容性好但共享 arena 有锁竞争。jemalloc 用多个 arena + per-thread arena 分配 + size class，强调可扩展性与低碎片，适合高并发服务端。tcmalloc（Google）用 per-thread cache + central cache + span，强调高并发下极低延迟，为 Chrome 等优化。选择取决于负载：默认用 ptmalloc，高并发可选 jemalloc/tcmalloc。

四者差异核心在多线程模型与碎片控制：dlmalloc 单线程，ptmalloc 多 arena 加锁，jemalloc/tcmalloc 以线程本地缓存最大化并发。Redis 等场景常换用 jemalloc。

• span 的定义（连续 page 段）
• span 与 object 的关系
• 大对象与分页管理

tcmalloc 以内存页（page）为基本单位，把若干连续 page 组成一个 span（span 是连续 page 的一个段）。span 是分配的基本单元：小对象从 span 中切分，一个 span 对应一个 size class；大对象则直接由一个或多个 span 构成。span 记录其 page 范围、所属 size class、引用对象个数等，用于管理对象的分配、释放与合并。通过 span，tcmalloc 能把"page 级内存"与"对象的 size class"对应起来，实现高效分配与回收。

span 是 tcmalloc 连接"物理页"与"对象"的桥梁：它把 page 组成可分配单元，并按 size class 划分对象，使释放的对象能精确归位到所属 span。

• chunk 的元数据
• bins 的分类（fast/unsorted/small/large）
• tcache 与 bins 的关系

ptmalloc 中的 chunk 是内存块的基本单元，带元数据（prev_size、size、标志位）。bins 是存储空闲 chunk 的链表集合，按大小分类：fastbins（小且不合并）、unsorted bin（刚释放的临时缓冲）、small bins（小对象精确分类）、large bins（大对象按区间）。tcache 是线程本地的小对象缓存，优先于 bins 命中。分配时先查 tcache，再查 fastbins/unsorted/small/large，最后才向系统申请。释放时先入 tcache，满了再进 bins。

这是"多级缓存"漏斗：tcache→fastbins→unsorted→small/large→系统。越靠前越快、越少加锁，越靠后越慢但覆盖越大，实现分配性能与内存利用的平衡。

• 伙伴系统的二进制拆分
• SLAB 面向对象的缓存
• 两者的协作关系

伙伴系统是内核底层的物理页分配器，按 2 的幂次（order）把物理内存划分为伙伴对，分配时合并/拆分大块，保证连续物理页可用，是内核虚拟内存与物理内存映射的基础。SLAB（及 SLUB/SLOB）是构建在伙伴系统之上的对象缓存分配器，把一页或多页切成固定大小的对象，为内核常用对象（如 task_struct、inode）提供高速、低碎片的缓存。二者协作：伙伴系统负责"页"，SLAB 负责"页内对象"，上层（kmalloc/vmalloc）在此基础上分配。

伙伴系统解决"连续物理页的分配与回收"，SLAB 解决"小对象的高速缓存"。两者是"页级"与"对象级"的分层协作，兼顾了物理连续性与分配效率。

• 查找顺序（tcache→fastbins→unsorted→small/large）
• tcache 优先的语义
• 性能原因

malloc 时查找顺序为：tcache → fastbins → unsorted bin → small bins → large bins → 系统申请。free 时先入 tcache，tcache 满后再放入 fastbins/unsorted bin。tcache 命中时不会再去 bins 查找，因为 tcache 是每个线程本地且无锁的最快缓存，直接返回即可满足需求，无需再遍历需要加锁的全局 bins。这也保证了分配的确定性与高性能：优先命中线程本地缓存，避免不必要的锁与遍历开销。

顺序体现了"快慢分级"：越靠前越无锁越快，命中即返回。tcache 命中即结束查找，是"最优路径优先"的体现，避免把最常命中的分配引向慢路径。

• extent 与 arena 缓存
• dirty page decay
• madvise(MADV_DONTNEED) 与 RSS 下降

jemalloc 用 extent 管理大块内存，释放的对象不会立即归还系统，而是缓存在 arena 的空闲 extent 中，以便快速复用。因此进程 free 后 RSS 不会立即下降。dirty page decay 机制指：arena 中缓存有空闲 extent 的 dirty page 会随时间递减，当达到 decay 阈值（如 10s）后，jemalloc 通过 madvise(MADV_DONTNEED) 或 MADV_FREE 把未使用的 dirty 页归还内核，内核才释放这些物理页，使 RSS 下降。这是"缓存复用 + 延迟回收"的协同：既保性能又逐步释放内存。

RSS 不立即下降是分配器"缓存延迟归还"的必然结果。decay + madvise 在"复用速度"与"内存占用"之间折中，是 jemalloc 内存管理的关键机制。

• mimalloc 的性能优势
• 微软对 mimalloc 的采纳
• 与系统 CRT 分配器的对比

mimalloc 由微软开发，设计上注重低延迟、高吞吐、低内存占用，且实现相对简洁、缓存友好。微软将其纳入 Visual Studio 2019+ 的工具链并提供支持，开发者可选用它替换 C/C++ 运行时的默认分配器（如通过链接替换 CRT 的 malloc），因其在常见工作负载下性能优于旧版 CRT 的 malloc，且对 Windows 的分配行为做了优化。其设计（free list 寻址、就地更新、分段）在 Windows 上表现稳定，故被微软生态推荐使用。

mimalloc 被集成推荐是"性能实测 + 平台适配"的结果：微软在自己的生态里提供自家优化过的分配器，开发者按需选用即可提升程序性能，但它并非替换 CRT 的强制默认。

• 内部碎片（分配粒度大于需求）
• 外部碎片（空闲块不连续）
• 缓解手段

内部碎片指分配对象比实际需求大产生的浪费（如分配 17B 却占 32B 的 size class），源于对齐与固定 size class；外部碎片指空闲内存总量足够但分散成不连续小块，无法满足连续大块分配，源于频繁分配/释放导致的小块交错。缓解：内部碎片靠合理 size class 与对齐设计；外部碎片靠合并（boundary tag）、分离空闲链表、紧凑（compaction）、对象池固定大小等。分配器（jemalloc/tcmalloc）通过分区与缓存同时缓解两者。

内部碎片是"粒度对齐"的必然代价，外部碎片是"分配历史"的积累结果。缓解策略核心是"减少浪费 + 提高连续性"。

• 内存池的概念
• 对象池的复用
• 减少系统调用与锁

内存池（memory pool）是预先分配一块大内存，在其上按需切分小块，减少频繁 malloc/free 的系统调用与分配器开销；对象池（object pool）则专门复用对象，向池中借出/归还对象，避免重复构造与析构，也避免频繁的堆分配。两者都通过"预分配 + 复用"减少分配开销，并降低碎片与锁竞争，适合高频分配、对象生命周期短暂且可预测的场景（如网络请求、游戏实体）。

内存池/对象池的本质是"把分配从运行时摊销到预分配"，通过复用消灭重复的分配与初始化成本，是高频路径性能优化的常用手段。

• 高频分配场景的痛点
• 内存池的优化思路
• 实际应用

在高频分配场景（如网络协议栈、游戏引擎、数据库查询、消息中间件），频繁 malloc/free 会带来系统调用、锁竞争、缓存失效和碎片。内存池通过：1）一次性预分配大块内存，之后 O(1) 分配；2）固定大小池减少碎片与元数据；3）线程本地池避免锁竞争；4）对象复用缓存热对象。这些手段把分配延迟降到最低，并提升缓存命中率，是高性能系统的关键优化。典型如 jemalloc 的 arena、Netty 的 PooledByteBuf、游戏引擎的实体池。

内存池优化是"固定大小 + 预分配 + 复用 + 线程本地"的组合拳，针对高频场景的分配瓶颈做针对性消除。