Python：mimalloc 替代 pymalloc：支撑 dict 和 list 乐观无锁访问的新分配器

一、问题的起点：为什么 pymalloc 撑不住 free-threading

要理解 CPython 为什么在 3.13 引入 mimalloc，必须先回到一个被长期忽视的事实：Python 的性能叙事，很大程度上是内存分配器的叙事。CPython 对象创建极其频繁——一次 a + b 可能触发多个临时对象分配，一个 dict 插入可能触发 resize 与 rehash。分配器路径上的每一次原子操作、每一次缓存未命中，都会被放大到整个解释器的吞吐上。

pymalloc 诞生于 2001 年前后（Python 2.3 时代），其设计目标非常明确：为"大量小对象、生命周期短、单线程为主"的 CPython 工作负载提供比系统 malloc 更快、碎片更少的分配路径。它在那个时代是成功的，甚至可以说是优雅的。但 free-threading（PEP 703）改变了前提条件。

在 GIL 存在的年代，同一时刻只有一个线程执行 Python 字节码，分配器面对的并发压力主要来自 C 扩展与 I/O 线程，锁竞争被 GIL 天然"挡"在了外面。一旦 GIL 被移除，多个线程可以真正并行地创建和销毁对象，分配器瞬间从"配角"变成"关键路径上的并发热点"。本文评述：pymalloc 的问题不在于它慢，而在于它的并发模型与 free-threading 的假设不兼容——这是结构性的，不是调参能解决的。

1.1 GIL 移除带来的分配器压力重估

PEP 703 由 Sam Gross 于 2023 年提出，目标是在 CPython 中支持可选的 GIL 禁用构建。该 PEP 明确指出，移除 GIL 后，对象分配与引用计数操作将成为最主要的并发瓶颈之一。原因很直接：CPython 中几乎所有操作都涉及 Py_INCREF/Py_DECREF，而引用计数本质上是对对象头字段的读改写操作。

分配器在这里扮演双重角色：一方面它要提供线程安全的分配/释放路径；另一方面，它返回的内存布局会影响引用计数操作的缓存局部性。如果两个线程频繁操作位于同一 cache line 上的对象，即使引用计数本身用了原子操作，也会产生严重的伪共享（false sharing）。

笔者的判断是：free-threading 的真正难点不在"锁的替换"，而在"内存布局的并发友好化"。分配器恰恰是决定内存布局的那一层。

1.2 一个被低估的耦合：dict/list 的乐观访问依赖分配器

PEP 703 中一个关键技术是"乐观无锁访问"（optimistic lock-free access）。以 dict 为例：读取操作先假设没有并发写入，直接读取，然后用版本号（version tag）校验是否发生了修改；若校验失败则回退到加锁路径。list 的读取同样采用类似思路。

这套机制有一个隐含前提：被乐观读取的内存必须在读取期间保持有效且布局稳定。如果分配器在并发释放时把内存归还给操作系统、或把同一块内存立即复用给另一个线程，乐观读取就可能读到"已释放但未失效"的数据，导致难以复现的崩溃。

这正是 mimalloc 的"延迟释放"（deferred free）机制的价值所在——它通过线程本地 free 列表与周期性回收，显著降低了内存被立即复用的概率，为乐观读取提供了更宽的安全窗口。本文将在第四章展开这条主线。

分配器与并发数据结构的关系，类似 CPU 缓存与内存模型的关系：上层协议再精巧，底层不配合就会失效。这是本文贯穿始终的分析主线。

二、pymalloc 解剖：arena、pool 与 size class 的三层结构

要讲清楚 mimalloc 带来了什么，得先把 pymalloc 的结构拆开。pymalloc 的源码主要集中在 Objects/obmalloc.c，其核心是三层结构：arena → pool → block。

2.1 arena：256 KiB 的内存单元

pymalloc 以 256 KiB 为单位向操作系统申请内存，称为一个 arena。arena 内部被划分为若干 pool，每个 pool 默认 4 KiB（一个虚拟内存页大小）。所有 arena 通过双向链表串联，每个 arena 记录自己的空闲 pool 数量。

这种设计的优点是：arena 对齐到 256 KiB 边界后，可以通过指针位运算快速定位所属 arena（arena = ptr & ~(256K-1)），无需额外查表。这在单线程下是极快的。

2.2 pool 与 size class：固定尺寸的分配单元

pymalloc 将小对象（≤512 字节）划分为 64 个 size class，每个 size class 对应一个固定 block 大小（8 字节对齐，如 16、32、48……512）。每个 pool 只服务一个 size class，pool 内的 block 大小统一，通过单向链表管理空闲 block。

这种"一个 pool 一个 size class"的策略消除了外部碎片（不同大小对象混放），但引入了内部碎片：申请 33 字节会得到 48 字节的 block，浪费约 31%。对于 CPython 这种对象大小分布集中的负载，内部碎片总体可接受。

层级	典型大小	管理方式	并发保护
arena	256 KiB	全局双向链表	全局锁
pool	4 KiB	按 size class 归属	全局锁
block	8–512 B	空闲单链表	全局锁

表格说明：pymalloc 三层结构均依赖同一把全局锁保护，这是其在多线程下的根本瓶颈。数据来源为 CPython 源码 Objects/obmalloc.c 的结构定义。

2.3 全局锁：单线程优化的代价

pymalloc 在多线程下的策略是：每个线程有一个小的本地缓存（thread-local free list），但一旦本地缓存耗尽或溢出，就要获取全局锁。在 GIL 时代，这几乎不成问题，因为同一时刻只有一个线程在跑 Python 字节码。但 free-threading 下，多个线程会同时耗尽本地缓存，全局锁成为串行点。

本文评述：pymalloc 的全局锁不是为了并发正确性而设计的，而是为了"在 GIL 保护下简化实现"而设计的。当 GIL 消失，这把锁就从"几乎不竞争"变成"高频竞争"，其成本被彻底暴露。

2.4 碎片化的长期累积问题

pymalloc 的 arena 一旦分配就很少归还操作系统，即使内部 pool 全部空闲。这意味着长时间运行的服务进程会出现"内存只增不减"的现象。对于多线程场景，不同线程的分配模式差异会加剧 arena 之间的碎片分布不均。

社区中大量关于"Python 进程内存不释放"的讨论，根源多在此。mimalloc 的页级回收机制正是针对这一点设计的。

三、mimalloc 设计哲学：分段页、线程本地堆与延迟释放

mimalloc 由微软研究院的 Daan Leijen 主导开发，最初发表于 2019 年的论文《Mimalloc: Free List Sharding in Action》。它的设计目标与 pymalloc 截然不同：从一开始就面向多核、高并发、长时间运行的服务负载。

3.1 核心创新：free list sharding（空闲列表分片）

mimalloc 最核心的设计是 free list sharding。传统分配器为每个 size class 维护一个全局空闲列表，多线程访问需要加锁。mimalloc 的做法是：把每个 size class 的空闲列表拆分成多个"分片"（shard），每个分片绑定到一个线程本地堆（thread-local heap）。

这样，绝大多数分配/释放操作只触及线程本地数据结构，无需任何原子操作或锁。只有当线程本地堆需要向全局堆"借"或"还"内存时，才涉及同步。这被称为"分片式空闲列表"，是 mimalloc 高并发性能的主要来源。

本文评述：free list sharding 的本质是把"锁竞争"转化为"空间换时间"——每个线程持有独立分片，牺牲少量内存利用率换取近乎无锁的分配路径。这与 tcmalloc 的 thread cache 思路同源，但 mimalloc 在分片粒度与回收策略上做了更激进的优化。

3.2 分段页（segmented pages）：更细的回收粒度

pymalloc 的回收粒度是 256 KiB 的 arena，mimalloc 则使用更小的"段"（segment），通常为 64 KiB，并进一步划分为页（page）。每个页服务一个 size class，页内 block 通过本地空闲列表管理。

关键差异在于：mimalloc 可以单独回收一个空闲的页或段，将其归还给操作系统或全局堆。这大幅改善了长时间运行进程的内存占用曲线。根据 mimalloc 官方基准测试（Leijen, 2019），在多种负载下 mimalloc 的内存占用比系统 malloc 低 10%–30%，且峰值内存更稳定。

维度	pymalloc	mimalloc
分配单元	arena 256 KiB	segment 64 KiB
空闲列表	全局 + 线程缓存	分片式，线程本地
并发路径	全局锁	多数无锁
内存归还	几乎不归还	页级延迟归还
安全特性	基础	加密空闲列表、守卫页

表格说明：对比数据基于两者官方文档与源码结构整理。mimalloc 的安全特性（如 free list encoding）在默认构建中启用，用于缓解 use-after-free 类漏洞。

3.3 延迟释放与安全窗口

mimalloc 的释放路径并非立即把内存放回全局可用池，而是先进入线程本地的延迟释放队列（deferred free list），在后续分配或周期性回收时才真正合并。这个"延迟"看似是性能优化，实际上对并发安全有额外价值。

在乐观无锁读取场景下，一个线程可能正在读取某块内存，而另一个线程刚刚释放了它。如果分配器立即复用该内存，读取方就可能读到被覆盖的数据。延迟释放拉长了"释放到复用"的时间窗口，降低了这种竞态的实际发生率。

笔者认为：这是 mimalloc 与 free-threading 之间最容易被忽视的协同点。它不是一个显式的安全机制，而是一个"概率性缓解"——不能替代正确的内存序设计，但能显著降低工程实现中的风险暴露。

3.4 与 tcmalloc、jemalloc 的定位差异

在通用分配器领域，Google 的 tcmalloc 与 Meta 的 jemalloc 是两大主流。tcmalloc 强调 thread cache 与中央堆的分层；jemalloc 强调 size class 精细化与 arena 分区。mimalloc 的差异化在于：更小的元数据开销、更激进的本地化、以及内置的安全缓解。

对于 CPython 而言，选择 mimalloc 而非 tcmalloc/jemalloc，笔者推测有几个现实考量：mimalloc 代码量小、易于集成到 CPython 构建系统；其 API 与系统 malloc 高度兼容；且微软提供了成熟的跨平台支持。CPython 核心开发者在其讨论中（如 GitHub issue #116022 相关讨论）也提到 mimalloc 在 Windows 平台上的表现优势。

四、核心主线：分配器如何决定 dict/list 的无锁上限

这一章是全文的分析核心。我们要回答一个具体问题：为什么说 mimalloc 是 dict/list 乐观无锁访问的"物理支撑"？

4.1 dict 的内存布局与并发读取

CPython 3.6 之后，dict 采用"紧凑布局"：一个索引表（indices）加一个条目数组（entries）。entries 按插入顺序存储键值对，indices 存储哈希到 entries 下标的映射。读取时先查 indices，再访问 entries。

在 free-threading 下，dict 的读取采用乐观策略：不加锁读取 indices 和 entries，读取前后检查版本号。如果版本号变化，说明发生了并发修改，重试或加锁。这套机制要求 entries 数组在读取期间不被释放或移动。

当 dict 扩容时，会分配新的 entries 数组，旧数组需要延迟释放——因为可能有读者仍持有指向旧数组的指针。如果分配器立即复用旧数组的内存，读者就可能读到新数组的数据，导致逻辑错误。

4.2 list 的 resize 与读者安全

list 的问题类似但更直接。list 底层是 PyObject **ob_item 指针数组。当 list 增长超过容量时，会分配更大的数组、拷贝元素、释放旧数组。

在无锁读取下，读者可能正在遍历旧数组。PEP 703 的实现中，list 的读取同样使用乐观策略，依赖版本号检测并发修改。但版本号只能检测"逻辑修改"，无法阻止"内存被复用"。

这就回到分配器的角色：如果旧数组的内存被立即复用，读者可能读到看似合法但实际错误的数据，版本号检查也无法挽救。mimalloc 的延迟释放机制在这里提供了实质性的缓解。

4.3 从"逻辑无锁"到"物理无锁"的鸿沟

很多关于无锁数据结构的讨论停留在算法层面：CAS 循环、版本号、内存序。但真正的工程实现必须回答一个更底层的问题：内存从哪里来，到哪里去，什么时候可以被复用。

笔者把这个问题称为"逻辑无锁"与"物理无锁"的鸿沟。算法层面可以设计出完全无锁的 dict/list 访问协议，但如果底层分配器在释放后立即复用内存，协议的正确性就无法保证。反之，一个具有延迟释放、线程本地分片的分配器，能为上层协议提供更宽松的实现空间。

本文的核心论点：分配器不是并发数据结构的"外部依赖"，而是其正确性边界的一部分。CPython 选择 mimalloc，本质上是在为 PEP 703 的无锁承诺购买"物理保险"。

4.4 引用计数与分配器的交互

CPython 的引用计数在 free-threading 下采用"偏向引用计数"（biased reference counting）方案：对象有一个本地引用计数和一个共享引用计数。本地计数由拥有对象所有权的线程无锁修改，共享计数用原子操作。

分配器在这里影响的是对象头的缓存局部性。如果分配器把频繁交互的对象放在相邻内存，引用计数操作的 cache line 争用会加剧；如果分配器倾向于把不同线程的对象分散到不同页，则能降低伪共享。mimalloc 的线程本地堆天然具有这种"分散"效果。

本文评述：这是一个典型的"分配器策略影响上层并发性能"的案例。它说明分配器的选择不能只看分配吞吐，还要看它如何塑造对象的内存分布。

五、PEP 703 语境下的分配器协同：引用计数、GC 与内存序

PEP 703 是一个庞大的工程，涉及引用计数、GC、对象布局、锁策略等多个子系统。分配器只是其中一环，但它的影响会传导到其他环节。

5.1 循环 GC 与分配器的内存可见性

CPython 的分代 GC 需要遍历对象图，检测循环引用。在 free-threading 下，GC 遍历必须与并发修改协调。GC 会暂停世界（stop-the-world）或采用增量策略，但无论哪种，它都需要读取对象头与引用字段。

如果分配器频繁移动对象（如某些压缩型 GC），GC 的复杂度会急剧上升。mimalloc 不移动已分配对象，这简化了 GC 的实现。这一点在 CPython 的分配器选型中是一个隐性加分项。

5.2 内存序与分配器的原子操作

无锁编程离不开内存序（memory ordering）。C11/C++11 定义了 relaxed、acquire、release、seq_cst 等语义。分配器内部的原子操作会与上层数据结构的原子操作产生交互。

例如，一个线程释放对象（release 语义），另一个线程获取该对象（acquire 语义），这构成 synchronizes-with 关系。如果分配器在释放路径上插入了额外的原子操作，可能改变这种关系的时序。mimalloc 的设计尽量减少分配路径上的原子操作，这有利于上层保持清晰的内存序推理。

笔者认为：分配器的"原子操作预算"是一个值得关注的指标。分配路径上每多一个原子操作，上层无锁算法的正确性推理就多一层复杂度。mimalloc 把原子操作集中在跨线程边界，而非每次分配，这是它适合 free-threading 的重要原因。

5.3 与 PEP 684（子解释器）的潜在协同

PEP 684 为 CPython 引入了每解释器 GIL，允许多个子解释器并行运行。这与 free-threading 是两条不同的并发路线，但都面临分配器竞争问题。mimalloc 的线程本地堆设计对子解释器场景同样友好——每个子解释器可以在自己的线程上运行，天然受益于分片式空闲列表。

社区中有观点认为，mimalloc 的引入同时服务于 PEP 703 和 PEP 684 两条路线，是一个"一石二鸟"的基础设施投资。这一判断在 CPython 的构建选项设计中有所体现。

六、工程实践：编译、启用与调优 mimalloc 的完整路径

理论讲完，进入可操作部分。这一章给出从源码编译到运行时调优的完整步骤。

6.1 确认你的 Python 是否已启用 mimalloc

Python 3.13 起，mimalloc 是可选构建项。可以通过以下方式检查：

python -c "import sys; print(sys._is_mimalloc_enabled())"

注意：该接口在不同版本中可能名称不同。更通用的方法是检查构建配置：

python -c "import sysconfig; print(sysconfig.get_config_var('WITH_MIMALLOC'))"

若返回 1 或 True，表示已启用。若为 None 或 0，则需要自行编译。

6.2 从源码编译启用 mimalloc

在 Linux 上，标准流程如下：

# 1. 获取 CPython 源码（以 3.13 为例）
git clone --depth 1 --branch v3.13.0 https://github.com/python/cpython.git
cd cpython

# 2. 配置构建，启用 mimalloc
./configure --with-mimalloc --enable-optimizations

# 3. 编译（-j 根据 CPU 核心数调整）
make -j$(nproc)

# 4. 验证
./python -c "import sysconfig; print(sysconfig.get_config_var('WITH_MIMALLOC'))"

对于 free-threading 构建，需要额外加上 --disable-gil：

./configure --with-mimalloc --disable-gil --enable-optimizations
make -j$(nproc)

需要注意的是，free-threading 构建目前仍标记为实验性，部分 C 扩展可能不兼容。建议在隔离环境中测试。

6.3 运行时环境变量调优

mimalloc 提供了一组环境变量用于运行时调优。以下是几个实用的：

环境变量	作用	建议值
MIMALLOC_SHOW_STATS	进程退出时打印统计	1（调试时）
MIMALLOC_PURGE_DELAY	延迟归还内存的毫秒数	默认 10，可调高
MIMALLOC_EAGER_COMMIT	是否立即提交内存	0（省内存）
MIMALLOC_RESERVE_HUGE_OS_PAGES	预留大页数量	按负载调整

表格说明：环境变量名称与默认值来自 mimalloc 官方文档（github.com/microsoft/mimalloc）。实际调优需结合负载特征。

6.4 迁移检查清单

从 pymalloc 迁移到 mimalloc，建议按以下步骤进行：

1. 基线测量：在现有 pymalloc 构建上跑通你的基准测试，记录吞吐、延迟、峰值内存。
2. 构建 mimalloc 版本：按 6.2 步骤编译，保持其他配置一致。
3. 功能验证：跑完整测试套件，重点关注 C 扩展与多线程代码。
4. 性能对比：用相同基准测试对比，注意区分单线程与多线程场景。
5. 内存观测：长时间运行，观察 RSS 曲线是否更平稳。
6. 灰度上线：先在非关键服务验证，再逐步扩大。

七、实测方法论：如何科学地对比两种分配器

性能对比最容易被做错。这一章给出方法论，帮助读者得到可信结论。

7.1 基准测试的选择

通用基准如 pyperformance 覆盖了多种负载，但对分配器差异的敏感度不一。建议补充针对性的微基准：

• dict 密集：大量键值插入、删除、查找。
• list 密集：频繁 append、resize、切片。
• 对象创建：短生命周期对象的批量创建与销毁。
• 多线程混合：多线程同时进行上述操作。

需要注意的是，微基准容易受 CPU 缓存、NUMA 等因素干扰，应结合真实业务负载验证。

7.2 测量指标

建议至少采集以下指标：

指标	含义	采集方式
吞吐	单位时间操作数	基准框架自带
P99 延迟	尾部延迟	perf / 自研计时
RSS 峰值	常驻内存峰值	/proc/self/status
分配次数	总分配调用数	MIMALLOC_SHOW_STATS
锁竞争	等待时间占比	perf lock / eBPF

表格说明：指标选择参考了分配器评测的通用实践。锁竞争指标在 free-threading 构建下尤其重要。

7.3 避免常见陷阱

几个容易踩的坑：

• 热身不足：JIT 与缓存需要预热，至少跑 3 轮取后两轮。
• CPU 频率漂移：固定频率或记录实际频率。
• NUMA 干扰：多路服务器上绑定 CPU 与内存节点。
• 只看平均值：分配器差异常体现在尾延迟，务必看 P99。
• 忽略构建差异：确保两次构建除分配器外其他选项一致。

本文评述：分配器性能对比的难点在于"噪声大、差异小"。如果基准测试本身波动超过 5%，就很难得出可靠结论。建议用统计方法（如多轮取中位数、置信区间）而非单次结果下判断。

八、前沿预判：分配器与解释器解耦的下一步

站在 2024–2025 的时间点，可以看到几条清晰的演进线索。

8.1 分配器作为可插拔组件

CPython 目前把 mimalloc 作为编译期选项。未来是否可能做成运行时可选？这涉及 ABI 兼容性与性能开销。笔者认为，短期内编译期选项仍是主流，因为运行时切换会引入间接调用开销，抵消分配器优化的收益。

8.2 硬件辅助的内存管理

ARM 的 MTE（Memory Tagging Extension）与 Intel 的 CET 提供了硬件级的内存安全检测。分配器可以利用这些特性实现更细粒度的 use-after-free 检测。mimalloc 已经在部分平台探索了相关集成。对于 free-threading 场景，硬件标签可以帮助捕获乐观读取中的内存复用错误。

8.3 与 Rust 生态的交叉影响

Rust 的所有权模型在编译期消除了大量内存安全问题，但其分配器生态同样在演进。mimalloc 有 Rust 绑定，且在 Rust 社区中被广泛用于替代系统分配器。CPython 与 Rust 在分配器层面的经验可以互相借鉴——尤其是"延迟释放"与"线程本地分片"这两个概念。

8.4 free-threading 的成熟时间表

PEP 703 明确将 free-threading 定位为"长期实验"。CPython 核心团队的目标是在数个版本内逐步稳定。分配器作为基础设施，其稳定性直接影响 free-threading 的可用性。mimalloc 的引入是一个积极信号，但距离"默认启用"仍有距离。

笔者认为：未来 2–3 年，free-threading 的进展将主要取决于三个子系统的协同成熟——引用计数、GC、分配器。分配器是其中最"底层"也最容易被忽视的一环，但它决定了上层能走多远。

九、结论与可操作清单

回到文章开头的问题：为什么 CPython 要用 mimalloc 替代 pymalloc？答案不是"mimalloc 更快"这么简单，而是"pymalloc 的并发模型与 free-threading 不兼容，而 mimalloc 的设计恰好补上了这块短板"。

具体来说，mimalloc 通过 free list sharding 消除了大部分锁竞争，通过分段页改善了内存归还，通过延迟释放为乐观无锁读取提供了安全窗口。这三点共同支撑了 dict/list 在 free-threading 下的无锁访问承诺。

给读者的可操作清单：

1. 检查你的 Python 版本与构建选项，确认是否已启用 mimalloc。
2. 若未启用，按第六章步骤从源码编译，先在测试环境验证。
3. 用第七章的方法论做基线对比，重点关注多线程与尾延迟。
4. 关注 CPython 官方关于 free-threading 的进展，评估迁移时机。
5. 在 C 扩展开发中，注意分配器假设的变化，避免依赖 pymalloc 特有行为。

十、参考文献与拓展资源

主要参考文献（8 篇）

1. Leijen, D., Zorn, B., & de Moura, L. (2019). Mimalloc: Free List Sharding in Action. APLAS 2019. 来源：Microsoft Research 技术报告。
2. Gross, S. (2023). PEP 703: Making the Global Interpreter Lock Optional in CPython. Python Enhancement Proposals.
3. Python Software Foundation. (2024). What's New In Python 3.13. 官方发布说明。
4. CPython 源码仓库. Objects/obmalloc.c 与 Python/mimalloc 集成代码. github.com/python/cpython.
5. mimalloc 官方文档与源码. github.com/microsoft/mimalloc.
6. Boehm, H. J. (2021). Thread-local heaps and concurrent memory management. 相关综述文献。
7. Berger, E. D., McKinley, K. S., Blumofe, R. D., & Wilson, P. R. (2000). Hoard: A Scalable Memory Allocator for Multithreaded Applications. ASPLOS 2000.
8. Ghemawat, S., & Menage, P. (2005). TCMalloc: Thread-Caching Malloc. Google 技术文档。

拓展资源与教程链接

• PEP 703 原文：https://peps.python.org/pep-0703/
• mimalloc GitHub 仓库：https://github.com/microsoft/mimalloc
• CPython 构建指南：https://devguide.python.org/getting-started/setup-building/
• pyperformance 基准框架：https://github.com/python/pyperformance
• Real Python 关于 Python 内存管理的教程：https://realpython.com/python-memory-management/
• PyCon 2024 关于 free-threading 的演讲视频（YouTube 搜索 "CPython free-threading PyCon 2024"）。
• mimalloc 性能基准数据：https://github.com/microsoft/mimalloc#performance

数据说明

本文涉及的性能数据主要来自 mimalloc 官方基准测试（Leijen, 2019）与 CPython 官方发布说明。文中表格中的对比数据为基于源码结构与官方文档的整理，非本文作者实测。若读者需要具体数值，建议在自身环境中按第七章方法论复现。本文未使用任何模拟数据集。