在列表，元组，实例，类，字典和函数中存在轮回引用问题。有 __del__ 要领的实例会以健全的方法被处理惩罚。给新范例添加GC支持是很容易的。支持GC的Python与通例的Python是二进制兼容的。
分代式接纳能运行事情（今朝是三个分代）。由 pybench 实测的功效是约莫有百分之四的开销。实际上所有的扩展模块都应该依然如故地正常事情（我不得不修改了尺度刊行版中的 new 和 cPickle 模块）。一个叫做 gc 的新模块顿时就可以用来调试接纳器和配置调试选项。
接纳器应该是跨平台可移植的。Python 的补丁版本通过了所有的回归测试而且跑 Grail、Idle 和 Sketch 的时候没有任何问题。
自 Python 2.0 和之后的版本，可移植的垃圾接纳机制已经包罗在个中了。垃圾接纳默认是开启的。请兴奋些吧！
为什么我们需要垃圾接纳？
今朝版本的 Python 回收引用计数的方法来打点分派的内存。Python 的每个工具都有一个引用计数，这个引用计数表白了有几多工具在指向它。当这个引用计数为 0 时，该工具就释放了。引用计数对付大都措施都事情地很好。然而，引用计数有一个本质上的缺陷，是由于轮回引用引起的。轮回引用最简朴的例子就是一个引用自身的工具。好比：
>>> l = [] >>> l.append(l) >>> del l
这个建设的列表的引用计数此刻是 1。然而，因为它从 Python 内部已经无法会见，而且大概没法再被用到了，它应该被看成垃圾。在今朝版本的 Python 中，这个列表永远不会被释放。
一般环境下轮回引用不是一个好的编程实践，而且险些总该被制止。然而，有时候很难制止制造轮回引用，要么则是措施员甚至没有察觉到轮回引用的问题。对付恒久运行的措施，好比处事器，这个问题出格令人烦恼。人们可不想他们的处事器因为轮回引用无法释放会见不到的工具而耗尽内存。对付大型措施，很难发明轮回引用是怎么缔造出来的。
“传统的”垃圾接纳是奈何的?
传统的垃圾接纳（好比标志-排除法可能遏制-拷贝法）凡是事情如下：
找到系统的根工具。根工具就像是全局的情况（好比 Python 中的 __main__ 模块）和仓库上的工具。
从这些工具搜索所有的可以会见的工具。这些工具都是“活泼”的。
释放其他所有工具。
不幸的是这个要领不能用于当前版本的 Python。由于扩展模块的事情方法，Python 不能完全地确定根工具荟萃。假如根工具荟萃没法被精确地确定，我们就有释放仍然被引用的工具的风险。纵然用其他方法设计扩展模块，也没有可移植的方法来找到当前 C 仓库上的工具。并且，引用计数提供了一些 Python 措施员已然等候的有关局部性内存引用和终结语义的长处。最好是我们可以或许找到一个即能利用引用计数，又可以或许释放轮回引用的的步伐。
这个要领如何事情？
从观念上讲，这个要领与传统垃圾接纳机制相反。这个要领试图去找到所有的不行会见工具，而不是去找所有的可会见工具。这样越发安详，因为假如这个算法失败了，起码不会比不举办垃圾接纳还要糟（不思量我们挥霍掉的时间和空间）。
因为我们仍然在用引用计数，垃圾接纳器只需要找到轮回引用。引用计数会处理惩罚其他范例垃圾。首先我们调查到轮回引用只能被容器工具缔造。容器工具是可以包括其他工具的引用的工具。在Python中，列表、字典、实例、类和元祖都是容器工具的例子。整数和字符串不是容器。通过这个发明，我们意识到非容器工具可以被垃圾接纳忽略。这是一个有用的优化因为整数和字符串这样的应该较量轻快。
此刻我们的想法是记录所有的容器工具。有几种要领可以做到，然而最好的一种步伐是操作双向链表，链表中的工具布局中包括指针字段。这样就可以使工具从荟萃中快速插入删除，并且不需要特别内存空间分派。当一个容器被建设，它就插入这个荟萃，被删除时，就从荟萃中去除。
既然我们可以或许获得所有的容器工具，我们怎么找到轮回引用呢？首先我们往容器工具中添加两个指针外的另一个字段。我们定名这个字段 gc_refs。通过以下几步我们可以找到轮回引用：
对每个容器工具，设 gc_refs 的值为工具的引用计数。
对每个容器工具，找到它引用的其他容器工具并把它们的 gc_refs 值减一。
所有的 gc_refs 大于 1 的容器工具是被容器工具荟萃外的工具所引用的。我们不能释放这些工具，所以我们把这些工具放到另一个荟萃。
被移走的工具所引用的工具也不能被释放。我们把它们和它们能会见到的工具都从今朝荟萃移走。
在今朝荟萃中的剩下的工具是仅被该荟萃中工具引用的（也就是说，他们无法被 Python 取到，也就是垃圾）。我们此刻可以去释放这些工具。
Finalizer的问题
#p#分页标题#e#
我们的雄伟打算尚有一个问题，就是利用 finalizer 的问题。Finalizer 就是在 Python 中实例的__del__要领。利用引用计数时，Finalizer 事情地不错。当一个工具的引用计数降到 0 的时候，Finalizer 就在工具被释放前挪用了。对措施员来说这是直接明白且容易领略的。
垃圾接纳的时候，挪用 finalizer 就成了一个贫苦的问题，尤其是面临轮回引用的问题时。假如在轮回引用中的两个工具都有 finalizer，该怎么做？先挪用哪个？在挪用第一个 finalizer 之后，这个工具无法被释放因为第二个 finalizer 还能取到它。
因为这个问题没有好的办理步伐，被有 finalizer 的工具引用的轮回是无法释放的。相反的，这些工具被加进一个全局的无法接纳垃圾列表中。措施应该老是可以从头编写来制止这个问题。作为最后的手段，措施可以读取这个全局列表并以一种对付当前应用有意义的方法释放这些引用轮回。
价钱是什么？
就像有些人说的，天底下没有免费的午餐。然而，这种垃圾接纳形式是相当便宜的。最大的价钱之一是每各容器工具特别需要的三个字的内存空间。尚有维护容器荟萃的开销。对当前版本的垃圾收集器来说，基于 pybench 这个开销或许是速度下降百分之四。
垃圾接纳器今朝记录工具的三代信息。通过调解参数，垃圾接纳耗费的时间可以想多小就多小。对一些应用来说，关掉自动垃圾接纳并在运行时显式挪用也许是有意义的。然而，以默认的垃圾接纳参数运行 pybench，垃圾接纳耗费的时间看起来并不大。显而易见，大量分派容器工具的应用会引起更多的垃圾接纳时间。
今朝的补丁增加了一个新的设置项来激活垃圾接纳器。有垃圾接纳器的 Python 与尺度 Python 是二进制兼容的。假如这个选项是封锁的，对 Python 表明器的事情就没有影响。
我该怎么利用它？
只要下载今朝版本的 Python 就可以了。垃圾接纳器已经包罗在了 2.0 今后的版本中，而且默认是默认开启的。假如你在用 Python 1.5.2 版，这里有一个也许能事情的老版本的补丁。假如你用的是 Windows 平台，你可以下载一个用来替代的 python15.dll。
Boehm-Demers 守旧垃圾接纳
这个补丁增加了一些修改到 Python 1.5.2，以利用 Boehm-Demers 守旧垃圾接纳。可是你必需先打上这个补丁。依然是回收了引用计数。垃圾接纳器只释放引用计数没有释放的内存（即轮回引用）。这样应该机能最好。你需要：
$ cd Python-1.5.2 $ patch -p1 < ../gc-malloc-cleanup.diff $ patch -p1 < ../gc-boehm.diff $ autoconf $ ./configure --with-gc
这个补丁假设你安装了 libgc.a，使得 -lgc 链接选项可用（/usr/local/lib 也应该可以）。假如你没有这个库，在编译以前下载安装。
今朝，这个补丁只在 Linux 上测试过。在其 他Unix 呆板上也许也会事情。在我的 Linux 呆板上，GC 版本的 Python 通过了所有的回归测试。
