由於面試中遇到了垃圾回收的問題，轉載學習和總結這個問題。
在C/C++中采用用戶自己管理維護內存的方式。自己管理內存極其自由，可以任意申請內存，但也為大量內存泄露、懸空指針等bug埋下隱患。
因此在現在的高級語言（java、C#等）都采用了垃圾收集機制。
python也采用了垃圾收集機制，采用引用計算機制為主，標記——清除和分代收集兩種機制為輔的策略。
一、引用計數機制
python里每一個東西都是對象，它們的核心就是一個結構體：PyObject。
typedef struct_object { int ob_refcnt; struct_typeobject *ob_type; } PyObject;
PyObject是每個對象必有的內容，其中ob_refcnt就是做為引用計數。當一個對象有新的引用時，它的ob_refcnt就會增加，當引用它的對象被刪除，它的ob_refcnt就會減少。
#define Py_INCREF(op) ((op)->ob_refcnt++) //增加計數 #define Py_DECREF(op) \ //減少計數 if (--(op)->ob_refcnt != 0) \ ; \ else \ __Py_Dealloc((PyObject *)(op))
引用計數為0時，該對象聲明就結束了。
1、引用計數機制優點
- 簡單
- 實時性：一旦沒有引用，內存就直接釋放了。 不用像其他機制等到特定時機。實時性還帶來一個好處：處理回收內存的時間分攤到了平時
2、引用計數機制缺點
- 維護引用計數消耗資源
- 循環引用
list1 = [] list2 = [] list1.append(list2) list2.append(list1)
list1與list2相互引用，如果不存在其他對象對它們的引用，list1與list2的引用計數也仍然為1，所占用的內存永遠無法被回收，這將是致命的。
對於如今的強大硬件，缺點1尚可接受，但是循環引用導致內存泄露，注定python還將引入新的回收機制（標記清除和分代收集）。
轉載地址:http://my.oschina.net/hebianxizao/blog/57367?fromerr=KJozamtm
二、Garbage collection(GC)
英文原文： visualizing garbage collection in ruby and python
GC系統所承擔的工作遠比“垃圾回收”多得多。它們負責三個重要任務：
- 為新生成的對象分配內存
- 識別那些垃圾對象
- 從垃圾對象回收內存
如果將應用程序比作人的身體：所有你所寫的那些優雅的代碼，業務邏輯，算法，應該就是大腦。垃圾回收就是應用程序那顆躍動的心。像心臟為身體其他器官提供血液和營養物那樣，垃圾回收器為你的應該程序提供內存和對象。如果垃圾回收器停止工作或運行遲緩,像動脈阻塞,你的應用程序效率也會下降，直至最終死掉。
1、簡單代碼示例
運用實例來幫助理論理解，下面是一個簡單類，分別用python和ruby寫成：
2、Ruby——可用列表
在ruby中執行上面的Node.new(1)時，Ruby到底做了什么？Ruby是如何為我們創建新的對象的呢？
出乎意料的是它做的非常少。實際上，早在代碼開始執行前，Ruby就提前創建了成百上千個對象，並把它們串在鏈表上，名曰：可用列表。下圖所示為可用列表的概念圖：
想象一下每個白色方格都標着一個“未使用預創建對象”。當調用Node.new時，Ruby只需要取一個預創建對象給我們使用即可：
上圖中左側灰格表示我們代碼中使用的當前對象，同時其他白格是未使用對象。(請注意：無疑我的示意圖是對實際的簡化。實際上，Ruby會用另一個對象來裝載字符串"ABC",另一個對象裝載Node類定義，還有一個對象裝載了代碼中分析出的抽象語法樹，等等)
這個簡單的用鏈表來預分配對象的算法已經發明了超過50年，發明者是計算機科學家John McCarthy，一開始是用Lisp語言實現。
Lisp不僅是最早的函數式編程語言，在計算機科學領域也有許多創舉。其一就是利用垃圾回收機制自動化進行程序內存管理的概念。
標准版的Ruby，也就是眾所周知的"Matz's Ruby Interpreter"(MRI),所使用的GC算法與McCarthy在1960年的實現方式很類似。
Ruby的垃圾回收機制像Lisp一樣，預先創建一些對象，然后在你分配新對象或者變量的時候供你使用。
3、Python——對象分配
由於許多原因Python也使用可用列表(用來回收一些特定對象比如 list)，但在為新對象和變量分配內存的方面Python和Ruby是不同的。
例如我們用Pyhon來創建一個Node對象：
當創建對象時Python立即向操作系統請求內存。(Python實際上實現了一套自己的內存分配系統，在操作系統堆之上提供了一個抽象層。)
當創建第二個對象的時候，再次向OS請求內存：
可以看到，在創建對象的時候，Python會花些時間為我們找到並分配內存。
4、Ruby和Python垃圾回收對比
（1）Ruby開發者像住在凌亂的房間里
Ruby把無用的對象留在內存里，直到下一次GC執行。隨着我們創建越來越多的對象，Ruby會持續尋可用列表里取預創建對象給我們。因此，可用列表會逐漸變短:
甚至變得更短：
一直在為變量n1賦新值，Ruby把舊值留在原處。"ABC","JKL"和"MNO"三個Node實例還滯留在內存中。Ruby不會立即清除代碼中不再使用的舊對象！
Ruby開發者們就像是住在一間凌亂的房間，地板上摞着衣服，要么洗碗池里都是臟盤子。作為一個Ruby程序員，無用的垃圾對象會一直環繞着你。
（2）Python開發者像住在衛生之家
用完的垃圾對象會立即被python打掃干凈。
Python與Ruby的垃圾回收機制頗為不同。讓我們回到前面提到的三個Python Node對象：
在內部，創建一個對象時，Python總是在對象的C結構體里保存一個整數，稱為 引用數。期初，Python將這個值設置為1：
值為1說明分別有個一個指針指向或是引用這三個對象。假如我們現在創建一個新的Node實例，JKL：
與之前一樣，Python設置JKL的引用數為1。然而，請注意由於我們改變了n1指向了JKL，不再指向ABC，Python就把ABC的引用數置為0了。
此刻，Python垃圾回收器立刻挺身而出！每當對象的引用數減為0，Python立即將其釋放，把內存還給操作系統：
上面Python回收了ABC Node實例使用的內存。而Ruby棄舊對象原地於不顧，也不釋放它們的內存。
Python的這種垃圾回收算法被稱為引用計數。是George-Collins在1960年發明的，恰巧與John McCarthy發明的可用列表算法在同一年出現。就像Mike-Bernstein在6月份哥譚市Ruby大會傑出的垃圾回收機制演講中說的: "1960年是垃圾收集器的黃金年代..."
再讓n2引用n1:
上圖中左邊的DEF的引用數已經被Python減少了，垃圾回收器會立即回收DEF實例。同時JKL的引用數已經變為了2 ，因為n1和n2都指向它。
三、標記——清除算法
此刻所有Ruby預創建對象都被程序用過了（都變灰了），可用列表中空空如也（沒有白格子）。
Ruby祭出另一McCarthy發明的算法，名曰：標記-清除。首先Ruby把程序停下來，Ruby用"地球停轉垃圾回收大法"。之后Ruby輪詢所有指針，變量和代碼產生別的引用對象和其他值。同時Ruby通過自身的虛擬機便利內部指針。標記出這些指針引用的每個對象，在圖中使用M表示。
上圖中那三個被標M的對象是程序還在使用的。在內部，Ruby實際上使用一串位值，被稱為:可用位圖(譯注：還記得《編程珠璣》里的為突發排序嗎，這對離散度不高的有限整數集合具有很強的壓縮效果，用以節約機器的資源。)，來跟蹤對象是否被標記了。
Ruby將這個可用位圖存放在獨立的內存區域中，以便充分利用Unix的寫時拷貝化。有關此事的更多內容請關注我另一博文《Why You Should Be Excited About Garbage Collection in Ruby 2.0》。
如果說被標記的對象是存活的，剩下的未被標記的對象只能是垃圾。下圖中用白格子來標識垃圾對象：
Ruby來清除這些無用的垃圾對象，把它們送回到可用列表中：
Ruby實際上不會吧對象從這拷貝到那。而是通過調整內部指針，將其指向一個新鏈表的方式，來將垃圾對象歸位到可用列表中的。
現在等到下回再創建對象的時候Ruby又可以把這些垃圾對象分給我們使用了。在Ruby里，對象們六道輪回，轉世投胎，享受多次人生。
四、標記—刪除 vs 引用計數
咋一看，python的GC算法似乎遠勝於Ruby：寧舍潔宇而居穢室乎？為什么Ruby寧願定期強制程序停止運行，也不使用Python的算法呢？
引用計數並不像第一眼看上去那樣簡單。有許多原因使得不許多語言不像Python這樣使用引用計數GC算法：
1、引用計數GC算法不好實現。
Python不得不在每個對象內部留一些空間來處理引用數。這樣付出了一小點兒空間上的代價。但更糟糕的是，每個簡單的操作（像修改變量或引用）都會變成一個更復雜的操作，因為Python需要增加一個計數，減少另一個，還可能釋放對象。
2、引用計數GC算法相對較慢。
雖然Python隨着程序執行GC很穩健（一把臟碟子放在洗碗盆里就開始洗啦），但這並不一定更快。Python不停地更新着眾多引用數值。特別是當你不再使用一個大數據結構的時候，比如一個包含很多元素的列表，Python可能必須一次性釋放大量對象。減少引用數就成了一項復雜的遞歸過程了。
3、引用計數GC算法並不總是奏效。
引用計數不能處理環形數據結構--也就是含有循環引用的數據結構。
五、Python的代式垃圾回收
英文原文地址: Generational GC in Python and Ruby
中文原文: 對比Ruby和Python的垃圾回收（2）：代式垃圾回收機制
1、python 引用計數算法
標准Ruby(也被稱為Matz的Ruby解釋器或是MRI)使用名為標記回收(Mark and Sweep)的垃圾回收算法，這個算法是為1960年原版本的Lisp所開發。
Python使用一種有53年歷史的GC算法，這種算法的思路非常不同，稱之為引用計數。
Python在引用計數之外，還用了另一個名為 Generational Garbage Collection 的算法。這意味着Python的垃圾回收器用不同的方式對待新創建的以及舊有的對象。
在Python中，每個對象都保存了一個稱為引用計數的整數值，來追蹤到底有多少引用指向了這個對象。
無論何時，如果我們程序中的一個變量或其他對象引用了目標對象，Python將會增加這個計數值，而當程序停止使用這個對象，則Python會減少這個計數值。一旦計數值被減到零，Python將會釋放這個對象以及回收相關內存空間。
2、引用計數存在的問題（循環數據結構）
從二十世紀六十年代起，計算機科學界就面臨一個嚴重的理論問題：針對引用計數算法來說，如果一個數據結構引用了它自身，則這個數據結構是一個循環數據結構，那么某些引用計數值是肯定無法變成零的。如下例所示：
上面代碼中的構造器（Python中叫init），在一個實例變量中存儲一個單獨的屬性。在類定義之后創建兩個節點，ABC和DEF，在圖中為左邊的矩形框。
兩個節點的引用計數都被初始化為1，因為各有兩個引用指向各個節點（n1和n2）。再在節點中定義兩個附加的屬性：next和prev。
Python中可以在代碼運行的時候動態定義實例變量或對象屬性。設置 n1.next 指向 n2，同時設置 n2.prev 指回 n1。現在，我們的兩個節點使用循環引用的方式構成了一個雙端鏈表。同時請注意到 ABC 以及 DEF 的引用計數值已經增加到了2。這里有兩個指針指向了每個節點：首先是 n1 以及 n2，其次就是 next 以及 prev。
然后假定程序不再使用這兩個節點，將n1和n2都設置為None。
此時，python如同往常一樣將每個節點的引用計數減少到1。
一個“孤島”或是一組未使用的、互相指向的對象，但是誰都沒有外部引用。換句話說，我們的程序不再使用這些節點對象了，所以我們希望Python的垃圾回收機制能夠足夠智能去釋放這些對象並回收它們占用的內存空間。但是這不可能，因為所有的引用計數都是1而不是0。Python的引用計數算法不能夠處理互相指向自己的對象。
3、python中的零代（Generation Zero）
代碼也許會在不經意間包含循環引用而且程序員往往未意識到。
事實上，Python程序運行的時候它將會建立一定數量的“浮點數垃圾”，Python的GC不能夠處理未使用的對象因為應用計數值不會到零。
因此python要引入 Generation GC 算法。如Ruby使用一個鏈表(free list)來持續追蹤未使用的、自由的對象一樣，Python使用一種不同的鏈表來持續追蹤活躍的對象。而不將其稱之為“活躍列表”，Python的內部C代碼將其稱為零代(Generation Zero)。每次當你創建一個對象或其他什么值的時候，Python會將其加入零代鏈表。
從上邊可以看到當我們創建ABC節點的時候，Python將其加入零代鏈表。請注意到這並不是一個真正的列表，並不能直接在你的代碼中訪問，事實上這個鏈表是一個完全內部的Python運行時。
相似的，當我們創建DEF節點的時候，Python將其加入同樣的鏈表：
此時，零代包含了兩個節點對象。(他還將包含Python創建的每個其他值，與一些Python自己使用的內部值。)
4、檢測循環引用
隨后，Python會循環遍歷零代列表上的每個對象，檢查列表中每個互相引用的對象，根據規則減掉其引用計數。在這個過程中，Python會一個接一個的統計內部引用的數量以防過早地釋放對象。
（1）循環檢測示例
從上面可以看到 ABC 和 DEF 節點包含的引用數為1。有三個其他的對象同時存在於零代鏈表中，藍色的箭頭指示了有一些對象正在被零代鏈表之外的其他對象所引用。(接下來我們會看到，Python中同時存在另外兩個分別被稱為一代和二代的鏈表)。這些對象有着更高的引用計數因為它們正在被其他指針所指向着。
（2）python的GC處理零代鏈表
通過識別內部引用，Python能夠減少許多零代鏈表對象的引用計數。在上圖的第一行中你能夠看見ABC和DEF的引用計數已經變為零了，這意味着收集器可以釋放它們並回收內存空間了。剩下的活躍的對象則被移動到一個新的鏈表：一代鏈表。
從某種意義上說，Python的GC算法類似於Ruby所用的標記回收算法。周期性地從一個對象到另一個對象追蹤引用以確定對象是否還是活躍的，正在被程序所使用的，這正類似於Ruby的標記過程。
（3）python中的GC閾值
python中什么時候進行這個標記過程？
隨着程序運行，Python解釋器保持對新創建的對象和因引用計數為零而被釋放掉的對象的追蹤。從理論上說，這兩個值應該保持一致，因為程序新建的每個對象都應該最終被釋放掉。
但在實際情況中，由於循環或程序使用了一些比其他對象存在時間更長的對象，被分配對象的計數值與被釋放對象的計數值之間的差異在逐漸增長。一旦差異累計超過某個閾值，則Python的收集機制就啟動了，並且觸發上邊所說到的零代算法，釋放“浮動的垃圾”，並且將剩下的對象移動到一代列表。
隨着時間的推移，程序所使用的對象逐漸從零代列表移動到一代列表。而Python對於一代列表中對象的處理遵循同樣的方法，一旦被分配計數值與被釋放計數值累計到達一定閾值，Python會將剩下的活躍對象移動到二代列表。
通過這種方法，你的代碼所長期使用的對象，那些你的代碼持續訪問的活躍對象，會從零代鏈表轉移到一代再轉移到二代。通過不同的閾值設置，Python可以在不同的時間間隔處理這些對象。Python處理零代最為頻繁，其次是一代然后才是二代
5、弱代假說(weak generational hypothesis)
代垃圾回收算法的核心行為：垃圾回收器會更頻繁的處理新對象。一個新的對象即是你的程序剛剛創建的，而一個來的對象則是經過了幾個時間周期之后仍然存在的對象。
python會在當一個對象從零代移動到一代，或是從一代移動到二代的過程中提升（promote）這個對象。這么做的緣故是弱代假說。
弱代假說由兩個觀點構成：年輕的對象通常死得也快，而老對象則很可能存活更長時間。
假定現在用Python或Ruby創建一個新對象：
根據假說，我的代碼很可能僅僅會使用ABC很短的時間。這個對象也許僅僅只是一個方法中的中間結果，並且隨着方法的返回這個對象就將變成垃圾了。大部分的新對象都是如此般地很快變成垃圾。
然而，偶爾程序會創建一些很重要的，存活時間比較長的對象-例如web應用中的session變量或是配置項。
通過頻繁的處理零代鏈表中的新對象，Python的垃圾收集器將把時間花在更有意義的地方：它處理那些很快就可能變成垃圾的新對象。同時只在很少的時候，當滿足閾值的條件，收集器才回去處理那些老變量。
六、Ruby的代式垃圾回收
1、Ruby的自由鏈
Ruby 2.1版本將會首次使用基於代的垃圾回收算法！當自由鏈使用完之后，Ruby會標記你的程序仍然在使用的對象。
從這張圖上我們可以看到有三個活躍的對象，因為指針n1、n2、n3仍然指向着它們。剩下的用白色矩形表示的對象即是垃圾。(實際情況會復雜得多，自由鏈可能會包含上千個對象，並且有復雜的引用指向關系，這里的簡圖只是幫助我們了解Ruby的GC機制背后的簡單原理，而不會將我們陷入細節之中)
Ruby會將垃圾對象移動回自由鏈中，這樣的話它們就能在程序申請新對象的時候被循環使用了。
2、Ruby2.1基於代的GC機制
從2.1版本開始，Ruby的GC代碼增加了一些附加步驟：它將留下來的活躍對象晉升(promote)到成熟代(mature generation)中。(在MRI的C源碼中使用了old這個詞而不是mature)，接下來的圖展示了兩個Ruby2.1對象代的概念圖：
在左邊是一個跟自由鏈不相同的場景，我們可以看到垃圾對象是用白色表示的，剩下的是灰色的活躍對象。灰色的對象剛剛被標記。
一旦“標記清除”過程結束，Ruby2.1將剩下的標記對象移動到成熟區：
跟Python中使用三代來划分不同，Ruby2.1只用了兩代，左邊是年輕的新一代對象，而右邊是成熟代的老對象。一旦Ruby2.1標記了對象一次，它就會被認為是成熟的。Ruby會打賭剩下的活躍對象在相當長的一段時間內不會很快變成垃圾對象。
注意：Ruby2.1並不會真的在內存中拷貝對象，這些代表不同代的區域並不是由不同的物理內存區域構成。(有一些別的編程語言的GC實現或是Ruby的其他實現，可能會在對象晉升的時候采取拷貝的操作)。Ruby2.1的內部實現不會將在標記&清除過程中預先標記的對象包含在內。一旦一個對象已經被標記過一次了，那么那將不會被包含在接下來的標記清除過程中。
假定你的Ruby程序接着運行着，創造了更多新的，更年輕的對象。則GC的過程將會在新的一代中出現，如圖：
如同Python那樣，Ruby的垃圾收集器將大部分精力都放在新一代的對象之上。它僅僅會將自上一次GC過程發生后創建的新的、年輕的對象包含在接下來的標記清除過程中。這是因為很多新對象很可能馬上就會變成垃圾(白色標記)。Ruby不會重復標記右邊的成熟對象。因為他們已經在一次GC過程中存活下來了，在相當長的一段時間內不會很快變成垃圾。因為只需要標記新對象，所以Ruby 的GC能夠運行得更快。它完全跳過了成熟對象，減少了代碼等待GC完成的時間。
偶然的Ruby會運行一次“全局回收”，重標記(re-marking)並重清除(re-sweeping)，這次包括所有的成熟對象。Ruby通過監控成熟對象的數目來確定何時運行全局回收。當成熟對象的數目雙倍於上次全局回收的數目時，Ruby會清理所有的標記並且將所有的對象都視為新對象。
3、白障
假定你的代碼創建了一個新的年輕的對象，並且將其作為一個已存在的成熟對象的子嗣加入。舉個例子，這種情況將會發生在，當你往一個已經存在了很長時間的數組中增加了一個新值的時候：
左邊的是新對象，而成熟的對象在右邊。在左邊標記過程已經識別出了5個新的對象目前仍然是活躍的(灰色)。但有兩個對象已經變成垃圾了(白色)。
但是如何處理正中間這個新建對象？這是剛剛那個問題提到的對象，它是垃圾還是活躍對象呢？
它是活躍對象，因為有一個從右邊成熟對象的引用指向它。但是我們前面說過已經被標記的成熟對象是不會被包含在標記清除過程中的(一直到全局回收)。這意味着類似這種的新建對象會被錯誤的認為是垃圾而被釋放，從而造成數據丟失。
Ruby2.1 通過監視成熟對象，觀察你的代碼是否會添加一個從它們到新建對象的引用來克服這個問題。
Ruby2.1 使用了一個名為白障(white barriers)的老式GC技術來監視成熟對象的變化 – 無論任意時刻當你添加了從一個對象指向另一個對象的引用時(無論是新建或是修改一個對象)，白障就會被觸發。白障將會檢測是否源對象是一個成熟對象，如果是的話則將這個成熟對象添加到一個特殊的列表中。隨后，Ruby2.1會將這些滿足條件的成熟對象包括到下一次標記清除的范圍內，以防止新建對象被錯誤的標記為垃圾而清除。
Ruby2.1 的白障實現相當復雜，主要是因為已有的C擴展並未包含這部分功能。Koichi Sasada以及Ruby的核心團隊使用了一個比較巧妙的方案來解決這個問題。如果想了解更多的內容，請閱讀這些相關材料：Koichi在EuRuKo 2013上的演講Koichi’s fascinating presentation。
七、總結
乍眼一看，Ruby和Python的GC實現是截然不同的，Ruby使用John-MaCarthy的原生“標記並清除”算法，而Python使用引用計數。但是仔細看來，可以發現Python使用了些許標記清除的思想來處理循環引用，而兩者同時以相似的方式使用基於代的垃圾回收算法。Python划分了三代，而Ruby只有兩代。
這種相似性應該不會讓人感到意外。兩種編程語言都使用了幾十年前的計算機科學研究成果來進行設計，這些成果早在語言成型之前就已經被做出來了。我比較驚異的是當你掀開不同編程語言的表面而深入底層，你總能夠發現一些相似的基礎理念和算法。現代編程語言應該感激那些六七十年代由麥卡錫等計算機先賢所作出的計算機科學開創性研究。