Python 3.6与3.11的字典内存对比_Compact Dict布局带来的优化

Python 3.6+ 字典更省内存？深入解析Compact Dict布局与实测影响

Python 3.6+ 字典更省内存是因为采用 Compact Dict 布局，只存储一份键值对数组，散列表仅存索引，分离稀疏哈希表与密集数据，3.11 相比 3.6 再省 5%～8% 内存。

Python 3.6+ 字典为什么更省内存？关键在 Compact Dict 布局

从 Python 3.6 开始，dict 的内部结构迎来了一次堪称“改头换面”的升级，采用了所谓的 Compact Dict（紧凑字典）布局。到了 3.11 版本，又在此基础上对内存对齐和哈希缓存策略做了进一步优化。这可不是什么小打小闹的调整，而是一次彻底的结构重构：旧版字典在内存中需要维护两份数据（一个散列表加上一个键值对数组），而新版设计则精简为只保留一份键值对数组，散列表里只存放索引。结果如何呢？以十万个 str 到 int 的映射为例，Python 3.11 相比 3.6 能再节省大约 5% 到 8% 的内存，如果跟 3.5 及更早的版本相比，节省的幅度更是接近 25%。

这背后并没有什么高深的魔法，核心思路就是将稀疏的哈希表（里面充斥着大量 NULL 空槽位）和密集的键值对数据分离开来，然后用偏移量索引来代替直接的指针跳转。当然，这种设计也带来了一点小代价——插入新键时可能需要多一次间接寻址。不过，考虑到现代 CPU 缓存友好性带来的性能提升，这点微小的开销几乎可以忽略不计。

怎么实测两个版本的字典内存差异？别信 sys.getsizeof() 直接结果

如果你想亲手验证不同版本间的内存差异，可得注意方法。sys.getsizeof() 这个函数返回的仅仅是字典对象头加上散列表本身的内存，它并不包含键和值这些对象实际占用的空间。要想获得真实的、可对比的内存占用数据，必须确保测试条件一致，并测量完整的对象图：

• 固定哈希种子：在启动解释器时加上 -X hashseed=0 参数，或者设置环境变量 PYTHONHASHSEED=0。这一步是为了禁用哈希随机化，确保每次运行的桶分布都相同，让对比结果具有可重复性。
• 使用正确的测量工具：不要只依赖 __sizeof__()。更准确的做法是手动递归计算所有键和值对象的大小（比如字符串的 __sizeof__()），或者直接使用第三方库如 pympler 提供的 asizeof() 函数。
• 注意字典构造方式：创建测试字典时，推荐使用 dict(zip(keys, values)) 一次性构建，而不是通过循环逐个执行 d[k] = v 来赋值。后者可能在动态扩容过程中产生临时的内存冗余，影响测量精度。

举个例子，用十万个固定长度的字符串键和小整数值进行测试，在 Python 3.6.15 和 3.11.9 下，使用 asizeof() 测得的总体内存占用分别约为 12.1 MB 和 11.3 MB。这个差值主要归功于散列表的缩容以及填充率阈值的提升（在 3.11 中，默认的填充阈值从 2/3 提高到了 3/4）。

立即学习“Python免费学习笔记（深入）”；

Compact Dict 对迭代顺序和性能的影响不是“顺便优化”，而是设计前提

很多人知道从 Python 3.7 开始，字典的插入顺序得到了官方保证。但事实上，这个特性并非 3.7 的“新功能”，而是 3.6 引入 Compact Dict 布局后一个自然而然的结果：键值对按照插入顺序线性存储在数组中，遍历时只需要顺序读取这个数组即可。这意味着：

• 任何像 for k in d: 或 list(d.keys()) 这样的操作，时间复杂度都是 O(n)，并且由于缓存局部性极佳，其速度比旧版的乱序遍历要快上 10% 到 15%。
• 不过，性能提升并非均匀分布。例如，popitem(last=True)（弹出最后一项）在 3.11 中比 3.6 略快，因为可以直接定位到末尾索引；而 popitem(last=False)（弹出第一项）仍然需要扫描数组开头，因此没有获得加速。
• 需要警惕的是，如果你的旧代码或测试用例依赖“字典键序是随机的”这一假设来实现简单的混淆逻辑，那么在升级到 3.6+ 版本后可能会失败。这并非 Bug，而是底层布局改变导致的确定性行为变化。

哪些场景下 Compact Dict 的优势会被抵消？注意这几个隐性开销

紧凑布局虽然节省空间，但并非一把万能钥匙。在下面几种特定场景下，Python 3.11 的字典可能反而显得“更重”或者更慢：

• 键是未定义哈希的自定义类：如果键的类型是自定义类，且没有正确实现 __hash__ 或 __eq__ 方法，Compact Dict 仍然需要存储完整的对象引用。相比之下，旧版字典可能会因为哈希冲突而分配更多空槽位，此时两者之间的内存差异会缩小，甚至可能发生反转。
• 频繁的删除与插入不同键：3.11 版本对“已删除槽位”的复用逻辑更为激进。但是，如果键的哈希分布极差（例如发生全碰撞），仍然会触发字典的扩容（resize）操作。而且，新版字典扩容后的最小尺寸从 8 增加到了 32，在某些情况下，这可能导致新表比 3.6 版本下的更大。
• 使用 dict.fromkeys() 创建大量重复键的字典：虽然 3.6 和 3.11 都会对键进行去重，但 3.11 版本在分配键数组时策略可能更“贪心”一些。如果传入的可迭代对象极其庞大（达到千万级别），这种预分配机制可能会导致暂时占用略多的内存。

说到底，评估内存时最关键的点往往不在于字典容器结构本身那点绝对数字，而在于字典里所装的键值对象——它们的生命周期、大小以及复杂的引用关系。Compact Dict 优化的是容器的“包装盒”，至于盒子里装的是短小精悍的字符串，还是包含循环引用的复杂嵌套字典，它就无能为力了。理解这一点，才能更好地利用新特性，并规避其潜在的短板。