Python的垃圾收集可以保证在任何情况下回收循环引用的对象吗? [英] Can Python's garbage collection guarantee the reclaiming of circular referenced objects under all circumstances?

查看:255
本文介绍了Python的垃圾收集可以保证在任何情况下回收循环引用的对象吗?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

这个问题是我之前问过的一个问题的扩展: Python委托模式 - 如何避免循环引用?阅读答复后,我决定澄清我的问题,但被要求单独发布。



这里是:


  1. Python文档中的一段(转载如下)指出垃圾收集不能保证循环
    被引用的对象。我发现一篇文章此处 a>表示同样的事情。但对我先前的问题的答复不同意。那么,我是否误解了这段经文,还是有更多的
    细节我错过了?

  2. 我想用一个弱点参考,正如Alex Martelli对<我应该担心Python中的循环引用吗?会避免开销垃圾收集完整回复中提到的循环引用对象?如果是这样,它是如何工作的?

相关的Python文档, by b $ b


CPython实现细节:CPython当前使用
引用计数方案,并且(可选)延迟检测
循环链接垃圾,收集大多数对象只要它们
变得无法访问,但是不能保证收集包含循环引用的垃圾
。有关控制循环垃圾收集的信息,请参阅gc模块
的文档。其他
实现的行为不同,CPython可能会发生变化。不要依赖
,当它们变得无法访问时,立即完成对象的定型(例如:
总是关闭文件)。

原始格式的文章可以在这里找到: http://docs.python.org/ reference / datamodel.html 粗体设置是我的。



感谢您提供任何回复。

从来没有 / em>如果它们定义了一个 __ del __ 方法,则会收集带有循环引用的对象。有一个漂亮的直接原因


Python不会自动收集这些循环,因为一般来说,Python不可能猜测运行的安全命令, __del __()方法。


我不愿意说这是 em>原因无法检测到具有循环引用的不可达对象。可能有一些不寻常的情况可能会阻碍GC的循环检测机制。但是除非你为其中一个对象定义了 __ del __ ,否则你很可能就是 。请不要担心,如果您发现性能问题,请使用GC广泛的调试选项。


This question is an extension of a question I asked earlier: Python Delegate Pattern - How to avoid circular reference? After reading the replies, I decided to clarify my question, but was requested to post it separately.

Here goes:

  1. A passage in the Python docs (reproduced below) states that garbaged collection is not guaranteed for circular referenced objects. A post I found here suggests the same thing. But the replies to my earlier question disagrees. So, have I misunderstood the passage or are there further details that I've missed?
  2. I suppose using a weak reference, as stated in Alex Martelli's reply to the question Should I worry about circular references in Python? would avoid the overhead for garbage collecting circular referenced objects mentioned in his reply entirely? If so how does it work?

The relevant Python docs that suggests conflicting following passage from Python's doc:

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).

The passage in its original form can be found here: http://docs.python.org/reference/datamodel.html The bold setting is mine.

Thanks in advance for any replies.

解决方案

I believe that the most important reason that objects with circular references aren't guaranteed to be collected is that, by design, Python never collects objects with circular references if they define a __del__ method. There is a pretty 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.

I am loath to say that this is the only reason unreachable objects with circular references might not be detected. There are probably a few unusual situations that could foil the GC's cycle detection mechanisms. But unless you define __del__ for one of your objects, you're probably ok. Just don't worry about it, and use the GC's extensive debugging options if you see performance issues.

这篇关于Python的垃圾收集可以保证在任何情况下回收循环引用的对象吗?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
相关文章
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆