上週，我根據之前在RuPy上做的一個名為“Visualizing Garbage Collection in Ruby and Python.”的報告寫了這篇文章的上半部分。在上篇中，我解釋了標準Ruby(也被稱為Matz的Ruby直譯器或是MRI)是如何使用名為標記回收(Mark and Sweep)的垃圾回收演算法，這個演算法是為1960年原版本的Lisp所開發。同樣，我也介紹了Python使用一種有53年曆史的GC演算法，這種演算法的思路非常不同，稱之為引用計數。

事實證明，Python在引用計數之外，還用了另一個名為Generational Garbage Collection的演算法。這意味著Python的垃圾回收器用不同的方式對待新建立的以及舊有的物件。並且在即將到來的2.1版本的MRI Ruby中也首次引入了Generational Garbage Collection 的垃圾回收機制(在另兩個Ruby的實現：JRuby和Rubinius中，已經使用這種GC機制很多年了，我將在下週的RubyConf大會上將它是如何在這兩種Ruby實現中工作的)。

當然，這句話“用不同的方式對待新建立的以及舊有的物件”是有點模糊不清，比如如何定義新、舊物件？又比如對於Ruby和Python來說具體是如何採取不同的對待方式？今天，我們就來談談這兩種語言GC機制的執行原理，回答上邊那些疑問。但是在我們開始談論Generational GC之前，我們先要花點時間談論下Python的引用計數演算法的一個嚴重的理論問題。

1. Python中的迴圈資料結構以及引用計數

通過上篇，我們知道在Python中，每個物件都儲存了一個稱為引用計數的整數值，來追蹤到底有多少引用指向了這個物件。無論何時，如果我們程式中的一個變數或其他物件引用了目標物件，Python將會增加這個計數值，而當程式停止使用這個物件，則Python會減少這個計數值。一旦計數值被減到零，Python將會釋放這個物件以及回收相關記憶體空間。

從六十年代開始，電腦科學界就面臨了一個嚴重的理論問題，那就是針對引用計數這種演算法來說，如果一個數據結構引用了它自身，即如果這個資料結構是一個迴圈資料結構，那麼某些引用計數值是肯定無法變成零的。為了更好地理解這個問題，讓我們舉個例子。下面的程式碼展示了一些上週我們所用到的節點類：

我們有一個構造器(在Python中叫做 init )，在一個例項變數中儲存一個單獨的屬性。在類定義之後我們建立兩個節點，ABC以及DEF，在圖中為左邊的矩形框。兩個節點的引用計數都被初始化為1，因為各有兩個引用指向各個節點(n1和n2)。

現在，讓我們在節點中定義兩個附加的屬性，next以及prev：

跟Ruby不同的是，Python中你可以在程式碼執行的時候動態定義例項變數或物件屬性。這看起來似乎有點像Ruby缺失了某些有趣的魔法。(宣告下我不是一個Python程式設計師，所以可能會存在一些命名方面的錯誤)。我們設定 n1.next 指向 n2，同時設定 n2.prev 指回 n1。現在，我們的兩個節點使用迴圈引用的方式構成了一個雙端連結串列。同時請注意到 ABC 以及 DEF 的引用計數值已經增加到了2。這裡有兩個指標指向了每個節點：首先是 n1 以及 n2，其次就是 next 以及 prev。

現在，假定我們的程式不再使用這兩個節點了，我們將 n1 和 n2 都設定為null(Python中是None)。

好了，Python會像往常一樣將每個節點的引用計數減少到1。

2. 在Python中的零代(Generation Zero)

請注意在以上剛剛說到的例子中，我們以一個不是很常見的情況結尾：我們有一個“孤島”或是一組未使用的、互相指向的物件，但是誰都沒有外部引用。換句話說，我們的程式不再使用這些節點物件了，所以我們希望Python的垃圾回收機制能夠足夠智慧去釋放這些物件並回收它們佔用的記憶體空間。但是這不可能，因為所有的引用計數都是1而不是0。Python的引用計數演算法不能夠處理互相指向自己的物件。

當然，上邊舉的是一個故意設計的例子，但是你的程式碼也許會在不經意間包含迴圈引用並且你並未意識到。事實上，當你的Python程式執行的時候它將會建立一定數量的“浮點數垃圾”，Python的GC不能夠處理未使用的物件因為應用計數值不會到零。

這就是為什麼Python要引入Generational GC演算法的原因！正如Ruby使用一個連結串列(free list)來持續追蹤未使用的、自由的物件一樣，Python使用一種不同的連結串列來持續追蹤活躍的物件。而不將其稱之為“活躍列表”，Python的內部C程式碼將其稱為零代(Generation Zero)。每次當你建立一個物件或其他什麼值的時候，Python會將其加入零代連結串列：

從上邊可以看到當我們建立ABC節點的時候，Python將其加入零代連結串列。請注意到這並不是一個真正的列表，並不能直接在你的程式碼中訪問，事實上這個連結串列是一個完全內部的Python執行時。

相似的，當我們建立DEF節點的時候，Python將其加入同樣的連結串列：

現在零代包含了兩個節點物件。(他還將包含Python建立的每個其他值，與一些Python自己使用的內部值。)

3. 檢測迴圈引用

隨後，Python會迴圈遍歷零代列表上的每個物件，檢查列表中每個互相引用的物件，根據規則減掉其引用計數。在這個過程中，Python會一個接一個的統計內部引用的數量以防過早地釋放物件。

為了便於理解，來看一個例子：

從上面可以看到 ABC 和 DEF 節點包含的引用數為1.有三個其他的物件同時存在於零代連結串列中，藍色的箭頭指示了有一些物件正在被零代連結串列之外的其他物件所引用。(接下來我們會看到，Python中同時存在另外兩個分別被稱為一代和二代的連結串列)。這些物件有著更高的引用計數因為它們正在被其他指標所指向著。

接下來你會看到Python的GC是如何處理零代連結串列的。

通過識別內部引用，Python能夠減少許多零代連結串列物件的引用計數。在上圖的第一行中你能夠看見ABC和DEF的引用計數已經變為零了，這意味著收集器可以釋放它們並回收記憶體空間了。剩下的活躍的物件則被移動到一個新的連結串列：一代連結串列。

從某種意義上說，Python的GC演算法類似於Ruby所用的標記回收演算法。週期性地從一個物件到另一個物件追蹤引用以確定物件是否還是活躍的，正在被程式所使用的，這正類似於Ruby的標記過程。

4. Python中的GC閾值

Python什麼時候會進行這個標記過程？隨著你的程式執行，Python直譯器保持對新建立的物件，以及因為引用計數為零而被釋放掉的物件的追蹤。從理論上說，這兩個值應該保持一致，因為程式新建的每個物件都應該最終被釋放掉。

當然，事實並非如此。因為迴圈引用的原因，並且因為你的程式使用了一些比其他物件存在時間更長的物件，從而被分配物件的計數值與被釋放物件的計數值之間的差異在逐漸增長。一旦這個差異累計超過某個閾值，則Python的收集機制就啟動了，並且觸發上邊所說到的零代演算法，釋放“浮動的垃圾”，並且將剩下的物件移動到一代列表。

隨著時間的推移，程式所使用的物件逐漸從零代列表移動到一代列表。而Python對於一代列表中物件的處理遵循同樣的方法，一旦被分配計數值與被釋放計數值累計到達一定閾值，Python會將剩下的活躍物件移動到二代列表。

通過這種方法，你的程式碼所長期使用的物件，那些你的程式碼持續訪問的活躍物件，會從零代連結串列轉移到一代再轉移到二代。通過不同的閾值設定，Python可以在不同的時間間隔處理這些物件。Python處理零代最為頻繁，其次是一代然後才是二代。

5. 弱代假說

來看看代垃圾回收演算法的核心行為：垃圾回收器會更頻繁的處理新物件。一個新的物件即是你的程式剛剛建立的，而一個來的物件則是經過了幾個時間週期之後仍然存在的物件。Python會在當一個物件從零代移動到一代，或是從一代移動到二代的過程中提升(promote)這個物件。

為什麼要這麼做？這種演算法的根源來自於弱代假說(weak generational hypothesis)。這個假說由兩個觀點構成：首先是年親的物件通常死得也快，而老物件則很有可能存活更長的時間。

假定現在我用Python或是Ruby建立一個新物件：

根據假說，我的程式碼很可能僅僅會使用ABC很短的時間。這個物件也許僅僅只是一個方法中的中間結果，並且隨著方法的返回這個物件就將變成垃圾了。大部分的新物件都是如此般地很快變成垃圾。然而，偶爾程式會建立一些很重要的，存活時間比較長的物件-例如web應用中的session變數或是配置項。

通過頻繁的處理零代連結串列中的新物件，Python的垃圾收集器將把時間花在更有意義的地方：它處理那些很快就可能變成垃圾的新物件。同時只在很少的時候，當滿足閾值的條件，收集器才回去處理那些老變數。

6. 回到Ruby的自由鏈

即將到來的Ruby 2.1版本將會首次使用基於代的垃圾回收演算法！(請注意的是，其他的Ruby實現，例如JRuby和Rubinius已經使用這個演算法許多年了)。讓我們回到上篇博文中提到的自由鏈的圖來看看它到底是怎麼工作的。

請回憶當自由鏈使用完之後，Ruby會標記你的程式仍然在使用的物件。

從這張圖上我們可以看到有三個活躍的物件，因為指標n1、n2、n3仍然指向著它們。剩下的用白色矩形表示的物件即是垃圾。(當然，實際情況會複雜得多，自由鏈可能會包含上千個物件，並且有複雜的引用指向關係，這裡的簡圖只是幫助我們瞭解Ruby的GC機制背後的簡單原理，而不會將我們陷入細節之中)

同樣，我們說過Ruby會將垃圾物件移動回自由鏈中，這樣的話它們就能在程式申請新物件的時候被迴圈使用了。

7. 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會清理所有的標記並且將所有的物件都視為新物件。

8. 白障

這個演算法的一個重要挑戰是值得深入解釋的：假定你的程式碼建立了一個新的年輕的物件，並且將其作為一個已存在的成熟物件的子嗣加入。舉個例子，這種情況將會發生在，當你往一個已經存在了很長時間的陣列中增加了一個新值的時候：

讓我們來看看圖，左邊的是新物件，而成熟的物件在右邊。在左邊標記過程已經識別出了5個新的物件目前仍然是活躍的(灰色)。但有兩個物件已經變成垃圾了(白色)。但是如何處理正中間這個新建物件？這是剛剛那個問題提到的物件，它是垃圾還是活躍物件呢？

當然它是活躍物件了，因為有一個從右邊成熟物件的引用指向它。但是我們前面說過已經被標記的成熟物件是不會被包含在標記清除過程中的(一直到全域性回收)。這意味著類似這種的新建物件會被錯誤的認為是垃圾而被釋放，從而造成資料丟失。

Ruby2.1 通過監視成熟物件，觀察你的程式碼是否會新增一個從它們到新建物件的引用來克服這個問題。Ruby2.1 使用了一個名為白障(white barriers)的老式GC技術來監視成熟物件的變化 – 無論任意時刻當你添加了從一個物件指向另一個物件的引用時(無論是新建或是修改一個物件)，白障就會被觸發。白障將會檢測是否源物件是一個成熟物件，如果是的話則將這個成熟物件新增到一個特殊的列表中。隨後，Ruby2.1會將這些滿足條件的成熟物件包括到下一次標記清除的範圍內，以防止新建物件被錯誤的標記為垃圾而清除。

Ruby2.1 的白障實現相當複雜，主要是因為已有的C擴充套件並未包含這部分功能。Koichi Sasada以及Ruby的核心團隊使用了一個比較巧妙的方案來解決這個問題。如果想了解更多的內容，請閱讀這些相關材料：Koichi在EuRuKo 2013上的演講Koichi’s fascinating presentation。

9. 站在巨人的肩膀上

乍眼一看，Ruby和Python的GC實現是截然不同的，Ruby使用John MaCarthy的原生“標記並清除”演算法，而Python使用引用計數。但是仔細看來，可以發現Python使用了些許標記清除的思想來處理迴圈引用，而兩者同時以相似的方式使用基於代的垃圾回收演算法。Python劃分了三代，而Ruby只有兩代。

這種相似性應該不會讓人感到意外。兩種程式語言都使用了幾十年前的電腦科學研究成果來進行設計，這些成果早在語言成型之前就已經被做出來了。我比較驚異的是當你掀開不同程式語言的表面而深入底層，你總能夠發現一些相似的基礎理念和演算法。現代程式語言應該感激那些六七十年代由麥卡錫等計算機先賢所作出的電腦科學開創性研究。