垃圾收集趣史

李先靜發表於2020-04-06

垃圾收集趣史

本文發表於2004年2月《CSDN開發高手》

寫作本文的初衷是想和大家分享垃圾收集( Garbage Collection )技術簡單而有趣的發展史。動筆之前,我站在窗邊,望了望正在小區裡裝運垃圾的清潔車。和生活中環衛工人們清運垃圾的工作相似,軟體開發裡的垃圾收集其實就是一種自動打掃和清除記憶體垃圾的技術,它可以有效防範動態記憶體分配中可能發生的兩個危險:因記憶體垃圾過多而引發的記憶體耗盡(這和生活垃圾堵塞排汙管道的 危險並沒有什麼本質的不同),以及不恰當的記憶體釋放所造成的記憶體非法引用(這類似於我們在生活中買到了一瓶已經過期三年的牛奶)。

據歷史學家們介紹,四千多年前的古埃及人已經在城市裡建設了完善的排汙和垃圾清運設施,一千多年前的中國人更是修築了當時世界上保潔能力最強的都市 ——長安。今天,當我們在軟體開發中體驗自動垃圾收集的便捷與舒適時,我們至少應當知道,這種拒絕雜亂、追求整潔的“垃圾收集”精神其實是人類自古以來就已經具備了的。

拓荒時代

國內的程式設計師大多是在 Java 語言中第一次感受到垃圾收集技術的巨大魅力的,許多人也因此把 Java 和垃圾收集看成了密不可分的整體。但事實上,垃圾收集技術早在 Java 語言問世前 30 多年就已經發展和成熟起來了, Java 語言所做的不過是把這項神奇的技術帶到了廣大程式設計師身邊而已。

如果一定要為垃圾收集技術找一個孿生兄弟,那麼, Lisp 語言才是當之無愧的人選。 1960 年前後誕生於 MIT 的 Lisp 語言是第一種高度依賴於動態記憶體分配技術的語言: Lisp 中幾乎所有資料都以“表”的形式出現,而“表”所佔用的空間則是在堆中動態分配得到的。 Lisp 語言先天就具有的動態記憶體管理特性要求 Lisp 語言的設計者必須解決堆中每一個記憶體塊的自動釋放問題(否則, Lisp 程式設計師就必然被程式中不計其數的 free 或 delete 語句淹沒),這直接導致了垃圾收集技術的誕生和發展——說句題外話,上大學時,一位老師曾告訴我們, Lisp 是對現代軟體開發技術貢獻最大的語言。我當時對這一說法不以為然:佈滿了圓括號,看上去像迷宮一樣的 Lisp 語言怎麼能比 C 語言或 Pascal 語言更偉大呢?不過現在,當我知道垃圾收集技術、資料結構技術、人工智慧技術、並行處理技術、虛擬機器技術、後設資料技術以及程式設計師們耳熟能詳的許多技術都起源於 Lisp 語言時,我特別想向那位老師當面道歉,並收回我當時的幼稚想法。

知道了 Lisp 語言與垃圾收集的密切關係,我們就不難理解,為什麼垃圾收集技術的兩位先驅者 J. McCarthy 和 M. L. Minsky 同時也是 Lisp 語言發展史上的重要人物了。 J. McCarthy 是 Lisp 之父,他在發明 Lisp 語言的同時也第一次完整地描述了垃圾收集的演算法和實現方式; M. L. Minsky 則在發展 Lisp 語言的過程中成為了今天好幾種主流垃圾收集演算法的奠基人——和當時不少技術大師的經歷相似, J. McCarthy 和 M. L. Minsky 在許多不同的技術領域裡都取得了令人豔羨的成就。也許,在 1960 年代那個軟體開發史上的拓荒時代裡,思維敏捷、意志堅定的研究者更容易成為無所不能的西部硬漢吧。

在瞭解垃圾收集演算法的起源之前,有必要先回顧一下記憶體分配的主要方式。我們知道,大多數主流的語言或執行環境都支援三種最基本的記憶體分配方式,它們分別是:

一、靜態分配( Static Allocation ):靜態變數和全域性變數的分配形式。我們可以把靜態分配的記憶體看成是家裡的耐用傢俱。通常,它們無需釋放和回收,因為沒人會天天把大衣櫃當作垃圾扔到窗外。

二、自動分配( Automatic Allocation ):在棧中為區域性變數分配記憶體的方法。棧中的記憶體可以隨著程式碼塊退出時的出棧操作被自動釋放。這類似於到家中串門的訪客,天色一晚就要各回各家,除了個別不識時務者以外,我們一般沒必要把客人捆在垃圾袋裡掃地出門。

三、動態分配( Dynamic Allocation ):在堆中動態分配記憶體空間以儲存資料的方式。堆中的記憶體塊好像我們日常使用的餐巾紙,用過了就得扔到垃圾箱裡,否則屋內就會滿地狼藉。像我這樣的懶人做夢都想有一臺家用機器人跟在身邊打掃衛生。在軟體開發中,如果你懶得釋放記憶體,那麼你也需要一臺類似的機器人——這其實就是一個由特定演算法實現的垃圾收集 器。

也就是說,下面提到的所有垃圾收集演算法都是在程式執行過程中收集並清理廢舊“餐巾紙”的演算法,它們的操作物件既不是靜態變數,也不是區域性變數,而是堆中所有已分配記憶體塊。

引用計數( Reference Counting )演算法

1960 年以前,人們為胚胎中的 Lisp 語言設計垃圾收集機制時,第一個想到的演算法是引用計數演算法。拿餐巾紙的例子來說,這種演算法的原理大致可以描述為:

午餐時,為了把腦子裡突然跳出來的設計靈感記下來,我從餐巾紙袋中抽出一張餐巾紙,打算在上面畫出系統架構的藍圖。按照“餐巾紙使用規約之引用計數版”的要求,畫圖之前,我必須先在餐巾紙的一角寫上計數值 1 ,以表示我在使用這張餐巾紙。這時,如果你也想看看我畫的藍圖,那你就要把餐巾紙上的計數值加 1 ,將它改為 2 ,這表明目前有 2 個人在同時使用這張餐巾紙(當然,我是不會允許你用這張餐巾紙來擦鼻涕的)。你看完後,必須把計數值減 1 ,表明你對該餐巾紙的使用已經結束。同樣,當我將餐巾紙上的內容全部謄寫到筆記本上之後,我也會自覺地把餐巾紙上的計數值減 1 。此時,不出意外的話,這張餐巾紙上的計數值應當是 0 ,它會被垃圾收集器——假設那是一個專門負責打掃衛生的機器人——撿起來扔到垃圾箱裡,因為垃圾收集器的惟一使命就是找到所有計數值為 0 的餐巾紙並清理它們。

引用計數演算法的優點和缺陷同樣明顯。這一演算法在執行垃圾收集任務時速度較快,但演算法對程式中每一次記憶體分配和指標操作提出了額外的要求(增加或減少 記憶體塊的引用計數)。更重要的是,引用計數演算法無法正確釋放迴圈引用的記憶體塊,對此, D. Hillis 有一段風趣而精闢的論述:

一天,一個學生走到 Moon 面前說:“我知道如何設計一個更好的垃圾收集器了。我們必須記錄指向每個結點的指標數目。” Moon 耐心地給這位學生講了下面這個故事:“一天,一個學生走到 Moon 面前說:‘我知道如何設計一個更好的垃圾收集器了……’”

D. Hillis 的故事和我們小時候常說的“從前有座山,山上有個廟,廟裡有個老和尚”的故事有異曲同工之妙。這說明,單是使用引用計數演算法還不足以解決垃圾收集中的所有問題。正因為如此,引用計數演算法也常常被研究者們排除在狹義的垃圾收集演算法之外。當然,作為一種最簡單、最直觀的解決方案,引用計數演算法本身具有其不可替 代的優越性。 1980 年代前後, D. P. Friedman , D. S. Wise , H. G. Baker 等人對引用計數演算法進行了數次改進,這些改進使得引用計數演算法及其變種(如延遲計數演算法等)在簡單的環境下,或是在一些綜合了多種演算法的現代垃圾收集系統中仍然可以一展身手。

標記-清除( Mark-Sweep )演算法

第一種實用和完善的垃圾收集演算法是 J. McCarthy 等人在 1960 年提出併成功地應用於 Lisp 語言的標記-清除演算法。仍以餐巾紙為例,標記-清除演算法的執行過程是這樣的:

午餐過程中,餐廳裡的所有人都根據自己的需要取用餐巾紙。當垃圾收集機器人想收集廢舊餐巾紙的時候,它會讓所有用餐的人先停下來,然後,依次詢問餐 廳裡的每一個人:“你正在用餐巾紙嗎?你用的是哪一張餐巾紙?”機器人根據每個人的回答將人們正在使用的餐巾紙畫上記號。詢問過程結束後,機器人在餐廳裡 尋找所有散落在餐桌上且沒有記號的餐巾紙(這些顯然都是用過的廢舊餐巾紙),把它們統統扔到垃圾箱裡。

正如其名稱所暗示的那樣,標記-清除演算法的執行過程分為“標記”和“清除”兩大階段。這種分步執行的思路奠定了現代垃圾收集演算法的思想基礎。與引用計數演算法不同的是,標記-清除演算法不需要執行環境監測每一次記憶體分配和指標操作,而只要在“標記”階段中跟蹤每一個指標變數的指向——用類似思路實現的垃 圾收集器也常被後人統稱為跟蹤收集器( Tracing Collector )

伴隨著 Lisp 語言的成功,標記-清除演算法也在大多數早期的 Lisp 執行環境中大放異彩。儘管最初版本的標記-清除演算法在今天看來還存在效率不高(標記和清除是兩個相當耗時的過程)等諸多缺陷,但在後面的討論中,我們可以看到,幾乎所有現代垃圾收集演算法都是標記-清除思想的延續,僅此一點, J. McCarthy 等人在垃圾收集技術方面的貢獻就絲毫不亞於他們在 Lisp 語言上的成就了。

複製( Copying )演算法

為了解決標記-清除演算法在垃圾收集效率方面的缺陷, M. L. Minsky 於 1963 年發表了著名的論文“一種使用雙儲存區的 Lisp 語言垃圾收集器( A LISP Garbage Collector Algorithm Using Serial Secondary Storage )”。 M. L. Minsky 在該論文中描述的演算法被人們稱為複製演算法,它也被 M. L. Minsky 本人成功地引入到了 Lisp 語言的一個實現版本中。

複製演算法別出心裁地將堆空間一分為二,並使用簡單的複製操作來完成垃圾收集工作,這個思路相當有趣。借用餐巾紙的比喻,我們可以這樣理解 M. L. Minsky 的複製演算法:

餐廳被垃圾收集機器人分成南區和北區兩個大小完全相同的部分。午餐時,所有人都先在南區用餐(因為空間有限,用餐人數自然也將減少一半),用餐時可 以隨意使用餐巾紙。當垃圾收集機器人認為有必要回收廢舊餐巾紙時,它會要求所有用餐者以最快的速度從南區轉移到北區,同時隨身攜帶自己正在使用的餐巾紙。等所有人都轉移到北區之後,垃圾收集機器人只要簡單地把南區中所有散落的餐巾紙扔進垃圾箱就算完成任務了。下一次垃圾收集的工作過程也大致類似,惟一的不 同只是人們的轉移方向變成了從北區到南區。如此迴圈往復,每次垃圾收集都只需簡單地轉移(也就是複製)一次,垃圾收集速度無與倫比——當然,對於用餐者往 返奔波於南北兩區之間的辛勞,垃圾收集機器人是決不會流露出絲毫憐憫的。

M. L. Minsky 的發明絕對算得上一種奇思妙想。分割槽、複製的思路不僅大幅提高了垃圾收集的效率,而且也將原本繁紛複雜的記憶體分配演算法變得前所未有地簡明和扼要(既然每次記憶體回收都是對整個半區的回收,記憶體分配時也就不用考慮記憶體碎片等複雜情況,只要移動堆頂指標,按順序分配記憶體就可以了),這簡直是個奇蹟!不過,任何奇 跡的出現都有一定的代價,在垃圾收集技術中,複製演算法提高效率的代價是人為地將可用記憶體縮小了一半。實話實說,這個代價未免也太高了一些。

無論優缺點如何,複製演算法在實踐中都獲得了可以與標記-清除演算法相比擬的成功。除了 M. L. Minsky 本人在 Lisp 語言中的工作以外,從 1960 年代末到 1970 年代初, R. R. Fenichel 和 J. C. Yochelson 等人也相繼在 Lisp 語言的不同實現中對複製演算法進行了改進, S. Arnborg 更是成功地將複製演算法應用到了 Simula 語言中。

至此,垃圾收集技術的三大傳統演算法——引用計數演算法、標記-清除演算法和複製演算法——都已在 1960 年前後相繼問世,三種演算法各有所長,也都存在致命的缺陷。從 1960 年代後期開始,研究者的主要精力逐漸轉向對這三種傳統演算法進行改進或整合,以揚長避短,適應程式設計語言和執行環境對垃圾收集的效率和實時性所提出的更高 要求。

走向成熟

1970 年代開始,隨著科學研究和應用實踐的不斷深入,人們逐漸意識到,一個理想的垃圾收集器不應在執行時導致應用程式的暫停,不應額外佔用大量的記憶體空間和 CPU 資源,而三種傳統的垃圾收集演算法都無法滿足這些要求。人們必須提出更新的演算法或思路,以解決實踐中碰到的諸多難題。當時,研究者的努力目標包括:

第一,提高垃圾收集的效率。使用標記-清除演算法的垃圾收集器在工作時要消耗相當多的 CPU 資源。早期的 Lisp 執行環境收集記憶體垃圾的時間竟佔到了系統總執行時間的 40% !——垃圾收集效率的低下直接造就了 Lisp 語言在執行速度方面的壞名聲;直到今天,許多人還條件反射似地誤以為所有 Lisp 程式都奇慢無比。

第二,減少垃圾收集時的記憶體佔用。這一問題主要出現在複製演算法中。儘管複製演算法在效率上獲得了質的突破,但犧牲一半記憶體空間的代價仍然是巨大的。在計算機發展的早期,在記憶體價格以 KB 計算的日子裡,浪費客戶的一半記憶體空間簡直就是在變相敲詐或攔路打劫。

第三,尋找實時的垃圾收集演算法。無論執行效率如何,三種傳統的垃圾收集演算法在執行垃圾收集任務時都必須打斷程式的當前工作。這種因垃圾收集而造成的 延時是許多程式,特別是執行關鍵任務的程式沒有辦法容忍的。如何對傳統演算法進行改進,以便實現一種在後臺悄悄執行,不影響——或至少看上去不影響——當前 程式的實時垃圾收集器,這顯然是一件更具挑戰性的工作。

研究者們探尋未知領域的決心和研究工作的進展速度同樣令人驚奇:在 1970 年代到 1980 年代的短短十幾年中,一大批在實用系統中表現優異的新演算法和新思路脫穎而出。正是因為有了這些日趨成熟的垃圾收集演算法,今天的我們才能在 Java 或 .NET 提供的執行環境中隨心所欲地分配記憶體塊,而不必擔心空間釋放時的風險。

標記-整理( Mark-Compact )演算法

標記-整理演算法是標記-清除演算法和複製演算法的有機結合。把標記-清除演算法在記憶體佔用上的優點和複製演算法在執行效率上的特長綜合起來,這是所有人都希 望看到的結果。不過,兩種垃圾收集演算法的整合並不像 1 加 1 等於 2 那樣簡單,我們必須引入一些全新的思路。 1970 年前後, G. L. Steele , C. J. Cheney 和 D. S. Wise 等研究者陸續找到了正確的方向,標記-整理演算法的輪廓也逐漸清晰了起來:

在我們熟悉的餐廳裡,這一次,垃圾收集機器人不再把餐廳分成兩個南北區域了。需要執行垃圾收集任務時,機器人先執行標記-清除演算法的第一個步驟,為 所有使用中的餐巾紙畫好標記,然後,機器人命令所有就餐者帶上有標記的餐巾紙向餐廳的南面集中,同時把沒有標記的廢舊餐巾紙扔向餐廳北面。這樣一來,機器人只消站在餐廳北面,懷抱垃圾箱,迎接撲面而來的廢舊餐巾紙就行了。

實驗表明,標記-整理演算法的總體執行效率高於標記-清除演算法,又不像複製演算法那樣需要犧牲一半的儲存空間,這顯然是一種非常理想的結果。在許多現代的垃圾收集器中,人們都使用了標記-整理演算法或其改進版本。

增量收集( Incremental Collecting )演算法

對實時垃圾收集演算法的研究直接導致了增量收集演算法的誕生。

最初,人們關於實時垃圾收集的想法是這樣的:為了進行實時的垃圾收集,可以設計一個多程式的執行環境,比如用一個程式執行垃圾收集工作,另一個程式執行程式程式碼。這樣一來,垃圾收集工作看上去就彷彿是在後臺悄悄完成的,不會打斷程式程式碼的執行。

在收集餐巾紙的例子中,這一思路可以被理解為:垃圾收集機器人在人們用餐的同時尋找廢棄的餐巾紙並將它們扔到垃圾箱裡。這個看似簡單的思路會在設計 和實現時碰上程式間衝突的難題。比如說,如果垃圾收集程式包括標記和清除兩個工作階段,那麼,垃圾收集器在第一階段中辛辛苦苦標記出的結果很可能被另一個程式中的記憶體操作程式碼修改得面目全非,以至於第二階段的工作沒有辦法開展。

M. L. Minsky 和 D. E. Knuth 對實時垃圾收集過程中的技術難點進行了早期的研究, G. L. Steele 於 1975 年發表了題為“多程式整理的垃圾收集( Multiprocessing compactifying garbage collection )”的論文,描述了一種被後人稱為“ Minsky-Knuth-Steele 演算法”的實時垃圾收集演算法。 E. W. Dijkstra , L. Lamport , R. R. Fenichel 和 J. C. Yochelson 等人也相繼在此領域做出了各自的貢獻。 1978 年, H. G. Baker 發表了“序列計算機上的實時表處理技術( List Processing in Real Time on a Serial Computer )”一文,系統闡述了多程式環境下用於垃圾收集的增量收集演算法。

增量收集演算法的基礎仍是傳統的標記-清除和複製演算法。增量收集演算法通過對程式間衝突的妥善處理,允許垃圾收集程式以分階段的方式完成標記、清理或復 制工作。詳細分析各種增量收集演算法的內部機理是一件相當繁瑣的事情,在這裡,讀者們需要了解的僅僅是: H. G. Baker 等人的努力已經將實時垃圾收集的夢想變成了現實,我們再也不用為垃圾收集打斷程式的執行而煩惱了。

分代收集( Generational Collecting )演算法

和大多數軟體開發技術一樣,統計學原理總能在技術發展的過程中起到強力催化劑的作用。 1980 年前後,善於在研究中使用統計分析知識的技術人員發現,大多數記憶體塊的生存週期都比較短,垃圾收集器應當把更多的精力放在檢查和清理新分配的記憶體塊上。這個發現對於垃圾收集技術的價值可以用餐巾紙的例子概括如下:

如果垃圾收集機器人足夠聰明,事先摸清了餐廳裡每個人在用餐時使用餐巾紙的習慣——比如有些人喜歡在用餐前後各用掉一張餐巾紙,有的人喜歡自始至終攥著一張餐巾紙不放,有的人則每打一個噴嚏就用去一張餐巾紙——機器人就可以制定出更完善的餐巾紙回收計劃,並總是在人們剛扔掉餐巾紙沒多久就把垃圾撿 走。這種基於統計學原理的做法當然可以讓餐廳的整潔度成倍提高。

D. E. Knuth , T. Knight , G. Sussman 和 R. Stallman 等人對記憶體垃圾的分類處理做了最早的研究。 1983 年, H. Lieberman 和 C. Hewitt 發表了題為“基於物件壽命的一種實時垃圾收集器( A real-time garbage collector based on the lifetimes of objects )”的論文。這篇著名的論文標誌著分代收集演算法的正式誕生。此後,在 H. G. Baker , R. L. Hudson , J. E. B. Moss 等人的共同努力下,分代收集演算法逐漸成為了垃圾收集領域裡的主流技術。

分代收集演算法通常將堆中的記憶體塊按壽命分為兩類,年老的和年輕的。垃圾收集器使用不同的收集演算法或收集策略,分別處理這兩類記憶體塊,並特別地把主要 工作時間花在處理年輕的記憶體塊上。分代收集演算法使垃圾收集器在有限的資源條件下,可以更為有效地工作——這種效率上的提高在今天的 Java 虛擬機器中得到了最好的證明。

應用浪潮

Lisp 是垃圾收集技術的第一個受益者,但顯然不是最後一個。在 Lisp 語言之後,許許多多傳統的、現代的、後現代的語言已經把垃圾收集技術拉入了自己的懷抱。隨便舉幾個例子吧:誕生於 1964 年的 Simula 語言, 1969 年的 Smalltalk 語言, 1970 年的 Prolog 語言, 1973 年的 ML 語言, 1975 年的 Scheme 語言, 1983 年的 Modula-3 語言, 1986 年的 Eiffel 語言, 1987 年的 Haskell 語言……它們都先後使用了自動垃圾收集技術。當然,每一種語言使用的垃圾收集演算法可能不盡相同,大多數語言和執行環境甚至同時使用了多種垃圾收集演算法。但無論怎樣,這些例項都說明,垃圾收集技術從誕生的那一天起就不是一種曲高和寡的“學院派”技術。

對於我們熟悉的 C 和 C++ 語言,垃圾收集技術一樣可以發揮巨大的功效。正如我們在學校中就已經知道的那樣, C 和 C++ 語言本身並沒有提供垃圾收集機制,但這並不妨礙我們在程式中使用具有垃圾收集功能的函式庫或類庫。例如,早在 1988 年, H. J. Boehm 和 A. J. Demers 就成功地實現了一種使用保守垃圾收集演算法( Conservative GC Algorithmic )的函式庫(參見 http://www.hpl.hp.com/personal/Hans_Boehm/gc )。我們可以在 C 語言或 C++ 語言中使用該函式庫完成自動垃圾收集功能,必要時,甚至還可以讓傳統的 C/C++ 程式碼與使用自動垃圾收集功能的 C/C++ 程式碼在一個程式裡協同工作。

1995 年誕生的 Java 語言在一夜之間將垃圾收集技術變成了軟體開發領域裡最為流行的技術之一。從某種角度說,我們很難分清究竟是 Java 從垃圾收集中受益,還是垃圾收集技術本身借 Java 的普及而揚名。值得注意的是,不同版本的 Java 虛擬機器使用的垃圾收集機制並不完全相同, Java 虛擬機器其實也經過了一個從簡單到複雜的發展過程。在 Java 虛擬機器的 1.4.1 版中,人們可以體驗到的垃圾收集演算法就包括分代收集、複製收集、增量收集、標記-整理、並行複製( Parallel Copying )、並行清除( Parallel Scavenging )、併發( Concurrent )收集等許多種, Java 程式執行速度的不斷提升在很大程度上應該歸功於垃圾收集技術的發展與完善。

儘管歷史上已經有許多包含垃圾收集技術的應用平臺和作業系統出現,但 Microsoft .NET 卻是第一種真正實用化的、包含了垃圾收集機制的通用語言執行環境。事實上, .NET 平臺上的所有語言,包括 C# 、 Visual Basic .NET 、 Visual C++ .NET 、 J# 等等,都可以通過幾乎完全相同的方式使用 .NET 平臺提供的垃圾收集機制。我們似乎可以斷言, .NET 是垃圾收集技術在應用領域裡的一次重大變革,它使垃圾收集技術從一種單純的技術變成了應用環境乃至作業系統中的一種內在文化。這種變革對未來軟體開發技術的影響力也許要遠遠超過 .NET 平臺本身的商業價值。

大勢所趨

今天,致力於垃圾收集技術研究的人們仍在不懈努力,他們的研究方向包括分散式系統的垃圾收集、複雜事務環境下的垃圾收集、資料庫等特定系統的垃圾收集等等。

但在程式設計師中間,仍有不少人對垃圾收集技術不屑一顧,他們寧願相信自己逐行編寫的 free 或 delete 命令,也不願把垃圾收集的重任交給那些在他們看來既蠢又笨的垃圾收集器。

我個人認為,垃圾收集技術的普及是大勢所趨,這就像生活會越來越好一樣毋庸置疑。今天的程式設計師也許會因為垃圾收集器要佔用一定的 CPU 資源而對其望而卻步,但二十多年前的程式設計師還曾因為高階語言速度太慢而堅持用機器語言寫程式呢!在硬體速度日新月異的今天,我們是要吝惜那一點兒時間損耗而踟躇不前,還是該堅定不移地站在程式碼和執行環境的淨化劑——垃圾收集的一邊呢?

[王詠剛,2003年12月]

 

相關文章