一文搞懂 Python 处理大量数据的底层原理

配置环境就卡半天，跑个脚本内存直接爆表，是不是你的日常？别急，今天不聊虚的，咱们直接钻进 CPython 的官方源码仓库，扒一扒它是如何管理“大量”内存块的。很多新手觉得 Python 内存泄漏是玄学，其实全是设计细节没搞懂。这篇文章，咱们用代码和源码说话，把这块硬骨头啃下来。

入口定位：从 sys.gettotalrefcount 看对象池

要搞清楚 Python 怎么存东西，得先知道它从哪里开始分配。很多人以为 list 就是一个个格子，其实不然。在 CPython 中，小对象（通常小于 512 字节）是由“小对象分配器”（pymalloc）管理的。

我们看一段极简代码，看看当你创建一个列表时，背后发生了什么：

import sys# 创建一个包含 10000 个整数的列表
data = list(range(10000))# 查看该对象的引用计数和类型
print(sys.getrefcount(data)) 
print(sys.getsizeof(data))# 关键：查看整个 Python 进程占用的内存总量
# 注意：这个函数在 C 层面统计的是 pymalloc 池的占用
print(sys.gettotalrefcount()) 

这里的 sys.getsizeof(data) 返回的是列表对象本身占用的空间，而不是列表里那 10000 个整数的空间。这是新手最容易混淆的地方。真正占用内存大户的，是那些被 pymalloc 拿走的“arena”（竞技场）和“pool”（池）。

在 CPython 的官方源码仓库中，Objects/listobject.c 文件里定义了列表的扩容逻辑。当列表需要增长时，它并不是每次都申请一块刚好够用的内存，而是采用“过度分配”策略。这种策略是为了应对“大量”数据的频繁追加操作，避免频繁的 malloc 系统调用。

核心片段：解析 _PyMem_Malloc 的内存分配逻辑

让我们深入 C 语言层面。CPython 的内存分配核心在 Python/pymalloc.c。这里有一段非常关键的代码，决定了你的程序在处理“大量”小对象时，内存是如何被切分和回收的。

/* * 简化自 CPython 源码 Python/pymalloc.c* 展示 pymalloc 如何管理小对象内存池*/// 定义常量：每个 arena 的大小是 256KB
#define ARENA_SIZE (256 * 1024)// 定义常量：每个 pool 的大小是 256 字节
#define POOL_SIZE (256)typedef struct {unsigned char *ob_base;   // 指向 arena 内存块的起始地址struct pool *pools;       // 指向第一个 pool 的指针unsigned char *ob_next;   // 指向下一个空闲 pool 的指针unsigned long total_used; // 当前 arena 已使用的内存大小unsigned long total_free; // 当前 arena 空闲的内存大小
} arena;typedef struct {unsigned char *ob_base;   // 指向 pool 内存块的起始地址unsigned char *ob_next;   // 指向下一个空闲 pool 的指针unsigned long ob_used;    // 当前 pool 已使用的内存unsigned long ob_free;    // 当前 pool 空闲的内存
} pool;// 核心分配函数逻辑简化版
void *_PyObject_Malloc(size_t size) {// 1. 如果请求的大小超过 512 字节，直接调用系统的 mallocif (size > 512) {return malloc(size);}// 2. 计算需要多少个 pool 来容纳这个 size// 每个 pool 可以容纳多个固定大小的槽位size_t pool_index = (size + POOL_SIZE - 1) / POOL_SIZE;// 3. 查找合适的 arenaarena *a = find_arena(pool_index);if (a == NULL) {// 如果没有空闲的 arena，向系统申请一个新的 256KB arenaa = new_arena();}// 4. 在 arena 中查找或创建 poolpool *p = find_pool(a, pool_index);if (p == NULL) {p = new_pool(a, pool_index);}// 5. 从 pool 中分配具体的内存块// 这里涉及到位图（bitmap）操作，标记哪些槽位被占用return allocate_from_pool(p, size);
}

逐行解析：

1. ARENA_SIZE 与 POOL_SIZE：CPython 将内存划分为三层结构。最外层是 Arena（256KB），中间是 Pool（256B），最内层是实际的 Object。这种分层设计是为了减少内存碎片。
2. size > 512：这是分水岭。大于 512 字节的对象（比如大列表、大字典、大字符串）直接走系统级的 malloc/free。小于 512 字节的，走 pymalloc。这就是为什么你创建“大量”小整数时，内存增长比创建一个大数组要复杂得多。
3. find_arena 与 new_arena：CPython 会维护一个空闲 Arena 链表。如果现有的 Arena 里找不到空闲的 Pool，它会向操作系统申请一块全新的 256KB 内存。注意，Arena 一旦分配，除非整个 Arena 里的所有 Pool 都空了，否则不会归还给操作系统。这是 Python 内存“只涨不跌”现象的根本原因。
4. allocate_from_pool：这里使用了位图来追踪每个 8 字节槽位的使用情况。当一个 Pool 被填满后，它会从空闲链表中移除。如果整个 Arena 的所有 Pool 都被填满，这个 Arena 就不再参与分配，直到有对象被释放。

这段源码揭示了一个残酷的事实：Python 的内存回收器（GC）并不能解决 pymalloc 层的内存碎片问题。 GC 只负责处理循环引用，而 pymalloc 的内存块一旦分配，即使对象被销毁，内存块也会留在 Pool 里，等待复用，而不是立即归还给 OS。

设计思想：过度分配与内存复用

理解了 pymalloc 的结构，我们再来看列表的扩容策略。在 Objects/listobject.c 中，有一个名为 list_resize 的函数。

/* * 简化自 CPython 源码 Objects/listobject.c* 展示列表扩容时的内存申请策略*/static int
list_resize(PyListObject *a, Py_ssize_t newsize)
{Py_ssize_t allocated = a->allocated;Py_ssize_t new_allocated;Py_ssize_t delta;PyObject **new_items;// 1. 如果新大小小于等于当前已分配大小，直接返回成功if (newsize <= allocated) {return 0;}// 2. 计算需要增加多少容量// 这是关键：过度分配策略// 当列表很小时，翻倍增长；当列表很大时，按 1/8 增长if (newsize < 9)new_allocated = 4;else {// 增量 = 当前大小 / 8 + 3delta = (newsize >> 3) + 3;new_allocated = newsize + delta;}// 3. 申请新的内存空间new_items = (PyObject **) PyObject_GC_NewVar(PyListObject,&PyList_Type, new_allocated);if (new_items == NULL) {return -1;}// 4. 复制旧数据到新空间memcpy(new_items, a->ob_item, a->allocated * sizeof(PyObject *));// 5. 释放旧空间PyMem_Free(a->ob_item);a->ob_item = new_items;a->allocated = new_allocated;a->ob_size = newsize;return 0;
}

设计思想解析：

1. 过度分配（Over-allocation）：代码中的 delta = (newsize >> 3) + 3 是精髓。它意味着，当你追加一个元素时，CPython 会预留出大约 1/8 的额外空间。这种策略牺牲了少量内存，换取了时间效率。对于“大量”数据的 append 操作，平均时间复杂度保持在 O(1)，而不是 O(n)。
2. 内存复用：PyObject_GC_NewVar 内部会调用我们前面提到的 pymalloc 分配器。如果新申请的空间大小恰好匹配某个空闲的 Pool 槽位，它会直接复用之前的内存块。这就是为什么在循环中创建和销毁对象时，内存不会持续飙升，而是波动后趋于稳定。
3. 为什么不用 realloc？ C 语言中通常用 realloc 来扩容数组。但 CPython 选择“申请新内存 -> 复制 -> 释放旧内存”的方式，是因为 realloc 在某些平台上可能移动内存块，导致 GC 追踪的对象指针失效。CPython 的 GC 依赖于对象的固定地址（在特定优化下），因此这种保守策略更安全。

手写简化版：用 Python 模拟 pymalloc 逻辑

为了更直观地理解这套机制，我们用 Python 手写一个极简的内存分配器模拟。虽然 Python 本身不支持底层内存操作，但我们可以用列表模拟 Arena 和 Pool。

class MiniPymalloc:def __init__(self):self.arenas = []  # 存储所有 Arenaself.free_arenas = []  # 空闲 Arena 链表def new_arena(self):# 模拟申请 256KB 内存，这里用列表长度 100 模拟arena = {'pools': [None] * 100,  # 100 个 Pool 槽位'free_pools': list(range(100)),  # 空闲 Pool 索引'total_used': 0}self.arenas.append(arena)return arenadef allocate(self, size):# 1. 寻找有空闲 Pool 的 Arenaarena = Nonefor a in self.arenas:if a['free_pools']:arena = abreak# 2. 如果没有，创建新 Arenaif arena is None:arena = self.new_arena()# 3. 从空闲列表中取出一个 Poolpool_idx = arena['free_pools'].pop(0)# 4. 模拟分配：标记该 Pool 为使用中arena['pools'][pool_idx] = {'size': size, 'data': 'allocated'}arena['total_used'] += sizereturn pool_idxdef free(self, pool_idx):# 简化版：假设我们知道是哪个 Arena# 实际实现中需要更复杂的映射pass# 测试
allocator = MiniPymalloc()
# 模拟创建大量对象
for i in range(1000):pool = allocator.allocate(64)  # 每个对象 64 字节# 模拟对象生命周期结束if i % 100 == 0:# 模拟 GC 回收部分对象pass

这个模拟版虽然简单，但核心逻辑一致：分层管理、空闲链表、复用优先。在实际项目中，当你发现内存占用异常时，可以通过 tracemalloc 模块来追踪这些分配事件，找出是哪类对象占用了大量的 Pool。

import tracemalloctracemalloc.start()# 创建大量对象
data = [i for i in range(1000000)]# 获取快照
snapshot = tracemalloc.take_snapshot()# 分析内存占用
top_stats = snapshot.statistics('lineno')print("[ Top 3 memory allocations ]")
for stat in top_stats[:3]:print(stat)# 对比两个快照
snapshot2 = tracemalloc.take_snapshot()
top_stats_diff = snapshot2.compare_to(snapshot, 'lineno')
print("\n[ Top 3 differences ]")
for stat in top_stats_diff[:3]:print(stat)

应用场景与避坑指南

理解了源码，再来看实战。处理“大量”数据时，常见的坑有这么几个：

1. 内存泄漏假象：如果你在一个长循环中不断创建和销毁小对象，psutil 显示的 RSS 内存可能不会下降。这不是泄漏，是 pymalloc 的 Arena 未归还。解决办法是定期调用 gc.collect()，但这只能帮助 GC 清理循环引用，对 pymalloc 层帮助有限。真正有效的办法是减少小对象的创建频率，或者使用 __slots__ 减少对象头大小。
2. 大对象与小对象的混合：如果你在列表中混合存储大对象（>512B）和小对象，内存分配会变得非常碎片化。建议将大对象和小对象分开存储，例如使用两个列表，或者使用 array 模块存储同类型的小数值。
3. 列表扩容的开销：当你从一个空列表开始，通过 append 添加“大量”元素时，前几次扩容会非常快（4, 8, 16...），但当你预知大小时，最好使用 list([None] * N) 预分配，然后按索引赋值。这样可以避免多次 memcpy 操作。

避坑技巧：

• 使用 sys.getsizeof 检查对象实际占用，而不是 len。
• 在性能敏感场景，使用 array.array 或 numpy 数组替代原生列表，因为它们使用紧凑的 C 结构存储数据，不受 pymalloc 小对象池的影响。
• 监控内存时，不要只看 RSS，要结合 tracemalloc 看具体是哪行代码分配了内存。

你在项目里踩过这个坑吗？比如发现内存只涨不跌，或者 append 操作偶尔卡顿？评论区聊聊，咱们一起看看是不是中了 pymalloc 的招。