通过gc.get_count()观察第一代计数频繁跳变且接近700阈值，或开启gc.set_debug(gc.debug_stats)查看“collected n objects”日志，可判断gc频繁触发。
怎么知道 gc 正在频繁触发？
看 gc.get_count() 的返回值，三个数分别代表 0、1、2 代的当前对象计数。如果第一代（索引 1）数值频繁跳变、且常接近阈值（默认 700），基本就是 gc 在反复干活。更直接的是开调试模式：gc.set_debug(gc.DEBUG_STATS)，之后每次自动回收都会打印统计信息——注意别在生产环境开，它本身有性能开销。
- 典型误判：只看内存占用上涨就以为是 gc 慢，其实可能只是对象没被引用释放，gc 根本收不走
- 真实信号是日志里出现大量 “collected N objects” 或 “collecting generation X”
-
gc.get_threshold()返回当前阈值，修改前务必记下原值，避免调低后引发雪崩式回收
为什么手动调用 gc.collect() 有时反而更慢？
因为默认调用的是全代回收（generation 2），会扫描所有存活对象，包括长期驻留的老对象。多数时候你真正想清理的是刚产生的短生命周期对象（generation 0），这时应该明确指定：gc.collect(0)。尤其在循环内或高频路径上，无参数调用等于主动给自己加锁+遍历全局堆。
- Web 请求处理中，在 request 结束时调
gc.collect(0)，比放gc.collect()更安全 - 异步任务（如 asyncio）里慎用，
gc.collect()是阻塞操作，可能卡住事件循环 - PyPy 下效果差异大，它的 gc 机制不同，手动触发收益极小，甚至负向
循环引用导致对象无法被释放，怎么快速定位？
先确认是不是真由循环引用引起：用 gc.garbage 查看未被回收的对象列表（需提前启用垃圾回收器：gc.disable() → gc.enable() → 再检查）。更实用的是结合 gc.get_referrers() 和 gc.get_referents() 追踪引用链。例如怀疑某个类实例泄漏，就拿它的 id 去查谁在引用它。
- 常见陷阱：闭包捕获了外部对象、回调函数存了 self、weakref 不当使用（比如忘了用
weakref.ref而用了普通引用） -
obj.__dict__和vars(obj)里藏的字典容易形成隐式循环，特别是动态绑定属性时 - 用
objgraph.show_backrefs([obj], max_depth=5)（需装 objgraph）比纯 gc 模块更直观，但属于额外依赖
关闭 gc 能提升性能吗？什么情况下可以关？
能，但仅限非常特定的场景：程序生命周期短（如 CLI 工具）、对象全部是原子类型（int/str/tuple）、且确定没有循环引用。python 启动时默认开启 gc，关掉后 gc.collect() 失效，gc.get_count() 始终返回 (0, 0, 0)。一旦存在未显式断开的循环引用，内存就只增不减。
立即学习“Python免费学习笔记（深入）”；
- Web 应用、长时服务、含自定义类的逻辑，一律不要关
- 子进程里可考虑关闭（如 multiprocessing 中的 worker），前提是父进程已确保资源干净退出
- 关闭后若出现 “cannot collect” 类错误，说明代码里有依赖 gc 清理的逻辑（比如某些 __del__ 方法），得重写
实际调优时，最常被忽略的是代际阈值与业务节奏的匹配。比如批处理每 1000 行做一次 gc.collect(0)，比依赖默认 700 阈值更可控；而阈值设成 10000 可能导致单次回收卡顿 200ms——这比多几次小回收更伤体验。