Python 3.14 刚把增量垃圾回收器推上舞台，还没站稳，就被生产环境的内存压力报告拉了下来。核心开发者 Hugo van Kemenade 宣布，3.14 和 3.15 将双双回滚至 3.13 的代际式 GC——一次教科书级的"理论收益 vs 现实代价"决策。
增量 GC 到底改了什么
Python 3.13 及之前使用的是三代式（generational）GC：第 0 代放新对象，第 1 代放存活过一次回收的对象，第 2 代放"老住户"。每次回收只扫一代，偶尔才全扫。暂停时间短，但全扫时可能卡一下。
3.14 引入的增量 GC 把一次完整的回收拆成多个小步，穿插在 Python 字节码执行之间，目标是让"大回收"不再一口气停住线程。听起来很美：暂停更短、响应更平滑。
问题在于：拆步意味着回收周期拉长。对象在"还没来得及回收"的窗口里持续存活，内存峰值被推高。生产环境里，那些本该被及时清理的短命对象，硬是多活了几轮字节码循环。
内存压力从何而来
代际式 GC 的核心假设是"大部分对象死得早"，所以第 0 代频繁回收就能压住内存。增量 GC 延迟了回收完成时间，直接打破了这个假设的收益链：
- 短命对象延迟释放：一次本该几毫秒完成的第 0 代回收，被拆成多步后可能横跨数百条字节码指令。期间新对象还在不断创建，旧对象还没释放，内存水位持续上涨。
- 碎片化加剧：回收不彻底，空闲内存块更分散，后续分配效率下降，间接推高内存占用。
- 大对象更难回收：跨代晋升的对象本就难回收，增量模式下第 2 代全扫周期更长，大对象的驻留时间进一步延长。
生产环境报告的典型症状：相同负载下，3.14 的进程 RSS 比 3.13 高出 20%-40%，部分服务甚至触发 OOM。
回滚决策的权衡
回滚不是"增量 GC 没价值"，而是"当前实现的代价超过了收益"。核心开发者的判断逻辑很清晰：
| 维度 | 代际式 GC（3.13） | 增量 GC（3.14） |
|---|---|---|
| 暂停时间 | 偶发长暂停 | 暂停更短更均匀 |
| 内存峰值 | 较低 | 显著升高 |
| 实现复杂度 | 稳定成熟 | 新引入，边界条件多 |
| 生产验证 | 十余年 | 不足一个版本周期 |
对于 Web 服务、数据处理这类"内存敏感、暂停容忍度尚可"的场景，内存压力是硬约束，暂停时间是软约束。回滚是务实选择。
观察你的 GC 行为
不管你用的是哪个版本，搞清楚 GC 在你的负载下到底做了什么，比盲目调参重要得多。下面这段代码可以直接运行，观察当前 Python 的 GC 统计和内存水位：
import gc
import os
import tracemalloc
import time
# 开启内存追踪
tracemalloc.start()
# 模拟短命对象密集创建的负载
def create_short_lived_objects(batch=100000):
"""创建一批短命对象，模拟 Web 请求中的临时数据"""
result = []
for i in range(batch):
# 这些 dict 大部分会在函数返回后可回收
result.append({"id": i, "data": f"payload-{i}" * 10})
# 只保留少量结果，其余变为垃圾
return result[:100]
# 记录 GC 前的状态
gc.collect() # 先做一次完整回收，建立基线
before_stats = gc.get_stats()
before_rss = os.popen(f"ps -o rss= -p {os.getpid()}").read().strip()
print("=== GC 回收前 ===")
print(f"进程 RSS: {before_rss} KB")
for i, stat in enumerate(before_stats):
print(f" 第 {i} 代: collections={stat['collections']}, "
f"collected={stat['collected']}, uncollectable={stat['uncollectable']}")
# 执行多轮负载
for round_num in range(5):
_ = create_short_lived_objects(200000)
time.sleep(0.01) # 让字节码循环推进
# 记录 GC 后的状态
gc.collect()
after_stats = gc.get_stats()
after_rss = os.popen(f"ps -o rss= -p {os.getpid()}").read().strip()
current, peak = tracemalloc.get_traced_memory()
print("\n=== GC 回收后 ===")
print(f"进程 RSS: {after_rss} KB")
print(f"tracemalloc 当前: {current / 1024:.1f} KB, 峰值: {peak / 1024:.1f} KB")
for i, stat in enumerate(after_stats):
print(f" 第 {i} 代: collections={stat['collections']}, "
f"collected={stat['collected']}, uncollectable={stat['uncollectable']}")
# 对比内存增长
rss_delta = int(after_rss) - int(before_rss)
print(f"\nRSS 增长: {rss_delta} KB ({rss_delta / 1024:.1f} MB)")
print(f"峰值/基线比: {peak / current:.2f}x")
运行方式：
# 用不同版本的 Python 对比
python3.13 gc_profile.py # 代际式 GC
python3.14 gc_profile.py # 增量 GC（如果你已经装了 3.14）
关注两个关键数字：
- 峰值/基线比：增量 GC 下这个比值会明显更高，说明回收延迟导致峰值膨胀。
- RSS 增长：回收后 RSS 是否回落到基线附近。如果回落不明显，说明有对象被延迟回收或跨代晋升了。
手动调参：在代际式 GC 下压住内存
回滚到代际式 GC 后，你仍然可以通过调参优化。Python 的 gc 模块暴露了三代阈值：
import gc
# 查看当前阈值
print(gc.get_threshold()) # 默认 (700, 10, 10)
# 更激进的第 0 代回收：降低阈值，更频繁清理短命对象
gc.set_threshold(500, 10, 10)
# 或者对内存极度敏感的服务，进一步压低
gc.set_threshold(300, 8, 5)
阈值含义：第 0 代阈值 700 表示当新分配对象数减去释放对象数超过 700 时触发第 0 代回收。降低这个值会让 GC 更勤快，暂停更频繁但每次更短，内存水位更低。
在生产环境调参前，先用上面的 profiling 脚本跑一遍你的实际负载，记录不同阈值下的 RSS 增长和峰值比，再做决策。
给开发者的行动清单
- 如果你正在用 3.14 beta/alpha：确认你的服务内存水位。如果比 3.13 下高出超过 15%，回滚消息对你不是"未来事件"，而是"当前问题"。考虑降回 3.13 或等待 3.14 正式版（会包含回滚）。
- 如果你计划升级到 3.14/3.15：回滚已确认，这两个版本发布时会恢复代际式 GC。升级路径不受影响，但不要依赖增量 GC 的行为做优化。
- 如果你对暂停时间敏感：代际式 GC 的长暂停仍然存在。短期方案是用
gc.set_threshold()缩短第 2 代回收间隔；中期方案是关注后续版本是否会引入改进的增量实现。 - 监控 RSS 和 GC 统计：把上面的 profiling 逻辑集成到你的服务健康检查里。
gc.get_stats()和ps -o rss是最廉价的观测手段，比事后排查 OOM 有效得多。
增量 GC 的回滚不是终点。暂停时间优化仍然是 Python GC 的长期方向，只是下一次尝试需要先解决"延迟回收 = 内存膨胀"这个硬约束，再谈平滑暂停。