Python的垃圾回收能否在所有情况下都保证回收循环引用的对象？

这个问题是我先前提出的问题的扩展：Python Delegate Pattern – How to avoid circular reference?阅读答复后,我决定澄清我的问题,但要求将其单独发布.

开始：

> Python文档中的一段(如下所示)指出,不能保证对循环进行垃圾回收
引用的对象.我发现here的帖子暗示了同样的事情.但是,对我之前的问题的答复不同意.所以,我误会了这段话还是在那边
我错过的细节？
>我想使用弱引用,如Alex Martelli在对问题Should I worry about circular references in Python?的答复中所述,将完全避免在他的答复中提到的垃圾收集循环引用对象的开销吗？如果是这样,它如何运作？

有关Python的文档,建议在从Python的文档中通过后出现冲突：

CPython implementation detail: CPython currently uses a
reference-counting scheme with (optional) delayed detection of
cyclically linked garbage, which collects most objects as soon as they
become unreachable, but is not guaranteed to collect garbage
containing circular references. See the documentation of the gc module
for information on controlling the collection of cyclic garbage. Other
implementations act differently and CPython may change. Do not depend
on immediate finalization of objects when they become unreachable (ex:
always close files).

该段落的原始形式可以在这里找到：http://docs.python.org/reference/datamodel.html我的是大胆的设置.

预先感谢您的任何答复.

解决方法:

我认为,不能保证具有循环引用的对象不能被收集的最重要原因是,根据设计,Python绝不会在定义__del__方法的情况下收集具有循环引用的对象.有一个漂亮的straightforward reason：

Python doesn’t collect such cycles automatically because, in general, it isn’t possible for Python to guess a safe order in which to run the __del__() methods.

我不愿意说这是可能无法检测到带有循环引用的不可达对象的唯一原因.可能有几种异常情况可能会破坏GC的循环检测机制.但是除非您为其中一个对象定义__del__,否则您可能会好的.只是不必担心,如果发现性能问题,请使用GC的广泛调试选项.

标签：circular-reference,python,garbage-collection
来源： https://codeday.me/bug/20191201/2079900.html