如何避免 Python 中的循环引用（Circular Reference）？-Python教程-PHP中文网

Python通过引用计数和循环垃圾回收器处理循环引用，但为提升效率，应优先使用弱引用或设计模式如依赖反转、中介者模式等从源头规避。

如何避免 python 中的循环引用（circular reference）？

Python中的循环引用，说白了，就是对象之间形成了一个封闭的引用链条，导致垃圾回收器（特指Python的引用计数机制）无法判断它们是否真的不再被需要，从而无法释放内存。要避免它，核心策略无非两种：要么主动打破这个强引用闭环，最常见的就是使用弱引用；要么就是从设计层面入手，从根源上规避这种相互依赖的结构。理解这一点，对于写出健壮、高效的Python代码至关重要。

解决方案

解决Python循环引用问题，需要结合对Python内存管理机制的理解，并采取相应的编程实践和设计模式。

首先，最直接且常用的方法是利用

weakref

登录后复制

模块提供的弱引用。弱引用不会增加对象的引用计数，因此即使对象被弱引用指向，当其所有强引用消失时，它仍然可以被垃圾回收。这在处理缓存、观察者模式或父子关系中，子对象需要引用父对象但又不希望阻止父对象被回收的场景下非常有效。

其次，从设计层面规避是更深层次的解决方案。这通常意味着重新思考对象间的关系和职责。例如，避免让两个对象互相持有对方的强引用。可以引入一个中间协调者来管理它们之间的通信，或者使用事件驱动机制，让对象通过发布/订阅模式进行交互，而不是直接持有对方的引用。在父子关系中，通常只让父对象持有子对象的强引用，而子对象如果需要引用父对象，则应使用弱引用。

立即学习“Python免费学习笔记（深入）”；

最后，虽然不常用，但在极少数情况下，如果循环引用无法通过弱引用或设计模式解决，并且你对对象的生命周期有非常精细的控制需求，可以考虑手动管理对象的引用，或者在特定时机通过

del

登录后复制

语句显式地删除引用，甚至调用

gc.collect()

登录后复制

来强制执行垃圾回收。但这通常被视为一种“下策”，因为它增加了代码的复杂性和出错的可能性，与Python的自动内存管理哲学相悖。

Python 垃圾回收机制是如何处理循环引用的？

Python的垃圾回收机制是一个分层的过程，它首先依赖于引用计数（Reference Counting），这是最基本也是最主要的内存管理方式。每个对象都有一个引用计数器，当有新的引用指向它时，计数器加一；当引用失效时，计数器减一。当计数器归零时，对象就会被立即回收。这个机制效率很高，因为它能即时回收内存。

然而，引用计数有一个致命的弱点：它无法处理循环引用。想象一下，对象A引用了对象B，同时对象B又引用了对象A。即使外部已经没有其他引用指向A和B，它们的引用计数却都至少为1（因为互相引用），导致引用计数永远不会归零。这样一来，这两个对象就永远无法被引用计数机制回收，形成了内存泄漏。

为了解决这个问题，Python引入了第二层垃圾回收机制，也就是一个独立的循环垃圾回收器（Cyclic Garbage Collector），它主要负责检测和回收那些引用计数不为零但实际上已经无法访问的循环引用对象。这个垃圾回收器会定期运行（或者在内存分配达到某个阈值时触发），它会遍历所有对象，构建一个引用图。然后，它会找出那些在引用图中形成闭环，并且这些闭环中的所有对象都无法从根对象（比如全局变量、栈帧中的局部变量）访问到的对象集合。一旦找到这样的集合，它就会“打破”这些循环引用，将这些对象标记为可回收，并最终释放它们的内存。

这个循环垃圾回收器是Python

gc

登录后复制

模块的核心。虽然它解决了循环引用问题，但它的运行会带来一定的性能开销，因为它需要遍历和分析大量的对象。所以，我们通过设计模式和弱引用来主动避免循环引用，实际上是在帮助Python的垃圾回收器减轻负担，提高程序的整体效率。毕竟，能避免的问题，最好还是避免掉，而不是寄希望于“善后”机制。

智谱清言 - 免费全能的AI助手

查看详情

什么时候应该考虑使用弱引用（Weak References）？

弱引用在Python中扮演着一个非常巧妙的角色，它允许你引用一个对象，但又不会阻止这个对象被垃圾回收器回收。这听起来有点矛盾，但正是这种“弱”关联，在某些特定场景下显得尤为重要。

我个人觉得，当你遇到以下几种情况时，就应该认真考虑使用弱引用了：

构建缓存系统： 这是一个经典的应用场景。你可能需要一个缓存来存储计算结果或加载的数据，但又不希望缓存中的对象永远占据内存。如果一个缓存项不再被其他地方强引用，它就应该被清除。使用弱引用作为缓存的值（或键），可以确保当原对象不再被需要时，缓存中的引用也会自动失效，从而实现自动化的缓存清理。
实现观察者模式（Observer Pattern）： 在这种模式中，一个“主题”（Subject）对象需要通知多个“观察者”（Observer）对象。如果主题持有观察者的强引用，那么即使某个观察者不再被程序其他部分使用，它也会因为被主题引用而无法被回收。这会导致潜在的内存泄漏。通过让主题持有观察者的弱引用，当观察者自身生命周期结束时，它就可以被正常回收，而主题的弱引用也会自动失效。
处理父子关系中的反向引用： 比如，你有一个树形结构，每个子节点都有一个指向其父节点的引用。通常，父节点会持有子节点的强引用。如果子节点也强引用其父节点，那么就形成了循环引用。在这种情况下，子节点应该持有父节点的弱引用。这样，当父节点被删除时，子节点对其的弱引用不会阻止父节点被回收。
大型数据结构中避免不必要的强引用： 有时，为了方便导航或查找，我们会在复杂的数据结构中添加一些辅助性的引用。如果这些引用不是数据结构核心生命周期的一部分，并且可能形成循环，那么使用弱引用是明智的选择。

使用弱引用时，你需要记住它返回的实际上是一个“弱引用对象”(

weakref.ref

登录后复制

的实例)，你需要调用它才能获取到实际的对象。如果原对象已经被回收，调用弱引用对象会返回

None

登录后复制

。这要求你在代码中做好

None

登录后复制

值的检查，这也是使用弱引用带来的额外复杂度。但权衡之下，为了避免内存泄漏和更清晰的内存管理，这点复杂度是值得的。

除了弱引用，还有哪些设计模式可以有效规避循环引用？

除了弱引用这个直接的工具，我们更应该从软件设计的角度出发，通过一些成熟的设计模式来从根本上减少甚至消除循环引用的可能性。这是一种更高级的“预防胜于治疗”的思路。

依赖反转原则（Dependency Inversion Principle, DIP）和接口/抽象： 这是SOLID原则之一，它的核心思想是高层模块不应该依赖低层模块，两者都应该依赖抽象。抽象不应该依赖细节，细节应该依赖抽象。当两个对象A和B需要交互时，与其让A直接引用B，B又直接引用A，不如引入一个接口（或抽象基类）。A依赖于这个接口，B也实现这个接口。这样，A和B之间就没有了直接的、相互的强引用，而是通过一个抽象层进行解耦。例如，A需要一个
```
Logger
```
登录后复制
，B是一个
```
FileLogger
```
登录后复制
。A不直接引用
```
FileLogger
```
登录后复制
，而是引用一个
```
ILogger
```
登录后复制
接口，
```
FileLogger
```
登录后复制
实现
```
ILogger
```
登录后复制
。这种方式极大地降低了对象间的耦合度，自然也就减少了循环引用的机会。
中介者模式（Mediator Pattern）： 当多个对象之间存在复杂的交互逻辑，并且它们之间相互引用以实现通信时，中介者模式可以派上用场。它引入一个中介者对象，所有的对象都不直接相互通信，而是通过中介者进行。这样，每个对象只需要知道中介者，而不需要知道其他具体对象的存在。中介者负责协调对象间的行为。这有效地打破了对象间的直接引用链，将多对多的复杂关系转换成多对一的关系，从而避免了循环引用。
事件驱动架构（Event-Driven Architecture）/发布-订阅模式： 这与观察者模式有相似之处，但更强调解耦。对象通过发布事件和订阅事件来通信，而不是直接调用对方的方法。发布者发出事件，订阅者监听并响应事件。发布者通常不需要知道具体的订阅者是谁，甚至可以不持有订阅者的引用（或者只持有弱引用）。这种模式将对象的行为和状态变化转化为可传播的事件，彻底解耦了生产者和消费者，极大地降低了直接引用导致的循环风险。
工厂模式（Factory Pattern）或建造者模式（Builder Pattern）： 在某些情况下，循环引用可能发生在对象的创建和组装阶段。例如，对象A在创建时需要B，B在创建时又需要A。通过引入工厂或建造者，可以将对象的创建逻辑集中管理。工厂负责根据需要创建和组装对象，并可以控制它们之间的引用关系，确保不会产生不必要的循环强引用。它能够在一个受控的环境中建立对象间的联系，而不是让对象在各自的构造函数中互相请求。