Python：生成器省内存：100 万个数的平方和，括号一换从占几个 G 到几乎不占

一、问题的提出：两个字符，三个数量级

几乎所有 Python 入门材料都会提到这样一句话：把列表推导式的方括号换成圆括号，就得到了生成器表达式，可以「节省内存」。这句话被重复了太多次，以至于很多人把它当作一条口诀背下来，却从未追问：省的是哪部分内存？省多少？在什么条件下省？代价是什么？

先看两段代码：

# 版本 A：列表推导式
total = sum([x * x for x in range(1_000_000)])

# 版本 B：生成器表达式
total = sum(x * x for x in range(1_000_000))

两者输出完全一致。但在 CPython 3.11 上，版本 A 的峰值内存通常在数十 MB 到上百 MB 量级（取决于元素对象大小与解释器版本），版本 B 的峰值内存则基本与 range(1_000_000) 本身的开销相当，也就是常数级别。若把元素换成更重的对象（比如字符串、元组、自定义类实例），版本 A 的内存占用可以轻松突破 1 GB，而版本 B 几乎纹丝不动。

本文评述：「省内存」这个说法过于笼统。准确的说法是：列表推导式会先物化一个长度为 n 的容器，容器本身加上其中 n 个元素对象共同占用 O(n) 空间；生成器表达式只在任意时刻持有一个元素，空间复杂度为 O(1)（不含输入序列本身）。这个区别的本质不是「语法糖」，而是两种不同的求值策略。

为了让讨论有据可依，本文后续所有测量均基于以下环境（模拟数据标注）：CPython 3.11.6 / 3.12.2，64 位 Linux，glibc 2.35，无第三方内存分配器介入。文中出现的具体字节数来自 sys.getsizeof 与 tracemalloc 的实测输出，属于可复现的模拟测量数据，读者在不同平台上可能得到略有差异的数值。

二、CPython 对象模型：一个 int 到底占多少字节

2.1 PyObject 头部与引用计数

在 CPython 中，一切皆对象，而每个对象都从一个固定的头部开始。这个头部在 64 位平台上通常包含一个引用计数（ob_refcnt，8 字节）和一个类型指针（ob_type，8 字节），合计 16 字节。这是所有 Python 对象的「最低消费」。

对于整数对象，头部之后还有一个变长的 ob_digit 数组。CPython 使用 30 位一组的「digit」来存储大整数（在 64 位平台上），因此小整数只需要一个 digit。加上对象头，一个「小整数」对象在 64 位 CPython 上通常占用 28 字节。

>>> import sys
>>> sys.getsizeof(0)
28
>>> sys.getsizeof(2**30)
32
>>> sys.getsizeof(2**60)
36
>>> sys.getsizeof(2**300)
60

可以看到，整数对象的大小随数值位数增长。这一点在讨论「平方和」时尤其重要：x * x 的结果会随着 x 增大而占用更多字节。当 x 接近 10⁶ 时，x² 接近 10¹²，需要约 40 位，也就是两个 30 位 digit，对象大小约为 32 字节。

2.2 列表对象的开销

列表本身是一个「指针数组 + 头部」的结构。头部包含引用计数、类型指针、以及已分配容量（allocated）和实际长度（ob_size）。每个元素槽位是一个 8 字节指针，指向堆上的元素对象。

>>> import sys
>>> empty = []
>>> sys.getsizeof(empty)
56
>>> lst = [0] * 1_000_000
>>> sys.getsizeof(lst)
8000056

一个空列表占 56 字节，而容纳 100 万个元素的列表占约 8 MB —— 这 8 MB 只是「指针数组」本身，还不包括被指向的整数对象。由于 [0] * 1_000_000 复用了同一个整数对象 0，所以元素对象本身只占一份。但如果元素是各不相同的整数，每个都要单独分配。

本文评述：很多人算内存时只算「容器大小」，忽略了「元素对象大小」。在 CPython 中，一个包含 100 万个独立整数的列表，真实内存占用约为 8 MB（指针数组）+ 100 万 × 28~32 字节（整数对象）≈ 36~40 MB。这才是列表推导式真正的内存账单。而生成器表达式不持有这个数组，也不持有所有元素对象，账单被压缩到常数级。

2.3 小整数缓存与它的误导性

CPython 对 -5 到 256 之间的整数做了缓存（小整数池），这些整数在解释器启动时就被创建，所有引用共享同一对象。这意味着如果你用 range(200) 做实验，列表推导式的内存占用会显得异常小，因为元素全部命中缓存。

>>> a = [x for x in range(200)]
>>> b = [x for x in range(1000, 1200)]
>>> sys.getsizeof(a), sys.getsizeof(b)
(1656, 1656)   # 容器大小相同
# 但 a 的元素全部来自缓存，b 的元素全部是新对象

这个细节经常让初学者在「小数据上测试」时得出错误结论。要观察真实差异，必须让元素落在缓存区之外，并且数量足够大。这也是本文选择「100 万个数的平方和」作为案例的原因：平方结果远超 256，必然产生大量独立对象。

三、求值策略：及早求值 vs 惰性求值

3.1 列表推导式：及早求值的典型

列表推导式在语义上等价于「先建一个空列表，然后循环 append」。CPython 为它生成字节码时，会使用 LIST_APPEND 指令，逐次把求值结果追加到正在构建的列表中。整个循环结束后，一个完整的列表才被交给 sum。

这意味着在 sum 开始工作之前，所有元素都已经存在于内存中。峰值内存出现在「列表构建完成、sum 尚未开始」的那一刻。

3.2 生成器表达式：惰性求值的载体

生成器表达式返回的是一个 generator 对象。它不执行任何计算，只是把「如何计算」这件事封装起来。只有当外部调用 next() 时，它才推进到下一个元素，计算、产出、然后暂停。

>>> gen = (x * x for x in range(1_000_000))
>>> import sys
>>> sys.getsizeof(gen)
208
>>> next(gen)
0
>>> next(gen)
1
>>> next(gen)
4

一个生成器对象本身只占 200 字节左右，与它将要产出多少元素无关。这就是 O(1) 空间复杂度的来源。

笔者认为：把生成器理解为「惰性列表」是一种简化，但会掩盖关键差异。列表是数据，生成器是计算过程。列表可以被索引、切片、重复遍历；生成器只能单向推进一次。这个差异决定了生成器不是列表的「省内存替代品」，而是一种不同的抽象。

3.3 惰性求值的三种「延迟」

惰性求值在 Python 生态中并非只有生成器一种形态。可以粗略分为三层：

机制	延迟对象	典型代表	内存特征
生成器	单个元素的求值	genexpr、yield	O(1)
迭代器协议	下一个元素的获取	map、filter、zip	O(1)
惰性容器	元素的物化时机	dict.keys()、range	视图 O(1)，容器 O(n)

值得注意的是，range 在 Python 3 中是一个惰性序列对象，它不存储所有整数，而是按需计算。这也是为什么 range(1_000_000) 本身几乎不占内存的原因。

四、动手测量：tracemalloc 与 memory_profiler 实操

4.1 用 tracemalloc 做进程内测量

tracemalloc 是标准库自带的分配追踪器，可以精确到「哪一行代码分配了多少内存」。它比 sys.getsizeof 更贴近真实，因为它统计的是解释器实际向系统申请的内存。

import tracemalloc

def measure(fn, label):
    tracemalloc.start()
    fn()
    current, peak = tracemalloc.get_traced_memory()
    tracemalloc.stop()
    print(f"{label}: current={current/1e6:.2f} MB, peak={peak/1e6:.2f} MB")

N = 1_000_000

measure(lambda: sum([x * x for x in range(N)]), "list-comp")
measure(lambda: sum(x * x for x in range(N)), "genexpr")

在 CPython 3.11 上的典型输出（模拟测量数据）：

list-comp: current=0.00 MB, peak=38.15 MB
genexpr:   current=0.00 MB, peak=0.21 MB

两者相差约 180 倍。注意 current 都是 0，因为函数返回后列表已被回收；真正有意义的是 peak。

4.2 用 memory_profiler 做逐行分析

如果想知道「哪一行吃掉了内存」，memory_profiler 的 @profile 装饰器更直观。它通过采样进程 RSS 来估计内存变化。

# pip install memory_profiler
from memory_profiler import profile

@profile
def build_list():
    return [x * x for x in range(1_000_000)]

@profile
def build_gen():
    return sum(x * x for x in range(1_000_000))

build_list()
build_gen()

运行 python -m memory_profiler demo.py，会看到 build_list 那一行的 Increment 达到几十 MB，而 build_gen 几乎为 0。

本文评述：两种工具各有侧重。tracemalloc 追踪的是 Python 层分配，数字精确但可能低估 C 扩展的分配；memory_profiler 看的是进程 RSS，更接近「系统视角」但受采样频率影响。工程上建议两者结合：先用 memory_profiler 定位可疑函数，再用 tracemalloc 精确定位行号。

4.3 一个容易踩的坑：测量顺序

CPython 的内存分配器（pymalloc）会缓存已释放的小对象内存，不会立刻归还给操作系统。因此如果你先跑列表版本再跑生成器版本，后者的 RSS 可能看起来偏高，因为它在复用前者留下的内存池。正确的做法是每个测量放在独立进程里，或者用 tracemalloc 这种追踪分配而非 RSS 的工具。

五、生成器的运行时结构：帧、状态与 GC

5.1 生成器对象里装了什么

一个生成器对象内部持有一个「帧对象」（frame），帧里保存了局部变量、指令指针、值栈等执行状态。当生成器暂停时，这个帧被冻结；当它恢复时，帧被重新激活。这就是为什么生成器能「记住执行到哪了」。

帧对象本身是有开销的。一个典型的生成器帧在 64 位 CPython 上可能占用几百字节到几 KB，取决于局部变量数量和值栈深度。这就是为什么「生成器对象占 208 字节」这个数字会随代码复杂度变化。

5.2 引用计数与循环垃圾回收

CPython 主要依赖引用计数来回收对象。生成器每产出一个元素，如果外部没有保留引用，该元素在下一轮迭代前就会被释放。这意味着生成器场景下的内存占用是「锯齿状」的：分配一个元素、消费它、释放它，峰值始终维持在一个元素的大小。

相比之下，列表推导式在构建过程中，所有元素都被列表强引用，引用计数始终 ≥ 1，无法被回收，直到整个列表被释放。

笔者认为：把生成器的省内存归因于「惰性求值」只说对了一半。另一半是引用计数的即时回收特性。如果 CPython 用的是纯追踪式 GC（像 Java 那样），生成器的内存优势会被削弱，因为垃圾对象可能在被回收前积累一批。这一点在讨论其他 Python 实现（如 PyPy）时需要特别注意。

5.3 生成器的状态机视角

从编译原理角度看，生成器是把一个「递归/循环」的计算过程编译成了一个显式状态机。每次 next() 就是一次状态转移。这与协程（coroutine）在实现上是同源的 —— Python 3.5 之后 async def 定义的协程，底层就是基于生成器机制扩展的。

理解这一点有助于判断：什么时候该用生成器？当你的计算可以被描述为「一个可暂停、可恢复的过程」时。反过来，如果计算需要随机访问中间结果，生成器就不合适。

六、工程改造路径：从列表到流的七种手法

6.1 手法一：直接替换为生成器表达式

最直接的一步：把 [expr for x in it] 改成 (expr for x in it)，前提是下游消费者只做一次线性遍历（sum、max、min、any、all、for 循环）。

# 改造前
total = sum([row["amount"] for row in rows])

# 改造后
total = sum(row["amount"] for row in rows)

6.2 手法二：用生成器函数替代「构建列表再返回」

当逻辑复杂到一行表达式写不下时，用 yield 写生成器函数。

def parse_lines(path):
    with open(path, encoding="utf-8") as f:
        for line in f:
            line = line.strip()
            if not line or line.startswith("#"):
                continue
            yield line.split(",")

注意这里还叠加了「文件逐行读取」的惰性：for line in f 本身就是惰性的，不会把整个文件读进内存。

6.3 手法三：itertools 组合流式管道

itertools 提供了大量惰性工具，可以把多个转换串成管道而不物化中间结果。

import itertools as it

pipeline = it.islice(
    (x * x for x in it.count(1)),
    1_000_000
)
total = sum(pipeline)

这里 it.count 是无限生成器，islice 截取前 100 万个，整个过程没有中间列表。

6.4 手法四：分块处理（chunking）

有些算法无法纯流式完成（比如需要排序、需要全局统计），这时可以分块：每次处理固定大小的块，块内物化，块间流式。

def chunked(iterable, size):
    it_ = iter(iterable)
    while True:
        chunk = list(it.islice(it_, size))
        if not chunk:
            return
        yield chunk

total = 0
for chunk in chunked((x * x for x in range(1_000_000)), 10_000):
    total += sum(chunk)

这样峰值内存被限制在「一个块」的大小，而不是整个数据集。

6.5 手法五：用 array / numpy 替代 Python 列表

如果数据是同质的数值，array.array 或 numpy.ndarray 比 Python 列表紧凑得多。一个 int64 的 numpy 数组，100 万个元素只占 8 MB，而 Python 列表要 36 MB 以上。

import numpy as np
arr = np.arange(1_000_000, dtype=np.int64)
total = int((arr * arr).sum())

注意 arr * arr 会产生一个临时数组，峰值内存约 16 MB。如果连这个临时数组都想避免，可以用 np.dot 或原地操作。

6.6 手法六：数据库游标与服务器端游标

从数据库读大量行时，默认的 fetchall() 会把所有行拉进内存。改用 fetchmany() 或服务器端游标（如 psycopg 的 named cursor、SQLAlchemy 的 stream_results）可以把内存压到常数级。

# SQLAlchemy 2.x 流式读取
with engine.connect().execution_options(stream_results=True) as conn:
    result = conn.execution_options(yield_per=10_000).execute(stmt)
    for row in result:
        process(row)

6.7 手法七：生成器 + 背压（backpressure）

在生产者-消费者场景中，如果生产者比消费者快，即使双方都是流式，中间队列也可能堆积。这时需要背压机制：让生产者等待消费者。Python 的 asyncio.Queue(maxsize=N) 或 queue.Queue(maxsize=N) 都能实现。

本文评述：这七种手法不是互斥的，而是可以叠加的。一个成熟的数据管道往往是「文件逐行读 → 生成器解析 → itertools 过滤 → 分块聚合 → 数据库流式写」。理解每一层的惰性边界，是控制内存的关键。

七、真实场景：日志、CSV、数据库游标与数据管道

7.1 日志聚合：从 OOM 到稳定运行

一个常见场景：统计一天内某个接口的 P99 延迟。日志文件可能几十 GB，如果写成 [parse(line) for line in f]，内存必然爆掉。正确做法是流式解析 + 分位数近似算法（如 t-digest 或 P² 算法）。

def iter_latencies(path):
    with open(path, encoding="utf-8") as f:
        for line in f:
            if "/api/order" not in line:
                continue
            try:
                yield float(line.rsplit(" ", 1)[-1])
            except ValueError:
                continue

count = 0
total = 0.0
for lat in iter_latencies("access.log"):
    count += 1
    total += lat
mean = total / count if count else 0.0

这段代码无论日志多大，内存都是常数级。如果要算分位数，可以接入 t-digest 的 Python 实现，它本身也是流式、有界的。

7.2 CSV 处理：csv 模块本身就是迭代器

标准库 csv.reader 返回的就是迭代器，配合文件对象逐行读取，天然流式。

import csv

with open("big.csv", newline="", encoding="utf-8") as f:
    reader = csv.DictReader(f)
    total = sum(float(row["amount"]) for row in reader)

注意 csv.DictReader 每行返回一个 dict，这个 dict 是新建的，用完即弃。如果字段很多，可以考虑用 csv.reader 返回列表，减少 dict 开销。

7.3 数据管道：把惰性作为设计原则

在 ETL 场景中，把每个阶段都设计成「接收可迭代对象、返回生成器」，可以让整条管道保持常数内存。

def read(path): ...
def parse(rows): ...
def filter_valid(rows): ...
def transform(rows): ...
def write(rows): ...

write(transform(filter_valid(parse(read("input.csv")))))

这种「生成器管道」风格在 Rust 的 Iterator、Java 的 Stream、以及 Python 的 itertools 中都有对应。笔者认为：它的价值不只是省内存，更在于把「数据流」和「转换逻辑」解耦，让每个阶段可以独立测试、独立替换。

八、反模式与陷阱：生成器并不总是答案

8.1 陷阱一：生成器只能遍历一次

gen = (x for x in range(5))
print(list(gen))   # [0, 1, 2, 3, 4]
print(list(gen))   # []

这是最常见的坑。如果下游需要多次遍历，要么重新创建生成器，要么物化成列表。判断标准：这段数据会被消费几次？

8.2 陷阱二：生成器表达式捕获变量的时机

funcs = [lambda: x for x in range(3)]
print([f() for f in funcs])   # [2, 2, 2]

funcs = [(lambda x=x: x) for x in range(3)]
print([f() for f in funcs])   # [0, 1, 2]

生成器表达式也有类似的作用域问题。惰性求值意味着变量在「被消费时」才求值，而不是「被定义时」。这是惰性带来的语义变化，必须警惕。

8.3 陷阱三：生成器 + 异常处理的复杂性

生成器中的异常会在 next() 调用点抛出，而不是在生成器创建时。这会让错误定位变得困难。建议在生成器内部捕获可预期的异常，或者用 try/except 包裹消费循环。

8.4 陷阱四：小数据上的性能反噬

生成器每次 next() 都有帧切换开销。在数据量很小（比如几百个元素）时，生成器版本可能比列表版本慢。是否值得用生成器，要看数据规模。

数据规模	推荐方案	理由
< 1 万	列表推导式	内存差异可忽略，列表更快更灵活
1 万 ~ 100 万	视元素大小而定	元素重则用生成器，元素轻则列表可接受
> 100 万	生成器 / 流式	列表可能触发 OOM

九、前沿演进：PEP 709、自由线程与 JIT

9.1 PEP 709：内联推导式

PEP 709 在 Python 3.12 中落地，把列表推导式、字典推导式、集合推导式从「创建一个隐式函数」改为「内联到外层帧」。这带来了两个变化：一是推导式更快（省去了函数调用开销），二是推导式内部的变量不再泄漏到外层作用域。

对内存的影响是间接的：内联后不再需要为推导式创建帧对象，小规模场景下的开销更低。但列表推导式「物化整个列表」的本质没有改变。生成器表达式不受 PEP 709 影响，因为它本来就需要一个独立的帧来保存暂停状态。

本文评述：PEP 709 让列表推导式在「小数据 + 高频调用」场景下更有竞争力，但它没有改变 O(n) 空间复杂度的事实。选择列表还是生成器，仍然应该基于数据规模和消费模式，而不是微性能。

9.2 自由线程（PEP 703）与内存模型

CPython 3.13 开始提供实验性的自由线程构建（no-GIL）。在无 GIL 的世界里，引用计数的原子化操作会带来额外开销，内存回收的时机也更复杂。这对生成器的影响在于：生成器暂停时持有的帧和局部变量，在多线程环境下需要更谨慎的同步。

目前自由线程构建仍处于实验阶段，生产环境大规模使用还需时间。但它提示我们：Python 的内存语义不是一成不变的，今天关于「生成器省内存」的结论，未来可能需要重新验证。

9.3 JIT 与自适应解释器

CPython 3.13 引入了实验性的 JIT（基于 copy-and-patch 技术）。JIT 主要优化的是执行速度，对内存占用的影响相对间接。但一个值得关注的方向是「逃逸分析」：如果 JIT 能证明某个列表不会被外部引用，理论上可以把它优化掉，直接流式处理。目前 CPython 的 JIT 还没有做到这一步，但在 PyPy 等实现中已有类似优化。

另一个相关方向是「零拷贝」数据结构的普及。Apache Arrow 的内存布局让跨语言、跨进程的数据交换不再需要序列化，Python 的 PyArrow 绑定让 pyarrow.Table 可以直接映射到 C++ 内存。在 Arrow 生态中，「生成器 vs 列表」的问题部分被「列式 vs 行式」取代。

十、结论与行动清单

回到最初的问题：sum([x*x for x in range(1_000_000)]) 和 sum(x*x for x in range(1_000_000)) 的差异，本质是「及早求值 + 物化容器」与「惰性求值 + 单元素状态」的差异。前者空间 O(n)，后者空间 O(1)。这个差异在数据量大、元素重时会被放大到几个数量级。

但生成器不是万能药。它牺牲了随机访问、多次遍历、以及一部分可读性，换来了内存的常数级占用。是否值得，取决于具体场景。

参考文献与延伸资源