在什么情况下，**Python** 的循环垃圾收集器即使检测到彼此循环引用的对象也拒绝销毁它们？

问题的答案

问题的历史

这个话题源于 Python 从纯引用计数演变到在 Python 2.0 中引入的混合垃圾收集模型。当开发者使用终结器方法（__del__）来管理外部资源（如文件句柄或网络套接字）时，核心问题出现了。当具有终结器的对象形成循环引用时，Python 无法确定安全的销毁顺序，可能导致崩溃或资源泄漏。这一局限性导致了循环垃圾收集器模块（gc）的实施和“不可回收”垃圾的特别处理。

问题

当一组对象形成引用循环且至少有一个定义了自定义的 __del__ 方法时，Python 面临一个确定性销毁的困境。解释器无法决定首先终结哪个对象，因为循环暗示了相互依赖，销毁一个可能会使其他对象处于无效状态。因此，Python 将这些对象移动到 gc.garbage 列表中，而不是释放它们的内存。这种行为在现代版本中仍然存在，当终结器阻止安全的收集时，会导致长期运行的应用程序逐渐发生内存泄漏。

解决方案

确定的解决方案涉及完全避免使用 __del__ 方法，转而使用上下文管理器（with 语句）或 weakref 回调来清理资源。如果终结器是不可避免的，请在对象变为不可访问之前通过在清理方法中将实例变量设置为 None 来显式打破引用循环。从 Python 3.4 开始，垃圾收集器可以通过仔细的终结顺序在许多情况下收集具有终结器的循环，但显式资源管理仍然是最可靠的模式。

import gc

class Resource:
    def __init__(self, name):
        self.name = name
        self.peer = None
        
    def __del__(self):
        print(f"正在清理 {self.name}")

# 创建带有终结器的循环
a = Resource("A")
b = Resource("B")
a.peer = b
b.peer = a

# 移除外部引用
del a, b

gc.collect()
print(f"不可回收: {gc.garbage}")  # 可能包含复杂场景中的对象

生活中的情况

我们维护了一个高吞吐量的数据处理管道，其中 Node 对象代表图中的计算步骤。每个节点持有对其邻居的引用，并包含一个 __del__ 方法来释放 GPU 内存句柄。在高强度工作负载下，我们观察到单调的内存增长，尽管在分析中没有明显的内存泄漏。调查显示复杂的图拓扑造成功能节点之间的引用循环，并且 __del__ 方法的存在阻止了循环 GC 回收这些对象，使它们在 gc.garbage 中累积，直到进程终止。

解决方案 1: 重构为上下文管理器

我们考虑用显式的 acquire() 和 release() 方法替代 __del__，通过上下文管理器调用。这种方法将完全消除终结器对垃圾收集的障碍并提供确定性的资源清理。然而，这需要修改数千行的图构造代码，并且如果开发者忘记在 with 块中包装节点使用，尤其是在遗留的基于回调的组件中，可能会导致资源泄漏。

解决方案 2: 为图边实现弱引用

我们探讨将所有邻居引用更改为 weakref.ref 对象，这样当没有外部引用时，节点可以立即被收集，而与图连接无关。尽管优雅，但这引入了显著的复杂性，因为图遍历算法需要在迭代期间不断检查死弱引用并处理瞬态“幽灵”节点。这种方法大大降低了我们用例的性能，并且需要广泛重构图遍历逻辑。

解决方案 3: 通过清理协议显式打破循环

我们实现了一个 destroy() 方法，它显式地将 self.neighbors = [] 和 self.gpu_handle = None ，然后再从图中移除节点。这在保留现有 API 接口的同时以确定性方式打破了循环。我们选择了这个解决方案，因为它将更改局限于节点移除逻辑，而不是在整个代码库中传播关注点，并且与现有图算法保持向后兼容。

结果

在实施显式清理协议并添加断言以验证 gc.garbage 在 CI 测试期间保持为空后，内存使用量稳定在常量基线。服务运行了数周，没有之前逐渐增加的内存。我们还记录了该模式，以确保未来的开发者能够理解终结器和循环引用之间的相互作用。

候选人常常忽略的问题

为什么在 Python 3.4+ 中即使在循环中存在终结器， gc.garbage 仍然包含对象？

虽然 Python 3.4 大幅改善了循环 GC，能够通过安全顺序调用终结器并在之后清除引用，但在特定条件下，对象可能仍然出现在 gc.garbage 中。如果 __del__ 方法通过将对象存储在全局变量中复活对象，则 GC 无法安全地收集循环，并将其移动到 gc.garbage 中，以防止无限循环。此外，具有自定义 tp_dealloc 槽的 C 扩展对象，如果未正确支持循环 GC 协议，也可能被视为不可回收，以避免在本地代码中崩溃。

当引用方是不可回收的循环一部分时， weakref.ref 与回调如何与循环垃圾收集器交互？

候选人常常错误地假设，弱引用回调在对象变得不可访问时立即触发。实际上，回调在对象实际被销毁并且内存被释放时触发。如果对象参与一个包含终结器的引用循环，GC 无法打破，该对象将保持分配在 gc.garbage 中，弱引用回调将永远不会执行。这一区别对于设计依赖于弱引用回调来通知对象销毁的资源清理系统至关重要。

__del__ 方法中的"复活"问题是什么，它如何阻止循环引用的垃圾收集？

复活发生在终结器方法将即将销毁的实例分配给全局变量或将其插入持久容器，从而在 GC 将其标记为销毁后有效地复活它。在循环引用场景中，如果一个对象的 __del__ 复活了循环内的任何对象，则整个循环再次变得可达。Python 的垃圾收集器检测到这一异常，并将整个循环移动到 gc.garbage 中，而不是尝试解决潜在的无尽销毁和复活循环，直到进程终止时才释放内存。