为什么Python列表的扩容机制是过度分配的_解析PyListObject的容量增长策略-Python教程-PHP中文网

Python列表扩容采用过度分配策略以保障append()平均O(1)性能，触发条件为ob_size == allocated，增长公式约为1.125倍，不缩容以避免抖动，extend()因一次预估和分配而显著快于循环append()。

为什么python列表的扩容机制是过度分配的_解析pylistobject的容量增长策略

Python列表的扩容不是“刚好够用”，而是刻意多分一点——这种过度分配（over-allocation）是CPython为保障append()平均O(1)性能做的底层妥协，不是bug，是设计。

扩容触发条件：不是“满就扩”，而是`len(lst) == allocated`

列表对象内部维护两个关键长度：ob_size（当前元素个数，即len(lst)）和allocated（已分配的指针槽数）。只有当ob_size == allocated时，下一次append()才会触发扩容。

空列表首次append()通常从allocated = 0或4起步（版本相关）
extend()会预估总长度，若预估值 > 当前allocated，直接按需扩容，可能一步到位
pop()、del、clear()只减ob_size，绝不缩容——allocated保持不变

增长公式：不是翻倍，而是`new_allocated = (size >> 3) + (size`

这个C语言位运算表达式等价于：size × 1.125 + 偏移量。它在小列表和大列表间做了平滑过渡：

小列表（size ）：+3，例如从4→8→12→16→20…避免起步太慢
中大列表（size ≥ 9）：+6，再叠加size >> 3（即size // 8），整体≈1.125倍
实测序列近似为：0 → 4 → 8 → 12 → 16 → 20 → 25 → 32 → 39 → 48 → 58 → 72 → 88 → 108…

它比简单翻倍（如2×）更节省内存，又比每次+1快得多；但也不是严格几何级数，属于启发式折中。

为什么不用`realloc()`缩容？`del`后内存还在那儿

CPython明确放弃自动缩容——哪怕你把一个百万元素列表clear()掉，sys.getsizeof(lst)几乎不变。

Python Hardener

通过完整的安全审查、代码整洁重构、健壮的错误处理、正确的日志记录以及完整的文档字符串覆盖，强化 Python 脚本。

下载

缩容要调用realloc()收缩内存，可能触发物理内存搬移，开销不比扩容小
更关键的是：防止“删完立刻再加，又得扩”的抖动（thrashing）
真要释放内存，只能重建：lst[:] = []（原地清空并缩容）或lst = []（弃旧建新）

这点常被忽略：长期复用同一个列表作临时缓冲区，allocated可能远大于当前len()，造成隐蔽内存浪费。

`extend()`比循环`append()`快的本质：一次预估，一次分配

当你写for x in data: lst.append(x)，每次append()都要检查ob_size == allocated，可能触发多次扩容+复制；而lst.extend(data)在C层直接遍历data获知长度（支持len()的对象）或边读边估（生成器），然后只做一次容量调整和批量memcpy。