Python 3.12 未改进 GC 算法，仍沿用引用计数加三色分代机制；调大 gc.set_threshold() 可减少 gen0 频繁触发带来的卡顿，但需结合对象生命周期与 gc.get_count() 观察合理设置。
gc 模块在 Python 3.12 中没有重构或替换原有分代回收逻辑，所谓“改进后的垃圾回收算法”是常见误解。Python 3.12 的 gc 行为与 3.11 完全一致：仍基于引用计数 + 三色分代（gen0/gen1/gen2），阈值默认仍是 (700, 10, 10)，触发逻辑、停顿特性、多线程全局性也都未变。
真正缓解卡顿的，从来不是“新算法”，而是你对现有机制的可控干预——比如调大 gc.set_threshold()。
为什么调大 gc.set_threshold(3000, 300, 30) 能减少卡顿
高频卡顿几乎都来自 gen0 频繁触发：每分配约 700 个新对象就停一次，每次虽短（~0.1–0.5ms），但密集循环里几百次/秒，人眼明显感知为“抖动”。
-
gc.set_threshold(3000, 300, 30)把 gen0 阈值从 700 提到 3000，触发频次降到原来的 ~1/4 - 单次 gen0 回收耗时略增（因要扫描更多对象），但总停顿时间下降、节奏更平滑
- 不影响 gen1/gen2 的晋升逻辑，只是拉长了“小回收”的间隔
注意：gc.set_threshold() 是全局生效的，不是 per-thread；设完后所有线程共享同一套阈值。
gc.collect(0) 和 gc.collect() 的区别直接影响卡顿感
主动触发回收时，选错参数会让卡顿更糟：
-
gc.collect(0)只清理 gen0，快（通常 -
gc.collect()（无参数）会逐代检查，可能触发 gen1 或 gen2 回收，耗时陡增（几 ms 到几十 ms），尤其在内存已堆积较多时 - 在 Web 请求处理中误用
gc.collect()，等于在关键路径上主动插入长停顿
建议：只在明确生命周期结束点（如大 list 构建完成、pandas.DataFrame 处理完毕）后调 gc.collect(0)；避免在循环内、高频回调里无差别调用。
macOS UI 自动化技能包 —— 用 Python 控制你的 Mac
下载
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
立即学习“Python免费学习笔记（深入）”；
哪些场景下 gc.set_threshold() 反而让程序更卡
不是阈值越大越好，关键看对象存活模式：
- 实时音视频帧处理（每帧 16ms 时限）：设
(10000, 1000, 100)后，单次 gen0 回收可能耗时 8ms，直接超帧 - 内存受限嵌入式环境：阈值过大 → gen0 积压对象过多 → 一次回收需遍历上万对象 → 停顿不可控
- 短生命周期 + 小对象密集分配（如 JSON 解析千级 dict）：阈值设太高，gen0 积压太多，反而增加标记开销
实操建议：print(gc.get_count()) 插在主循环开头，观察输出是否长期卡在 (690, x, y) —— 若是，说明 gen0 已濒临临界，调阈值才有效；若常为 (10, 0, 0)，说明当前分配节奏根本没触发 gen0，调阈值无意义。
真正容易被忽略的是：Python 3.12 没改 GC，但新增了 sys.monitoring（实验性）可挂钩内存分配事件，配合 gc.get_stats() 才能定位真实瓶颈。光调阈值不看 gc.get_count()，就像调油门不看转速表。
