Python垃圾回收機制

阿新 • • 發佈：2020-08-19

一、理解整數物件池及intern機制

1. 小整數物件池

整數在程式中的使用非常廣泛，Python為了優化速度，使用了小整數物件池，避免為整數頻繁申請和銷燬記憶體空間。

Python 對小整數的定義是 [-5, 257) 這些整數物件是提前建立好的，不會被垃圾回收。在一個 Python 的程式中，所有位於這個範圍內的整數使用的都是同一個物件.

同理，單個字母也是這樣的。

但是當定義2個相同的字串時，引用計數為0，觸發垃圾回收

2. 大整數物件池

每一個大整數，均建立一個新的物件。

3. intern機制

a1 = "HelloWorld"
a2 = "HelloWorld"
a3 = "HelloWorld"
a4 = "HelloWorld"
a5 = "HelloWorld"
a6 = "HelloWorld"
a7 = "HelloWorld"
a8 = "HelloWorld"
a9 = "HelloWorld"

python會不會建立9個物件呢？在記憶體中會不會開闢9個”HelloWorld”的記憶體空間呢？想一下，如果是這樣的話，我們寫10000個物件，比如a1=”HelloWorld”…..a1000=”HelloWorld”，那他豈不是開闢了1000個”HelloWorld”所佔的記憶體空間了呢？如果真這樣，記憶體不就爆了嗎？所以python中有這樣一個機制——intern機制，讓他只佔用一個”HelloWorld”所佔的記憶體空間。靠引用計數去維護何時釋放

。　　

總結：

1.小整數[-5,257)共用物件，常駐記憶體
2.單個字元共用物件，常駐記憶體
3.單個單詞，不可修改，預設開啟intern機制，共用物件，引用計數為0，則銷燬,程式碼示例如下：

4.字串（含有空格），不可修改，沒開啟intern機制，不共用物件，引用計數為0，銷燬程式碼示例如下：

5.大整數不共用記憶體，引用計數為0，銷燬

6.數值型別和字串型別在 Python 中都是不可變的，這意味著你無法修改這個物件的值，每次對變數的修改，實際上是建立一個新的物件

二、Garbage collection(GC垃圾回收)

現在的高階語言如java，c#等，都採用了垃圾收集機制，而不再是c，c++裡使用者自己管理維護記憶體的方式。自己管理記憶體極其自由，可以任意申請記憶體，但如同一把雙刃劍，為大量記憶體洩露，懸空指標等bug埋下隱患。對於一個字串、列表、類甚至數值都是物件，且定位簡單易用的語言，自然不會讓使用者去處理如何分配回收記憶體的問題。 python裡也同java一樣採用了垃圾收集機制，不過不一樣的是: 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時，該物件生命就結束了。

引用計數機制的優點：

簡單
實時性：一旦沒有引用，記憶體就直接釋放了。不用像其他機制等到特定時機。實時性還帶來一個好處：處理回收記憶體的時間分攤到了平時。

引用計數機制的缺點：

維護引用計數消耗資源

迴圈引用

list1 = []
list2 = []
list1.append(list2)
list2.append(list1)

list1與list2相互引用，如果不存在其他物件對它們的引用，list1與list2的引用計數也仍然為1，所佔用的記憶體永遠無法被回收，這將是致命的。對於如今的強大硬體，缺點1尚可接受，但是迴圈引用導致記憶體洩露，註定python還將引入新的回收機制。(標記清除和分代收集)

2. 畫說 Ruby 與 Python 垃圾回收

英文原文:visualizing garbage collection in ruby and python

2.1 應用程式那顆躍動的心

GC系統所承擔的工作遠比"垃圾回收"多得多。實際上，它們負責三個重要任務。它們

為新生成的物件分配記憶體
識別那些垃圾物件，並且
從垃圾物件那回收記憶體。

如果將應用程式比作人的身體：所有你所寫的那些優雅的程式碼，業務邏輯，演算法，應該就是大腦。以此類推，垃圾回收機制應該是那個身體器官呢？（我從RuPy聽眾那聽到了不少有趣的答案：腰子、白血球 :) ）

我認為垃圾回收就是應用程式那顆躍動的心。像心臟為身體其他器官提供血液和營養物那樣，垃圾回收器為你的應該程式提供記憶體和物件。如果心臟停跳，過不了幾秒鐘人就完了。如果垃圾回收器停止工作或執行遲緩,像動脈阻塞,你的應用程式效率也會下降，直至最終死掉。

2.2 一個簡單的例子

運用例項一貫有助於理論的理解。下面是一個簡單類，分別用Python和Ruby寫成，我們今天就以此為例：

順便提一句，兩種語言的程式碼竟能如此相像：Ruby 和 Python 在表達同一事物上真的只是略有不同。但是在這兩種語言的內部實現上是否也如此相似呢？

2.3 Ruby 的物件分配

當我們執行上面的Node.new(1)時，Ruby到底做了什麼？Ruby是如何為我們建立新的物件的呢？出乎意料的是它做的非常少。實際上，早在程式碼開始執行前，Ruby就提前建立了成百上千個物件，並把它們串在連結串列上，名曰：可用列表。下圖所示為可用列表的概念圖：

想象一下每個白色方格上都標著一個"未使用預建立物件"。當我們呼叫 Node.new ,Ruby只需取一個預建立物件給我們使用即可：

上圖中左側灰格表示我們程式碼中使用的當前物件，同時其他白格是未使用物件。(請注意：無疑我的示意圖是對實際的簡化。實際上，Ruby會用另一個物件來裝載字串"ABC",另一個物件裝載Node類定義，還有一個物件裝載了程式碼中分析出的抽象語法樹，等等)

如果我們再次呼叫 Node.new，Ruby將遞給我們另一個物件：

這個簡單的用連結串列來預分配物件的演算法已經發明瞭超過50年，而發明人這是赫赫有名的電腦科學家John McCarthy，一開始是用Lisp實現的。Lisp不僅是最早的函數語言程式設計語言，在電腦科學領域也有許多創舉。其一就是利用垃圾回收機制自動化進行程式記憶體管理的概念。

標準版的Ruby，也就是眾所周知的"Matz's Ruby Interpreter"(MRI),所使用的GC演算法與McCarthy在1960年的實現方式很類似。無論好壞，Ruby的垃圾回收機制已經53歲高齡了。像Lisp一樣，Ruby預先建立一些物件，然後在你分配新物件或者變數的時候供你使用。

2.4 Python 的物件分配

我們已經瞭解了Ruby預先建立物件並將它們存放在可用列表中。那Python又怎麼樣呢？

儘管由於許多原因Python也使用可用列表(用來回收一些特定物件比如 list)，但在為新物件和變數分配記憶體的方面Python和Ruby是不同的。

例如我們用Pyhon來建立一個Node物件：

與Ruby不同，當建立物件時Python立即向作業系統請求記憶體。(Python實際上實現了一套自己的記憶體分配系統，在作業系統堆之上提供了一個抽象層。但是我今天不展開說了。)

當我們建立第二個物件的時候，再次像OS請求記憶體：

看起來夠簡單吧，在我們建立物件的時候，Python會花些時間為我們找到並分配記憶體。

2.5 Ruby 開發者住在凌亂的房間裡

Ruby把無用的物件留在記憶體裡，直到下一次GC執行

回過來看Ruby。隨著我們建立越來越多的物件，Ruby會持續尋可用列表裡取預建立物件給我們。因此，可用列表會逐漸變短:

...然後更短：

請注意我一直在為變數n1賦新值，Ruby把舊值留在原處。"ABC","JKL"和"MNO"三個Node例項還滯留在記憶體中。Ruby不會立即清除程式碼中不再使用的舊物件！Ruby開發者們就像是住在一間凌亂的房間，地板上摞著衣服，要麼洗碗池裡都是髒盤子。作為一個Ruby程式設計師，無用的垃圾物件會一直環繞著你。

2.6 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年是垃圾收集器的黃金年代..."

Python開發者工作在衛生之家,你可以想象，有個患有輕度OCD(一種強迫症)的室友一刻不停地跟在你身後打掃，你一放下髒碟子或杯子，有個傢伙已經準備好把它放進洗碗機了！

現在來看第二例子。加入我們讓n2引用n1：

上圖中左邊的DEF的引用數已經被Python減少了，垃圾回收器會立即回收DEF例項。同時JKL的引用數已經變為了2 ，因為n1和n2都指向它。

2.7 標記-清除

最終那間凌亂的房間充斥著垃圾，再不能歲月靜好了。在Ruby程式運行了一陣子以後，可用列表最終被用光光了:

此刻所有Ruby預建立物件都被程式用過了(它們都變灰了)，可用列表裡空空如也（沒有白格子了）。

此刻Ruby祭出另一McCarthy發明的演算法，名曰：標記-清除。首先Ruby把程式停下來，Ruby用"地球停轉垃圾回收大法"。之後Ruby輪詢所有指標，變數和程式碼產生別的引用物件和其他值。同時Ruby通過自身的虛擬機器便利內部指標。標記出這些指標引用的每個物件。我在圖中使用M表示。

上圖中那三個被標M的物件是程式還在使用的。在內部，Ruby實際上使用一串位值，被稱為:可用點陣圖(譯註：還記得《程式設計珠璣》裡的為突發排序嗎，這對離散度不高的有限整數集合具有很強的壓縮效果，用以節約機器的資源。)，來跟蹤物件是否被標記了。

如果說被標記的物件是存活的，剩下的未被標記的物件只能是垃圾，這意味著我們的程式碼不再會使用它了。我會在下圖中用白格子表示垃圾物件：

接下來Ruby清除這些無用的垃圾物件，把它們送回到可用列表中：

在內部這一切發生得迅雷不及掩耳，因為Ruby實際上不會吧物件從這拷貝到那。而是通過調整內部指標，將其指向一個新連結串列的方式，來將垃圾物件歸位到可用列表中的。

現在等到下回再建立物件的時候Ruby又可以把這些垃圾物件分給我們使用了。在Ruby裡，物件們六道輪迴，轉世投胎，享受多次人生。

2.8 標記-刪除 vs. 引用計數

乍一看，Python的GC演算法貌似遠勝於Ruby的：寧舍潔宇而居穢室乎？為什麼Ruby寧願定期強制程式停止執行，也不使用Python的演算法呢？

然而，引用計數並不像第一眼看上去那樣簡單。有許多原因使得不許多語言不像Python這樣使用引用計數GC演算法：

首先，它不好實現。Python不得不在每個物件內部留一些空間來處理引用數。這樣付出了一小點兒空間上的代價。但更糟糕的是，每個簡單的操作（像修改變數或引用）都會變成一個更復雜的操作，因為Python需要增加一個計數，減少另一個，還可能釋放物件。

第二點，它相對較慢。雖然Python隨著程式執行GC很穩健（一把髒碟子放在洗碗盆裡就開始洗啦），但這並不一定更快。Python不停地更新著眾多引用數值。特別是當你不再使用一個大資料結構的時候，比如一個包含很多元素的列表，Python可能必須一次性釋放大量物件。減少引用數就成了一項複雜的遞迴過程了。

最後，它不是總奏效的。引用計數不能處理環形資料結構--也就是含有迴圈引用的資料結構。

三、 Python中的迴圈資料結構以及引用計數

1 迴圈引用

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

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

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

3.3 檢測迴圈引用

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

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

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

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

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

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

Python中的GC閾值

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

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

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

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

弱代假說

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

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

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

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

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

四、gc模組

1.垃圾回收機制

Python中的垃圾回收是以引用計數為主，分代收集為輔。

1)導致引用計數+1的情況

物件被建立，例如a=23
物件被引用，例如b=a
物件被作為引數，傳入到一個函式中，例如func(a)
物件作為一個元素，儲存在容器中，例如list1=[a,a]

2)導致引用計數-1的情況

物件的別名被顯式銷燬，例如del a
物件的別名被賦予新的物件，例如a=24
一個物件離開它的作用域，例如f函式執行完畢時，func函式中的區域性變數（全域性變數不會）
物件所在的容器被銷燬，或從容器中刪除物件

3)檢視一個物件的引用計數

import sys
a = "hello world"
sys.getrefcount(a)

可以檢視a物件的引用計數，但是比正常計數大1，因為呼叫函式的時候傳入a，這會讓a的引用計數+1

2.迴圈引用導致記憶體洩露

引用計數的缺陷是迴圈引用的問題

import gc

class ClassA():
    def __init__(self):
        print('object born,id:%s'%str(hex(id(self))))

def f2():
    while True:
        c1 = ClassA()
        c2 = ClassA()
        c1.t = c2
        c2.t = c1
        del c1
        del c2

#把python的gc關閉
gc.disable()

f2()

執行f2()，程序佔用的記憶體會不斷增大。　　

建立了c1，c2後這兩塊記憶體的引用計數都是1，執行c1.t=c2和c2.t=c1後，這兩塊記憶體的引用計數變成2.
在del c1後，記憶體1的物件的引用計數變為1，由於不是為0，所以記憶體1的物件不會被銷燬，所以記憶體2的物件的引用數依然是2，在del c2後，同理，記憶體1的物件，記憶體2的物件的引用數都是1。
雖然它們兩個的物件都是可以被銷燬的，但是由於迴圈引用，導致垃圾回收器都不會回收它們，所以就會導致記憶體洩露。

3.垃圾回收

#coding=utf-8
import gc

class ClassA():
    def __init__(self):
        print('object born,id:%s'%str(hex(id(self))))
    # def __del__(self):
    #     print('object del,id:%s'%str(hex(id(self))))

def f3():
    print("-----0------")
    # print(gc.collect())
    c1 = ClassA()
    c2 = ClassA()
    c1.t = c2
    c2.t = c1
    print("-----1------")
    del c1
    del c2
    print("-----2------")
    print(gc.garbage)
    print("-----3------")
    print(gc.collect()) #顯式執行垃圾回收
    print("-----4------")
    print(gc.garbage)
    print("-----5------")

if __name__ == '__main__':
    gc.set_debug(gc.DEBUG_LEAK) #設定gc模組的日誌
    f3()

執行結果:

-----0------
object born,id:0x724b20
object born,id:0x724b48
-----1------
-----2------
[]
-----3------
gc: collectable <ClassA instance at 0x724b20>
gc: collectable <ClassA instance at 0x724b48>
gc: collectable <dict 0x723300>
gc: collectable <dict 0x71bf60>
4
-----4------
[<__main__.ClassA instance at 0x724b20>, <__main__.ClassA instance at 0x724b48>, {'t': <__main__.ClassA instance at 0x724b48>}, {'t': <__main__.ClassA instance at 0x724b20>}]
-----5------

說明:

垃圾回收後的物件會放在gc.garbage列表裡面
gc.collect()會返回不可達的物件數目，4等於兩個物件以及它們對應的dict

有三種情況會觸發垃圾回收：

呼叫gc.collect(),
當gc模組的計數器達到閥值的時候。
程式退出的時候

4.gc模組常用功能解析

gc模組提供一個介面給開發者設定垃圾回收的選項。上面說到，採用引用計數的方法管理記憶體的一個缺陷是迴圈引用，而gc模組的一個主要功能就是解決迴圈引用的問題。

1)常用函式：

gc.set_debug(flags) 設定gc的debug日誌，一般設定為gc.DEBUG_LEAK

gc.collect([generation]) 顯式進行垃圾回收，可以輸入引數，0代表只檢查第一代的物件，1代表檢查一，二代的物件，2代表檢查一，二，三代的物件，如果不傳引數，執行一個full collection，也就是等於傳2。 返回不可達（unreachable objects）物件的數目

gc.get_threshold() 獲取的gc模組中自動執行垃圾回收的頻率。

gc.set_threshold(threshold0[, threshold1[, threshold2]) 設定自動執行垃圾回收的頻率。

gc.get_count() 獲取當前自動執行垃圾回收的計數器，返回一個長度為3的列表

2)gc模組的自動垃圾回收機制

必須要import gc模組，並且is_enable()=True才會啟動自動垃圾回收。

這個機制的主要作用就是發現並處理不可達的垃圾物件。

垃圾回收=垃圾檢查+垃圾回收

在Python中，採用分代收集的方法。把物件分為三代，一開始，物件在建立的時候，放在一代中，如果在一次一代的垃圾檢查中，改物件存活下來，就會被放到二代中，同理在一次二代的垃圾檢查中，該物件存活下來，就會被放到三代中。

gc模組裡面會有一個長度為3的列表的計數器，可以通過gc.get_count()獲取。

例如(488,3,0)，其中488是指距離上一次一代垃圾檢查，Python分配記憶體的數目減去釋放記憶體的數目，注意是記憶體分配，而不是引用計數的增加。例如：

print gc.get_count() # (590, 8, 0)
a = ClassA()
print gc.get_count() # (591, 8, 0)
del a
print gc.get_count() # (590, 8, 0)

3是指距離上一次二代垃圾檢查，一代垃圾檢查的次數，同理，0是指距離上一次三代垃圾檢查，二代垃圾檢查的次數。

gc模快有一個自動垃圾回收的閥值，即通過gc.get_threshold函式獲取到的長度為3的元組，例如(700,10,10) 每一次計數器的增加，gc模組就會檢查增加後的計數是否達到閥值的數目，如果是，就會執行對應的代數的垃圾檢查，然後重置計數器

例如，假設閥值是(700,10,10)：

當計數器從(699,3,0)增加到(700,3,0)，gc模組就會執行gc.collect(0),即檢查一代物件的垃圾，並重置計數器為(0,4,0)
當計數器從(699,9,0)增加到(700,9,0)，gc模組就會執行gc.collect(1),即檢查一、二代物件的垃圾，並重置計數器為(0,0,1)
當計數器從(699,9,9)增加到(700,9,9)，gc模組就會執行gc.collect(2),即檢查一、二、三代物件的垃圾，並重置計數器為(0,0,0)

注意點

gc模組唯一處理不了的是迴圈引用的類都有__del__方法，所以專案中要避免定義__del__方法

import gc

class ClassA():
    pass
    # def __del__(self):
    #     print('object born,id:%s'%str(hex(id(self))))

gc.set_debug(gc.DEBUG_LEAK)
a = ClassA()
b = ClassA()

a.next = b
b.prev = a

print "--1--"
print gc.collect()
print "--2--"
del a
print "--3--"
del b
print "--3-1--"
print gc.collect()
print "--4--"

執行結果：　　

--1--
0
--2--
--3--
--3-1--
gc: collectable <ClassA instance at 0x21248c8>
gc: collectable <ClassA instance at 0x21248f0>
gc: collectable <dict 0x2123030>
gc: collectable <dict 0x2123150>
4
--4--

如果把del開啟，執行結果為:　　

--1--
0
--2--
--3--
--3-1--
gc: uncollectable <ClassA instance at 0x6269b8>
gc: uncollectable <ClassA instance at 0x6269e0>
gc: uncollectable <dict 0x61bed0>
gc: uncollectable <dict 0x6230c0>
4
--4--