gc.collect() 不总回收类实例，因其仅处理不可达对象；若实例仍被隐式引用（如循环引用、全局缓存、__del__异常或弱引用容器残留），则无法回收。
为什么 gc.collect() 有时不回收你的类实例
手动调用 gc.collect() 并不能保证立即回收某个特定类实例，尤其当该实例仍被隐式引用（比如循环引用、全局字典缓存、__del__ 中的异常、或弱引用容器未清理）时。Python 的垃圾回收器（GC）只处理「不可达对象」，而「可达性」取决于整个引用图——不是你删了 del obj 就算完事。
常见现象包括：
- 调用
gc.collect()返回 0，但内存没降 -
obj的__del__方法没执行 -
gc.get_referrers(obj)显示还有意外持有者（如日志装饰器、信号槽、线程局部存储）
确认实例是否真被回收：用 gc.get_objects() 和 id() 追踪
别靠内存监控猜，直接查 GC 堆里还有没有那个实例。关键步骤是：在创建后记下 id(obj)，再触发回收后检查是否仍在 gc.get_objects() 结果中。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 用
gc.disable()临时关掉自动 GC，避免干扰观察 - 调用
gc.collect(generation=0)先清第 0 代（最频繁），再逐步试generation=1、2 - 检查前加
gc.collect()两次——第一次解引用，第二次才真正回收（尤其有__del__时） - 示例片段：
import gc<br>class Demo: pass<br>obj = Demo()<br>oid = id(obj)<br>del obj<br>gc.collect() # 可能还不够<br>gc.collect() # 再来一次<br>found = any(id(o) == oid for o in gc.get_objects())
类定义中影响回收的关键点：__del__、循环引用、弱引用
__del__ 是双刃剑：它让对象进入「带 finalizer 的不可达集合」，但一旦其中抛出异常，该对象会被永久留在 gc.garbage 里，后续 gc.collect() 都无法清理它。
循环引用场景更常见，比如：
- A 实例持有一个函数闭包，该闭包又引用了 A
- 父子类结构中，子类实例通过属性反向引用父类管理器
- 使用
functools.lru_cache装饰实例方法（缓存键含self）
此时必须打破引用环，或改用 weakref.ref 存储反向引用。例如：
import weakref<br>class Parent:<br> def __init__(self):<br> self._child_ref = None<br> def set_child(self, child):<br> self._child_ref = weakref.ref(child) # 不增加引用计数
生产环境慎用 gc.collect()：代价与替代方案
主动调用 gc.collect() 在多数场景下是过早优化，甚至有害——它会暂停所有线程、扫描整个堆，对 latency 敏感服务（如 Web API）可能引发毛刺。CPython 默认的三代分代策略已足够高效。
更务实的做法：
- 优先用
del obj+ 显式置None清除长生命周期引用（如模块级变量、类属性） - 大对象（如 NumPy 数组、PIL 图像）及时调用其自有释放方法（
.close()、.delete()） - 怀疑泄漏时，用
objgraph.show_growth()或tracemalloc定位源头，而不是狂刷gc.collect() - 若真需控制，用
gc.set_threshold(500, 5, 5)调低第 0 代阈值，比手动 collect 更平滑
真正难搞的从来不是「怎么触发回收」，而是「为什么这个实例还在被谁拿着」——多花一分钟查 gc.get_referrers(obj)，胜过十次 gc.collect()。
