Python 3.14 和 3.15 回退增量垃圾回收器2026 年 4 月 16 日hugovkHugo van Kemenade提出Python 3.14 引入新的增量垃圾回收器后收到许多报告指出生产环境存在严重内存压力问题。因此决定在 3.14 和 3.15 版本中回退该功能恢复到 3.13 版本的分代垃圾回收器。版本情况及后续计划3.15 版本仍处于 alpha 阶段进行更改可行3.14 版本在补丁版本中做此更改虽不常见但旧的垃圾回收器已知稳定新的增量垃圾回收器未经过 PEP 流程且在 3.13 最终版本发布前就被回退过。此问题已在核心团队和指导委员会中讨论。若想在 3.16 版本重新引入增量垃圾回收器可通过常规 PEP 流程进行更全面评估。时间表3.15 首个 beta 版本计划于 2026 年 5 月 5 日发布若回退功能下周左右准备好发布可额外发布一个 alpha 9 版本。3.14 原计划于 2026 年 6 月 9 日发布 3.14.5 补丁版本回退功能准备好后会提前发布。确定日期后hugovk 会更新此主题和发布相关的 PEP。众人讨论此后众人围绕垃圾回收器展开讨论。2026 年 4 月 17 日上午 7:37pitrouAntoine Pitrou提出是否可同时包含两种垃圾回收器让用户启动时选择担心维护成本太高。同日上午 8:37hugovk 认为这样做成本太高在 3.14 版本中同时存在两种垃圾回收器而 3.13 和 3.15 版本中只有一种会增加维护难度和风险需未来的 PEP 评估。同日上午 9:22tim.oneTim Peters认同此观点指出垃圾回收器代码复杂代码越简单越好特别是在自由线程环境中内存损坏问题可能很久才显现有缺陷的扩展模块导致的内存损坏也常此时暴露。同日上午 11:18storchakaSerhiy Storchaka提出可在 3.14 和 3.15 版本中同时包含两种垃圾回收器旧的作为默认选项新的作为实验性选项前提是不使代码过于复杂。同日下午 12:26pitrou 表示赞同。同日下午 1:04sergey - miryanovSergey Miryanov称和 [nas](/u/nas) 都创建了带有 -X 标志的分支用于切换不同版本的垃圾回收器虽可行但会增加长期维护成本支持在 3.16 及以后版本同时包含两个版本。同日下午 4:19nasNeil Schemenauer介绍自己开发的允许在启动时选择的原型增量垃圾回收器增加约 1600 行代码从维护角度看不算太糟代码分离性好未导致明显性能下降但代码变多变复杂回退到旧的垃圾回收器是安全保守做法。他还提到理想情况下应让新的垃圾回收器可选旧的作为默认选项Java 就是如此但他们人力有限。昨晚的性能基准测试显示增量垃圾回收器最大垃圾回收暂停时间更短但产生大量循环垃圾时进程内存使用显著增加、运行时间变长。一次测试中增量垃圾回收器最大暂停时间为 1.3 毫秒分代垃圾回收器为 26 毫秒增量垃圾回收器的峰值驻留集大小RSS是分代垃圾回收器的 2.7 倍。此外Sergey 已提出 PR 来回退到旧的垃圾回收器他会审核。同日下午 5:08pitrou 询问测试是基于真实工作负载还是专门设计的微基准测试。同日下午 6:37nas 回复测试是合成测试主要产生大量循环希望有更接近真实情况的基准测试和更多真实应用测试反馈。pyperformance 套件中缺乏能现实测试循环垃圾回收的基准测试他最近添加的新基准测试不创建循环仅测试创建大型对象图时垃圾回收的开销。最近有趣的案例是 [Sphinx 变慢](https://github.com/python/cpython/issues/124567)该问题已解决。缺乏现实基准测试和真实应用反馈时进行广泛合成基准测试有帮助。同日下午 7:35hugovk 指出 [Sphinx 变慢](https://github.com/python/cpython/issues/124567) 是导致 3.13 版本回退的案例。同日下午 8:12tim.one 认为缺乏真实工作负载测试是长期问题排序和 pymalloc 方面的问题常先在 Stack Overflow 上出现。他编写 Python 当前排序算法时收到的性能测试结果大多来自合成测试只有一组来自真实应用但无法分享数据。判断字典实现的冲突解决策略时也类似多数策略因真实应用中的罕见灾难性情况被弃用。学术研究者 Sebastian Wild 呼吁提供 “现实世界的数据” 也少有人回应。他还提到早期提出主分支上似乎存在二次时间复杂度行为的问题当时不知是垃圾回收器变更导致简化测试用例几乎不创建循环却触发启发式算法使垃圾回收器部分运行频繁。排序有可预测的最坏情况复杂度垃圾回收情况更复杂。他认同进行广泛合成基准测试有帮助也强调在生产版本中让用户轻松尝试增量垃圾回收器的必要性。同日下午 8:49gpsheadGregory P. Smith询问是否能为补丁版本发布候选版本以便更广泛测试如发布 3.14.5rc1。同日晚上 11:12tim.one 认为在补丁版本中无条件使用增量垃圾回收器风险太大补丁版本首要原则是 “不造成伤害”该变更影响所有程序部分代码微妙复杂且该领域长期存在依赖应用的性能 “惊喜”Neil 的合成测试表明可能还有更糟情况。他支持若能在启动时提供选项启用增量垃圾回收器幸运的话默认情况无明显变化还能让有需求用户测试两种垃圾回收器效果增加现实数据量。他编写 Python 当前的 list.sort() 时提供补丁将新排序算法作为 list 的新方法方便用户比较性能启动时提供选项也能让比较不同垃圾回收器更轻松。后续观点2026 年 4 月 18 日凌晨 4:58tim.one 不满 Python 3.14 引入增量垃圾回收器的介绍只提优点不提缺点他在多数应用中不关心暂停时间更在意运行时间增加认为明确权衡利弊很重要做出改变前广泛讨论更好虽 PEP 流程可解决问题但对内部实现变更来说可能繁琐希望未来在 “充分披露” 方面做得更好。同日下午 5:36hugovk 表示自 2021 年的 [3.9.2rc1](https://www.python.org/downloads/release/python-392rc1/) 以来未再为补丁版本发布候选版本快速演示构建可行但未上传到服务器不确定服务器端是否有基于最终版本后不再有候选版本的假设也未尝试 macOS 或 Windows 构建可能需直接操作并按需修复。同日下午 5:45hugovk 纠正 Sphinx 报告是由一位贡献者更早发现直到 Bellevue 冲刺期间才找到根本原因。同日晚上 7:03tim.one 肯定了 hugovk 的澄清还提出已使用 3.14 版本的用户问题回退增量垃圾回收器可能对他们造成伤害特别是调整过 gc.set_threshold() 参数的用户。他认为总体伤害最小的做法可能是将增量垃圾回收器作为默认选项添加启动选项让用户切换到旧的三代垃圾回收器但也承认没有完美解决方案。2026 年 4 月 19 日凌晨 1:47nas 开发了 [这个工具](https://github.com/nascheme/cyclotron)已发现 3.14t 垃圾回收器的一个严重问题并着手修复。同日凌晨 1:51nas 给出使用该工具对比 3.13 和 3.14 版本的测试结果。