Python 3.14 增量垃圾回收器：分代小批量扫描，多线程重负载不再卡顿

一、背景：CPython 内存管理的双轨机制

1.1 引用计数：即时但无法闭环

CPython 中每个 PyObject 头部都带有一个 ob_refcnt 字段。对象被引用时计数加一，引用解除时计数减一，归零即刻释放。这套机制的优势是回收时机确定、延迟极低，绝大多数临时对象在离开作用域时就被立即销毁。

但引用计数有一个结构性缺陷：它无法处理循环引用。当对象 A 引用 B、B 又引用 A 时，即使外部已无任何引用，两者的计数都不会归零，内存被永久占用。这正是分代 GC 存在的理由。

本文评述：引用计数与分代 GC 不是"二选一"的替代关系，而是分工关系。引用计数负责高频、短生命周期的对象，分代 GC 负责低频、长生命周期且可能成环的对象。任何对 GC 的改动，都必须放在这个分工框架下评估，否则容易得出片面结论。

1.2 分代假设：弱代假说在 CPython 中的落地

分代 GC 的理论基础是"弱代假说"（Weak Generational Hypothesis）：大多数对象生命周期很短，少数对象生命周期很长。基于此，CPython 把所有容器对象划分为三代——第 0 代（Gen0）、第 1 代（Gen1）、第 2 代（Gen2）。新创建的对象进入 Gen0，经历一次 GC 仍存活的对象晋升到下一代。

Gen0 扫描最频繁、成本最低；Gen2 扫描最少，但一旦触发，扫描范围最大。Python 3.13 及之前，每一代都有一个独立的计数器和阈值（默认 (700, 10, 10)），当某代的分配计数减去释放计数超过阈值时，触发该代及其所有更年轻代的 GC。

1.3 三代结构的默认参数

下表整理了 Python 3.13 及之前版本中分代 GC 的默认参数，这些参数在 3.14 中部分被重新定义：

数据来源：CPython 官方文档 gc 模块说明（Python 3.13 文档）。

二、痛点：分代 GC 的停顿从何而来

2.1 停顿的数学表达

一次分代 GC 的耗时可以粗略建模为：T ≈ c · N，其中 N 是该代中需要扫描的容器对象数量，c 是单个对象的平均扫描成本（包括标记、遍历引用、判断可达性等）。当 Gen2 中积累了数十万甚至上百万个存活对象时，N 很大，T 随之线性增长。

关键在于：Gen2 的触发虽然不频繁，但一旦触发，扫描的是"全部三代"。这意味着一次 Gen2 GC 的停顿，可能是 Gen0 的成百上千倍。在延迟敏感的服务中，这种偶发的长停顿比平均延迟更致命。

本文评述：很多团队把 GC 问题简化为"GC 太频繁"，于是调大阈值。但真正的痛点是停顿分布的尾部，而非频率本身。调大阈值只是把停顿推迟，并没有消除它，甚至可能因为单次扫描对象更多而让尖刺更高。

2.2 多线程场景下的放大效应

CPython 的 GC 在触发时会持有 GIL（全局解释器锁）。这意味着：GC 执行期间，所有 Python 线程都被暂停。在单线程脚本中，这只是一次暂停；在多线程服务中，它表现为所有工作线程同时卡住。

更微妙的是，多线程环境下的对象分配速率更高，Gen0 触发更频繁，进而推动 Gen1、Gen2 的触发节奏加快。负载越重，GC 越频繁；GC 越频繁，停顿越容易被用户感知。这形成了一个正反馈。

2.3 一个可观测的停顿模型

下表给出一个模拟的停顿分布（模拟数据，基于典型 Web 服务负载特征构造，用于说明趋势，非实测）：

说明：上表为模拟数据，用于定性说明不同代 GC 的停顿量级差异，实际数值随对象图规模、引用密度、CPU 性能变化。

三、增量 GC 的核心设计：分代小批量扫描

3.1 从"一次扫完"到"分次扫完"

增量 GC 的基本思路是：把一次完整的代扫描拆分为多个"增量步骤"（increment），每个步骤只处理一部分对象。当累积的工作量达到某个预算时，暂停扫描，把剩余工作留到下一次触发时继续。

这带来一个直接后果：单次停顿被摊薄。原本一次 100 ms 的 Gen2 停顿，可能被拆成 10 次 10 ms 的增量停顿，分布在更长的时间窗口内。对延迟敏感的服务而言，10 ms 的尖刺远比 100 ms 的尖刺容易接受。

本文评述：增量化的本质是用总吞吐的轻微下降，换取尾延迟的显著改善。它并不减少总扫描工作量，甚至因为需要维护增量状态而略有增加。这是一笔明确的权衡交易，不是"免费的优化"。

3.2 增量状态机

增量 GC 需要维护一个"扫描进度"状态：当前扫到哪一代、哪个对象、还剩多少工作。这个状态在多次 GC 触发之间保持，直到该代扫描完成。可以把它理解为一个可暂停、可恢复的遍历过程。

实现上，这要求 GC 的标记阶段支持"断点续扫"。传统标记清除是一次性深度遍历，增量版本则需要在遍历过程中记录边界，下次从边界继续。

3.3 与三色标记的关系

增量标记的经典理论工具是三色标记法：白色表示未访问、灰色表示已访问但子节点未处理、黑色表示已完全处理。增量 GC 在暂停时，对象图处于"白-灰-黑"混合状态。恢复扫描时，从灰色集合继续。

本文评述：三色标记是理解增量 GC 的必要但不充分工具。它解释了"如何暂停和恢复"，但没有回答"暂停多久、恢复多频繁"——后者才是工程调优的真正战场。

拓展阅读：CPython 官方 gc 模块文档 docs.python.org/3/library/gc.html；PEP 索引 peps.python.org。关于分代 GC 的经典论述可参考 Jones & Lins 的《Garbage Collection Handbook》。

四、关键机制：触发阈值、工作预算与写屏障

4.1 触发阈值：从"对象计数"到"工作预算"

传统分代 GC 的触发依据是"分配计数 - 释放计数 > 阈值"。增量 GC 需要引入第二个维度：每次触发时允许处理多少工作。这个"工作预算"决定了单次停顿的上界。

预算过小，增量步骤太多，GC 总开销上升；预算过大，单次停顿又回到老问题。找到合适的预算，是增量 GC 调优的核心。

4.2 写屏障：增量标记的正确性保障

增量标记期间，用户程序仍在运行，可能修改对象引用关系。如果处理不当，会出现"黑色对象指向白色对象"的情况——白色对象本该被扫描到，却因为黑色对象已处理完毕而被漏掉，导致存活对象被误回收。

写屏障（Write Barrier）就是拦截这类修改的机制。当程序修改引用时，屏障记录下变化，确保增量标记的正确性。常见的策略包括增量更新（incremental update）和快照（snapshot-at-the-beginning）。

本文评述：写屏障是增量 GC 的隐藏成本。它给每一次引用赋值都增加了额外判断，在引用密集的代码路径上，这部分开销可能抵消掉部分停顿收益。评估增量 GC 时，不能只看停顿，还要看吞吐。

4.3 参数对照表

五、工程实践：如何观测与调优增量 GC

5.1 第一步：打开 GC 统计

Python 的 gc 模块提供了基础统计接口。调优的第一步是观测，而不是盲目改参数。

import gc

# 查看当前阈值
print(gc.get_threshold())      # (700, 10, 10)

# 查看各代统计
print(gc.get_stats())
# [{'collections': 100, 'collected': 5000, 'uncollectable': 0},
#  {'collections': 10,  'collected': 200,  'uncollectable': 0},
#  {'collections': 1,   'collected': 50,   'uncollectable': 0}]

# 查看当前各代对象数
print(gc.get_count())          # (分配数-释放数, gen1计数, gen2计数)

5.2 第二步：测量停顿

Python 标准库没有直接暴露单次 GC 耗时，但可以通过回调函数测量：

import gc, time

last = time.perf_counter()

def on_gc(phase, info):
    global last
    now = time.perf_counter()
    if phase == "stop":
        duration = (now - last) * 1000  # ms
        gen = info.get("generation", -1)
        print(f"GC gen={gen} duration={duration:.2f}ms")
    last = now

gc.callbacks.append(on_gc)

这段代码会打印每次 GC 的耗时和代。把它接入生产环境的监控，就能得到停顿分布。

5.3 第三步：按负载调整阈值

调整阈值没有万能公式，但有可遵循的路径：

1. 先观测：记录 GC 频率和停顿分布，找出尖刺来自哪一代。
2. 再定位：如果尖刺来自 Gen2，说明老年代对象过多，需检查是否有长生命周期容器在持续增长。
3. 后调整：对延迟敏感的服务，可适当降低 Gen0 阈值，让年轻代更早回收，减少晋升到 Gen2 的对象数量。
4. 最后验证：每次调整后重新测量 P99 延迟，确认改善而非恶化。

5.4 第四步：必要时手动控制

对于极端的延迟敏感场景，可以在请求间隙手动触发 GC，把停顿挪到可预测的时间点：

import gc

# 在低峰期手动触发
gc.collect(0)   # 只回收 Gen0
gc.collect(1)   # 回收 Gen0+Gen1
gc.collect(2)   # 全量回收

# 或临时禁用自动 GC，改为手动调度
gc.disable()
# ... 在合适时机调用 gc.collect()
gc.enable()

本文评述：手动 GC 是一把双刃剑。它把不可控的随机停顿变成可控的定时停顿，但如果调度不当，反而会在高峰期引入额外开销。只有在充分观测、明确瓶颈之后才应使用。

六、多线程重负载场景的实测路径

6.1 构造可复现的负载

要验证增量 GC 的效果，需要一个能稳定产生大量容器对象的负载。下面是一个最小化的多线程分配压测脚本：

import threading, time, gc

def worker(stop):
    while not stop.is_set():
        # 制造循环引用，迫使 GC 介入
        a = {}
        b = {"a": a}
        a["b"] = b
        # 制造短生命周期对象
        _ = [dict() for _ in range(100)]

stop = threading.Event()
threads = [threading.Thread(target=worker, args=(stop,)) for _ in range(8)]
for t in threads: t.start()

time.sleep(30)
stop.set()
for t in threads: t.join()

print(gc.get_stats())

6.2 对比实验设计

在相同硬件、相同负载下，分别运行 Python 3.13 和 3.14，记录：

• GC 总次数与各代次数
• 单次 GC 耗时的 P50、P95、P99
• 整体吞吐（每秒完成的任务数）
• 进程 RSS 峰值

本文评述：对比实验的关键是控制变量。GC 行为对对象图结构极其敏感，负载脚本、线程数、对象大小分布都必须一致，否则结论不可信。

6.3 预期观察

基于增量 GC 的设计目标，可以合理预期：Gen2 的单次停顿峰值下降，但 GC 总次数上升，整体吞吐可能略有波动。下表为一个模拟的对比结果（模拟数据）：

说明：上表为模拟数据，用于说明增量 GC 的典型权衡方向，非实测结果。实际数值取决于负载特征。

七、前沿研究与学术脉络

7.1 增量与并发 GC 的谱系

增量 GC 是 GC 研究中的一个成熟方向。从早期的 Baker 增量复制算法，到 Dijkstra 的片上增量标记，再到现代 JVM 的 G1、ZGC，核心问题始终是：如何在保证正确性的前提下，把标记和整理工作分散到程序执行过程中。

本文评述：CPython 的增量 GC 与 JVM 的并发 GC 有本质差异。JVM 的并发 GC 依赖多核并行和内存屏障，可以在应用线程运行时真正并行地做 GC；CPython 受 GIL 限制，增量 GC 更多是时间维度上的切分，而非空间维度上的并行。理解这个差异，才能对 3.14 的效果有合理预期。

7.2 引用计数与追踪 GC 的混合

CPython 是少数同时使用引用计数和追踪 GC 的主流运行时。这种混合模式的优势是回收及时，劣势是写屏障成本高、循环引用处理复杂。近年来的研究（如对引用计数开销的量化分析）表明，引用计数在多线程环境下的原子操作成本不容忽视。

本文评述：增量 GC 的引入，某种程度上是在向追踪 GC 一侧倾斜。它承认了引用计数无法独立解决所有问题，需要追踪 GC 承担更多责任。这是 CPython 内存管理策略的一次微妙但重要的调整。

7.3 延迟敏感型运行时的启示

Go 语言的 GC 演进（从 STW 到并发标记清除，再到亚毫秒停顿）为延迟敏感型运行时提供了重要参考。Go 团队的核心经验是：停顿目标必须明确、可测量，并且要接受吞吐上的代价。

本文评述：CPython 的增量 GC 可以看作是在借鉴这一思路，但受限于 GIL 和引用计数架构，它无法做到 Go 那样的完全并发。因此，对 Python 3.14 的期待应该是"显著削平尖刺"，而非"消除停顿"。

7.4 值得关注的研究方向

• 无 GIL 的 CPython：PEP 703 提出的 free-threaded 模式若成熟，将改变 GC 的并发模型。
• 分代策略的自适应化：根据运行时负载动态调整阈值，而非固定参数。
• 对象图结构感知：针对不同应用的对象图特征，定制扫描策略。
• 与内存分配器的协同：GC 与 pymalloc 的交互仍有优化空间。

八、结论与展望

Python 3.14 的增量垃圾回收器，是 CPython 内存管理在延迟维度上的一次结构性改进。它把分代 GC 的"整代停顿"拆分为"分代小批量扫描"，用总吞吐的轻微代价换取尾延迟的显著改善。对于多线程重负载服务，这意味着更平滑的响应曲线和更可控的 P99。

但增量 GC 不是银弹。它引入了写屏障开销、增量状态维护成本和调优复杂度。工程团队需要建立观测能力，理解自己应用的对象图特征，才能把这次改进转化为实际收益。

本文评述：从更长的技术演进视角看，Python 3.14 的增量 GC 是 CPython 向"延迟友好型运行时"迈出的一步。它与 free-threaded 模式、自适应解释器等改动一起，构成了 Python 在性能与并发方向上的一组协同演进。笔者认为，未来几年 CPython 的 GC 策略会继续向自适应、低停顿方向演进，而 3.14 是这个过程中的一个重要节点。

九、参考文献与声明

9.1 主要参考文献

1. Python Software Foundation. gc — Garbage Collector interface. Python 3.13/3.14 Documentation, 2024–2025.
2. Python Software Foundation. What's New In Python 3.14. 2025.
3. Jones R, Lins R, Batty M, et al. The Garbage Collection Handbook: The Art of Automatic Memory Management. 2nd ed. CRC Press, 2023.
4. Dijkstra E W, Lamport L, Martin A J, et al. On-the-fly garbage collection: an exercise in cooperation. Communications of the ACM, 1978, 21(11): 966–975.
5. Baker H G. List processing in real time on a serial computer. Communications of the ACM, 1978, 21(4): 280–294.
6. Detlefs D, Flood C, Heller S, et al. Garbage-first garbage collection. ISMM, 2004: 37–48.
7. Go Team. Go 1.24 Release Notes: Garbage Collector. 2025.
8. PEP 703. Making the Global Interpreter Lock Optional in CPython. 2023–2025.
9. CPython Source Repository. Modules/gcmodule.c. GitHub, 2025.

9.2 拓展资源

• CPython 官方文档：docs.python.org/3/library/gc.html
• PEP 官方索引：peps.python.org
• CPython GitHub：github.com/python/cpython
• Real Python GC 教程：realpython.com/python-garbage-collection/
• PyCon 相关演讲合集：YouTube: Python Garbage Collection

9.3 数据说明

本文中标注为"模拟数据"的表格，均为基于典型负载特征构造的示意数据，用于说明趋势与量级关系，非真实实测结果。涉及 CPython 默认参数的内容，来源于 Python 官方文档。涉及数据集的处理：本文未使用外部数据集，所有代码示例均为独立构造的最小化示例，可直接运行验证。