Python中的循环引用虽能被垃圾回收器处理，但一旦涉及`__del__`方法、全局变量或C扩展持有，便极易引发内存缓慢泄漏，尤其在长周期服务中危害显著；典型场景涵盖树形结构的父子节点双向引用、观察者模式中的互相注册、闭包或装饰器隐式捕获对象，以及缓存字典中键值互持等；真正可靠的解法不是依赖`gc.collect()`救火或`DEBUG_SAVEALL`调试，而是从设计层面用`weakref`精准打破非生命周期必需的强引用链——如子节点对父节点的“只读访问”、使用`WeakKeyDictionary`管理缓存，并辅以`objgraph`进行可视化回溯分析，从而在源头规避隐患。

循环引用通常出现在对象互相持有对方的强引用时

Python 的垃圾回收器（GC）能处理大多数循环引用，但前提是这些对象没有 __del__ 方法，且不被全局变量、模块级字典或 C 扩展长期持有着。一旦出现未被及时清理的循环引用，就可能造成内存缓慢增长，尤其在长周期服务中容易暴露问题。

典型场景包括：树形结构父子节点双向引用、观察者模式中对象互相注册、缓存字典里键值互为引用等。

• 父节点保存子节点列表，子节点又通过 parent 属性反向引用父节点
• 用 dict 缓存函数结果，而缓存值本身又持有该 dict 的引用（比如闭包捕获）
• 类中定义了 __del__，又参与了循环，此时 GC 会将其放入 gc.garbage 而不自动清理

用 weakref 打破非必需的强引用链

当某一方的引用只是“观测”或“临时访问”用途，而非生命周期依赖，就该用 weakref 替代直接赋值。它不会阻止被引用对象被回收，也天然避开循环引用问题。

例如子节点需要访问父节点但不决定其存活：

import weakref
class Node:
def init(self, parent=None):
self._parent_ref = weakref.ref(parent) if parent else None
@property
def parent(self):
    return self._parent_ref() if self._parent_ref else None

• 不要对函数、类、模块用 weakref.ref——它们是全局常驻对象，弱引用无意义
• 避免在 __del__ 中调用 weakref.ref() 或访问已可能被销毁的对象
• weakref.WeakKeyDictionary 和 weakref.WeakValueDictionary 更适合缓存场景，键或值被回收后条目自动消失

gc.collect() 不是修复手段，而是诊断工具

手动调用 gc.collect() 可以触发一次完整回收，并返回本次清理的循环引用对象数量。但它不能替代设计上的解耦——频繁靠它“救场”，说明引用关系没理清。

• 调试时可加 gc.set_debug(gc.DEBUG_SAVEALL)，之后未回收对象会留在 gc.garbage 里供检查
• 生产环境禁用 DEBUG_SAVEALL，它会导致内存泄漏（因为对象被强制保留）
• 若 gc.collect() 返回值持续增大，应结合 gc.get_objects() 或 objgraph 定位具体类型

闭包和装饰器里容易藏匿隐式循环引用

闭包会捕获外部作用域的变量，如果这个变量恰好是当前正在构造的对象，就构成循环。装饰器返回的 wrapper 函数若引用了被装饰实例，也一样。

常见错误写法：

def make_processor(obj):
    def process():
        return obj.do_something()  # obj 被闭包持有
    return process
若 obj 是某个实例，且 process 被存进 obj 的属性里，就成环了

• 用 functools.partial 替代闭包，它不捕获整个作用域，只绑定明确参数
• 装饰器中避免把 self 或实例传进闭包；改用描述符或绑定方法（types.MethodType）更可控
• 用 __slots__ 限制实例属性，能减少意外引用（比如误存了闭包函数到实例上）

实际项目里最难察觉的是跨模块、跨线程的间接引用，比如一个全局事件总线里注册了 A 对象的方法，而 A 又持有了总线实例——这种链路得靠 objgraph.show_backrefs() 搭配截图分析。别指望单靠 del 或 gc.collect() 解决。

好了，本文到此结束，带大家了解了《Python循环引用怎么产生及避免方法》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！