Python内存优化指南

可视化演示

动态展示哈希表使用线性探测法解决冲突的过程，直观呈现哈希函数映射与冲突时顺序探测下一个空槽的机制。

对象内存账本

小飞第一天盘点仓库，发现每件货物不是只有“净重”这么简单。外包装泡沫箱、贴在上面的运单、放在门口的扫码枪，都要占空间。Python 里的对象也是这样：一个整数、一个列表、一个字典，除了数据本身，还带着对象头、引用指针、哈希表等“包装材料”。你看内存用量时，不能只盯着业务数据的大小。

sys.getsizeof() 就是一把量包装箱的尺子。它告诉你一个对象“自己占了多少内存”，但不会递归去量它引用的其他对象。比如一个列表，它内部其实只是存放了指向各元素对象的指针，真正的大头往往在元素对象身上。列表为了快速追加，还会预留一部分空位，这就是“扩容余量”。了解这三层，你才看得懂内存账单。

CPython 64 位环境下，一个包含 n 个指针的列表，内存大约可以这样估算：

小飞总算明白，仓库爆仓不一定因为货物重，也可能因为包装箱太多。优化内存的第一步，就是学会看每件 Python 对象的“包装账本”。

生成器省内存

小飞接到新任务：要把一万件货逐件贴上标签再发走。最笨的办法，是把所有货先搬进仓库、整整齐齐码好，再一件件处理；聪明一点的办法，是在仓库门口架一条传送带，货从左边进来，处理完从右边直接发走，仓库里永远只有一件货。生成器就是这条传送带。

列表推导式会一次性把结果全部装进列表，而生成器表达式和 yield 函数会在每次被 for 循环索要时，才产出下一个值。处理大文件时尤其明显：for line in open(file) 不会把整个文件读进内存，而 readlines() 会。这样做的好处是内存占用不再随数据规模线性上涨。

传送带虽然省地方，但也有代价：货一旦发走就没了。生成器只能从头到尾消费一次，不能回头重新取。小飞在仓库门口立了块牌子：“流水线货物，过后不候。”

slots瘦身

仓库里有一种特殊货箱，每个箱子都自带一本厚厚的流动账本，记录“这个箱子今天能不能加个备注、明天能不能贴张新标签”。对小飞来说，大多数箱子规格固定，根本不需要账本，只需要几个固定的抽屉就够了。Python 普通类实例里的 __dict__，就是那本流动账本。

默认情况下，每个实例都用一个字典保存属性，这让 Python 很灵活，可以随时 obj.new_attr = 1。但灵活性是有代价的：空字典也要约 64 字节，每个实例还要为弱引用预留指针。当你创建几百万个数据对象时，账本就会把内存吃光。在类里声明 __slots__ = ("x", "y")，就是告诉 Python：“别给我配账本了，我就要这两个固定抽屉。”于是实例不再有 __dict__，内存明显变小，属性访问也更快。

小飞把仓库里的流动账本全部换成了编号抽屉，地方一下子宽裕了。但要注意：如果父类用了 slots，子类不重复声明，子类实例仍会带着 __dict__。想彻底省内存，继承链上每一层都要自己规划好抽屉。

memoryview零拷贝

客户要看一箱大货中间夹着的一小片标签。小飞原本的做法，是把整箱货搬到客户面前；更聪明的做法，是让客户隔着玻璃窗直接看，连货箱都不用挪。普通 bytes 切片就是“搬货”，每切一次就复制一份新内存；memoryview 则是那扇玻璃窗，它直接暴露对象的缓冲区，让你只读或者修改底层数据，却不产生拷贝。

memoryview 支持缓冲区协议的对象，比如 bytes、bytearray、array。对 memoryview 做切片，返回的仍然是一个 memoryview，它记录的是“从哪看到哪、长度多少”，而不是把内容复制出来。处理大文件、网络包、二进制协议时，这能省下大量不必要的临时内存。

玻璃窗虽然不搬货，但窗口信息必须准确。使用 memoryview 时，要保证原对象还活着，底层缓冲区没有失效。小飞在仓库贴上标语：“能隔着窗户看的货，绝不搬出来看。”

array紧凑数组

仓库里有一批同规格的小零件，比如一万个 8 字节的浮点数。如果每件都用 Python 的 float 对象单独包装，再加上列表里 8 字节的指针，内存会非常浪费。小飞的做法，是找厂商定制一排标准货格：每个格子大小完全一样，所有零件紧紧挨在一起。Python 的 array 模块就是这种标准货格。

array('d') 会创建一个 C 语言 double 类型的连续数组，元素在内存里一个挨一个地排布，没有 Python 对象头和指针开销。它适合存储大量同类型的数值数据，类型码 'i' 是整数、'd' 是双精度浮点、'f' 是单精度浮点。相比之下，一个 Python 列表存放 float 对象，每个元素要算上 8 字节指针和 28 字节左右的 float 对象。

小飞把散装货统一装进标准货格后，仓库使用率大幅提升。但标准货格也有约束：所有元素必须是同一种类型，不能像列表那样混装字符串和对象。适合数值密集场景，不适合放异构数据。

泄漏检测排查

小飞发现最近仓库数据不对劲：明明每天出货量差不多，仓库却越来越满。有人把货搬进了“环形走廊”，A 箱指着 B 箱，B 箱又指着 A 箱，谁都不觉得自己应该被送到垃圾站。在 Python 里，这种互相引用的循环垃圾，引用计数无法归零，需要专门的垃圾回收器来识别。

排查内存泄漏有三件常用工具。tracemalloc 可以记录每块内存分配时的代码位置，对比两次快照就能看出内存被谁持续占用；gc 模块可以手动触发垃圾回收、查看无法回收的对象；objgraph 则能把对象之间的引用关系画成引用图，让你一眼找到“环形走廊”的入口。

小飞终于在环形走廊尽头找到那批“永远走不出去”的货，用弱引用拆掉了回路。内存曲线终于恢复了平稳。真正的优化高手，不只是会省，还会定期盘点，让每个字节的去向都清清楚楚。

AI 应用场景

Python 演示

import sysimport tracemalloc  def sum_squares_with_list(n):    nums = [i for i in range(n)]    return sum(x * x for x in nums)  def sum_squares_with_gen(n):    return sum(x * x for x in range(n))  class NoSlots:    def __init__(self, x, y):        self.x = x        self.y = y  class WithSlots:    __slots__ = ("x", "y")     def __init__(self, x, y):        self.x = x        self.y = y  def total_size(obj):    size = sys.getsizeof(obj)    if hasattr(obj, "__dict__"):        size += sys.getsizeof(obj.__dict__)    return size  def peak_mb(fn):    tracemalloc.start()    fn()    cur, peak = tracemalloc.get_traced_memory()    tracemalloc.stop()    return peak / 1024 / 1024  def main():    n = 300000    list_peak = peak_mb(lambda: sum_squares_with_list(n))    gen_peak = peak_mb(lambda: sum_squares_with_gen(n))    print("list 方案峰值 = %.1f MB" % list_peak)    print("generator 方案峰值 = %.1f MB" % gen_peak)     no_slots = total_size(NoSlots("a", 1))    with_slots = total_size(WithSlots("a", 1))    print("普通实例 = %d 字节, slots实例 = %d 字节" % (no_slots, with_slots))  if __name__ == "__main__":    main()

1. nums = [i for i in range(n)]一次性把 30 万个整数全部囤进列表，内存压力瞬间拉满。
2. return sum(x * x for x in nums)虽然求和部分用了生成器表达式，但 nums 仍然占着大量内存。
3. return sum(x * x for x in range(n))不建任何列表，range 本身是惰性的，边取边算。
4. __slots__ = ("x", "y")告诉 Python 只要两个固定抽屉，不要为实例创建 __dict__ 账本。
5. if hasattr(obj, "__dict__")手动把字典本身的大小也加进去，才能算出普通实例的真实内存。
6. tracemalloc.start()启动内存追踪，记录从这一刻开始的每一次分配。
7. tracemalloc.get_traced_memory()返回当前占用和峰值占用，用来对比两种方案的峰值。

常见误区

面试题