概要

在列表，元組，實(shí)例，類，字典和函數(shù)中存在循環(huán)引用問題。有 __del__ 方法的實(shí)例會(huì)以健全的方式被處理。給新類型添加GC支持是很容易的。支持GC的Python與常規(guī)的Python是二進(jìn)制兼容的。

分代式回收能運(yùn)行工作（目前是三個(gè)分代）。由 pybench 實(shí)測(cè)的結(jié)果是大約有百分之四的開銷。實(shí)際上所有的擴(kuò)展模塊都應(yīng)該依然如故地正常工作（我不得不修改了標(biāo)準(zhǔn)發(fā)行版中的 new 和 cPickle 模塊）。一個(gè)叫做 gc 的新模塊馬上就可以用來調(diào)試回收器和設(shè)置調(diào)試選項(xiàng)。

回收器應(yīng)該是跨平臺(tái)可移植的。Python 的補(bǔ)丁版本通過了所有的回歸測(cè)試并且跑 Grail、Idle 和 Sketch 的時(shí)候沒有任何問題。

自 Python 2.0 和之后的版本，可移植的垃圾回收機(jī)制已經(jīng)包括在其中了。垃圾回收默認(rèn)是開啟的。請(qǐng)高興些吧！

為什么我們需要垃圾回收？

目前版本的 Python 采用引用計(jì)數(shù)的方式來管理分配的內(nèi)存。Python 的每個(gè)對(duì)象都有一個(gè)引用計(jì)數(shù)，這個(gè)引用計(jì)數(shù)表明了有多少對(duì)象在指向它。當(dāng)這個(gè)引用計(jì)數(shù)為 0 時(shí)，該對(duì)象就釋放了。引用計(jì)數(shù)對(duì)于多數(shù)程序都工作地很好。然而，引用計(jì)數(shù)有一個(gè)本質(zhì)上的缺陷，是由于循環(huán)引用引起的。循環(huán)引用最簡(jiǎn)單的例子就是一個(gè)引用自身的對(duì)象。比如：

>>> l = []
>>> l.append(l)
>>> del l

這個(gè)創(chuàng)建的列表的引用計(jì)數(shù)現(xiàn)在是 1。然而，因?yàn)樗鼜?Python 內(nèi)部已經(jīng)無法訪問，并且可能沒法再被用到了，它應(yīng)該被當(dāng)作垃圾。在目前版本的 Python 中，這個(gè)列表永遠(yuǎn)不會(huì)被釋放。

一般情況下循環(huán)引用不是一個(gè)好的編程實(shí)踐，并且?guī)缀蹩傇摫槐苊?。然而，有時(shí)候很難避免制造循環(huán)引用，要么則是程序員甚至沒有察覺到循環(huán)引用的問題。對(duì)于長(zhǎng)期運(yùn)行的程序，比如服務(wù)器，這個(gè)問題特別令人煩惱。人們可不想他們的服務(wù)器因?yàn)檠h(huán)引用無法釋放訪問不到的對(duì)象而耗盡內(nèi)存。對(duì)于大型程序，很難發(fā)現(xiàn)循環(huán)引用是怎么創(chuàng)造出來的。

“傳統(tǒng)的”垃圾回收是怎樣的?

傳統(tǒng)的垃圾回收（比如標(biāo)記-清除法或者停止-拷貝法）通常工作如下：

找到系統(tǒng)的根對(duì)象。根對(duì)象就像是全局的環(huán)境（比如 Python 中的 __main__ 模塊）和堆棧上的對(duì)象。
從這些對(duì)象搜索所有的可以訪問的對(duì)象。這些對(duì)象都是“活躍”的。
釋放其他所有對(duì)象。
不幸的是這個(gè)方法不能用于當(dāng)前版本的 Python。由于擴(kuò)展模塊的工作方式，Python 不能完全地確定根對(duì)象集合。如果根對(duì)象集合沒法被準(zhǔn)確地確定，我們就有釋放仍然被引用的對(duì)象的風(fēng)險(xiǎn)。即使用其他方式設(shè)計(jì)擴(kuò)展模塊，也沒有可移植的方式來找到當(dāng)前 C 堆棧上的對(duì)象。而且，引用計(jì)數(shù)提供了一些 Python 程序員已然期待的有關(guān)局部性內(nèi)存引用和終結(jié)語(yǔ)義的好處。最好是我們能夠找到一個(gè)即能使用引用計(jì)數(shù)，又能夠釋放循環(huán)引用的的辦法。

這個(gè)方法如何工作？

從概念上講，這個(gè)方法與傳統(tǒng)垃圾回收機(jī)制相反。這個(gè)方法試圖去找到所有的不可訪問對(duì)象，而不是去找所有的可訪問對(duì)象。這樣更加安全，因?yàn)槿绻@個(gè)算法失敗了，起碼不會(huì)比不進(jìn)行垃圾回收還要糟（不考慮我們浪費(fèi)掉的時(shí)間和空間）。

因?yàn)槲覀內(nèi)匀辉谟靡糜?jì)數(shù)，垃圾回收器只需要找到循環(huán)引用。引用計(jì)數(shù)會(huì)處理其他類型垃圾。首先我們觀察到循環(huán)引用只能被容器對(duì)象創(chuàng)造。容器對(duì)象是可以包含其他對(duì)象的引用的對(duì)象。在Python中，列表、字典、實(shí)例、類和元祖都是容器對(duì)象的例子。整數(shù)和字符串不是容器。通過這個(gè)發(fā)現(xiàn)，我們意識(shí)到非容器對(duì)象可以被垃圾回收忽略。這是一個(gè)有用的優(yōu)化因?yàn)檎麛?shù)和字符串這樣的應(yīng)該比較輕快。

現(xiàn)在我們的想法是記錄所有的容器對(duì)象。有幾種方法可以做到，然而最好的一種辦法是利用雙向鏈表，鏈表中的對(duì)象結(jié)構(gòu)中包含指針字段。這樣就可以使對(duì)象從集合中快速插入刪除，而且不需要額外內(nèi)存空間分配。當(dāng)一個(gè)容器被創(chuàng)建，它就插入這個(gè)集合，被刪除時(shí)，就從集合中去除。

既然我們能夠得到所有的容器對(duì)象，我們?cè)趺凑业窖h(huán)引用呢？首先我們往容器對(duì)象中添加兩個(gè)指針外的另一個(gè)字段。我們命名這個(gè)字段 gc_refs。通過以下幾步我們可以找到循環(huán)引用：

對(duì)每個(gè)容器對(duì)象，設(shè) gc_refs 的值為對(duì)象的引用計(jì)數(shù)。
對(duì)每個(gè)容器對(duì)象，找到它引用的其他容器對(duì)象并把它們的 gc_refs 值減一。
所有的 gc_refs 大于 1 的容器對(duì)象是被容器對(duì)象集合外的對(duì)象所引用的。我們不能釋放這些對(duì)象，所以我們把這些對(duì)象放到另一個(gè)集合。
被移走的對(duì)象所引用的對(duì)象也不能被釋放。我們把它們和它們能訪問到的對(duì)象都從目前集合移走。
在目前集合中的剩下的對(duì)象是僅被該集合中對(duì)象引用的（也就是說，他們無法被 Python 取到，也就是垃圾）。我們現(xiàn)在可以去釋放這些對(duì)象。

Finalizer的問題

我們的宏偉計(jì)劃還有一個(gè)問題，就是使用 finalizer 的問題。Finalizer 就是在 Python 中實(shí)例的__del__方法。使用引用計(jì)數(shù)時(shí)，F(xiàn)inalizer 工作地不錯(cuò)。當(dāng)一個(gè)對(duì)象的引用計(jì)數(shù)降到 0 的時(shí)候，F(xiàn)inalizer 就在對(duì)象被釋放前調(diào)用了。對(duì)程序員來說這是直接明了且容易理解的。

垃圾回收的時(shí)候，調(diào)用 finalizer 就成了一個(gè)麻煩的問題，尤其是面對(duì)循環(huán)引用的問題時(shí)。如果在循環(huán)引用中的兩個(gè)對(duì)象都有 finalizer，該怎么做？先調(diào)用哪個(gè)？在調(diào)用第一個(gè) finalizer 之后，這個(gè)對(duì)象無法被釋放因?yàn)榈诙€(gè) finalizer 還能取到它。

因?yàn)檫@個(gè)問題沒有好的解決辦法，被有 finalizer 的對(duì)象引用的循環(huán)是無法釋放的。相反的，這些對(duì)象被加進(jìn)一個(gè)全局的無法回收垃圾列表中。程序應(yīng)該總是可以重新編寫來避免這個(gè)問題。作為最后的手段，程序可以讀取這個(gè)全局列表并以一種對(duì)于當(dāng)前應(yīng)用有意義的方式釋放這些引用循環(huán)。

代價(jià)是什么？

就像有些人說的，天底下沒有免費(fèi)的午餐。然而，這種垃圾回收形式是相當(dāng)廉價(jià)的。最大的代價(jià)之一是每各容器對(duì)象額外需要的三個(gè)字的內(nèi)存空間。還有維護(hù)容器集合的開銷。對(duì)當(dāng)前版本的垃圾收集器來說，基于 pybench 這個(gè)開銷大概是速度下降百分之四。

垃圾回收器目前記錄對(duì)象的三代信息。通過調(diào)整參數(shù)，垃圾回收花費(fèi)的時(shí)間可以想多小就多小。對(duì)一些應(yīng)用來說，關(guān)掉自動(dòng)垃圾回收并在運(yùn)行時(shí)顯式調(diào)用也許是有意義的。然而，以默認(rèn)的垃圾回收參數(shù)運(yùn)行 pybench，垃圾回收花費(fèi)的時(shí)間看起來并不大。顯而易見，大量分配容器對(duì)象的應(yīng)用會(huì)引起更多的垃圾回收時(shí)間。

目前的補(bǔ)丁增加了一個(gè)新的配置項(xiàng)來激活垃圾回收器。有垃圾回收器的 Python 與標(biāo)準(zhǔn) Python 是二進(jìn)制兼容的。如果這個(gè)選項(xiàng)是關(guān)閉的，對(duì) Python 解釋器的工作就沒有影響。

我該怎么使用它？

只要下載目前版本的 Python 就可以了。垃圾回收器已經(jīng)包括在了 2.0 以后的版本中，并且默認(rèn)是默認(rèn)開啟的。如果你在用 Python 1.5.2 版，這里有一個(gè)也許能工作的老版本的補(bǔ)丁。如果你用的是 Windows 平臺(tái)，你可以下載一個(gè)用來替代的 python15.dll。

Boehm-Demers 保守垃圾回收

這個(gè)補(bǔ)丁增加了一些修改到 Python 1.5.2，以使用 Boehm-Demers 保守垃圾回收。但是你必須先打上這個(gè)補(bǔ)丁。依然是采用了引用計(jì)數(shù)。垃圾回收器只釋放引用計(jì)數(shù)沒有釋放的內(nèi)存（即循環(huán)引用）。這樣應(yīng)該性能最好。你需要：

$ cd Python-1.5.2
$ patch -p1 < ../gc-malloc-cleanup.diff
$ patch -p1 < ../gc-boehm.diff
$ autoconf
$ ./configure --with-gc

這個(gè)補(bǔ)丁假設(shè)你安裝了 libgc.a，使得 -lgc 鏈接選項(xiàng)可用（/usr/local/lib 也應(yīng)該可以）。如果你沒有這個(gè)庫(kù)，在編譯以前下載安裝。

目前，這個(gè)補(bǔ)丁只在 Linux 上測(cè)試過。在其 他Unix 機(jī)器上也許也會(huì)工作。在我的 Linux 機(jī)器上，GC 版本的 Python 通過了所有的回歸測(cè)試。

總結(jié)

以上就是本文關(guān)于Python內(nèi)存管理方式和垃圾回收算法解析的全部?jī)?nèi)容，希望對(duì)大家有所幫助。感興趣的朋友可以繼續(xù)參閱本站：Python算法輸出1-9數(shù)組形成的結(jié)果為100的所有運(yùn)算式、Python數(shù)據(jù)結(jié)構(gòu)與算法之列表（鏈表，linked list）簡(jiǎn)單實(shí)現(xiàn)、Python算法之求n個(gè)節(jié)點(diǎn)不同二叉樹個(gè)數(shù)等，有什么問題可以隨時(shí)留言，小編會(huì)及時(shí)回復(fù)大家的。感謝朋友們對(duì)本站的支持！

最新評(píng)論