gc --- 垃圾回收器接口?

此模塊提供可選的垃圾回收器的接口，提供的功能包括：關(guān)閉收集器、調(diào)整收集頻率、設(shè)置調(diào)試選項。它同時提供對回收器找到但是無法釋放的不可達對象的訪問。由于 Python 使用了帶有引用計數(shù)的回收器，如果你確定你的程序不會產(chǎn)生循環(huán)引用，你可以關(guān)閉回收器?？梢酝ㄟ^調(diào)用 gc.disable() 關(guān)閉自動垃圾回收。若要調(diào)試一個存在內(nèi)存泄漏的程序，調(diào)用 gc.set_debug(gc.DEBUG_LEAK) ；需要注意的是，它包含 gc.DEBUG_SAVEALL ，使得被垃圾回收的對象會被存放在 gc.garbage 中以待檢查。

gc 模塊提供下列函數(shù)：

gc.enable()?

啟用自動垃圾回收

gc.disable()?

停用自動垃圾回收

gc.isenabled()?

如果啟用了自動回收則返回 True。

gc.collect(generation=2)?

若被調(diào)用時不包含參數(shù)，則啟動完全的垃圾回收。可選的參數(shù) generation 可以是一個整數(shù)，指明需要回收哪一代（從 0 到 2 ）的垃圾。當參數(shù) generation 無效時，會引發(fā) ValueError 異常。返回發(fā)現(xiàn)的不可達對象的數(shù)目。

每當運行完整收集或最高代 (2) 收集時，為多個內(nèi)置類型所維護的空閑列表會被清空。 由于特定類型特別是 float 的實現(xiàn)，在某些空閑列表中并非所有項都會被釋放。

gc.set_debug(flags)?

設(shè)置垃圾回收器的調(diào)試標識位。調(diào)試信息會被寫入 sys.stderr 。此文檔末尾列出了各個標志位及其含義；可以使用位操作對多個標志位進行設(shè)置以控制調(diào)試器。

gc.get_debug()?

返回當前調(diào)試標識位。

gc.get_objects(generation=None)?

返回一個收集器所跟蹤的所有對象的列表，所返回的列表除外。 如果 generation 不為 None，則只返回收集器所跟蹤的屬于該生成的對象。

在 3.8 版更改: 新的 generation 形參。

引發(fā)一個 審計事件 gc.get_objects，附帶參數(shù) generation。

gc.get_stats()?

返回一個包含三個字典對象的列表，每個字典分別包含對應(yīng)代的從解釋器開始運行的垃圾回收統(tǒng)計數(shù)據(jù)。字典的鍵的數(shù)目在將來可能發(fā)生改變，目前每個字典包含以下內(nèi)容：

• collections 是該代被回收的次數(shù)；

• collected 是該代中被回收的對象總數(shù)；

• uncollectable 是在這一代中被發(fā)現(xiàn)無法收集的對象總數(shù) （因此被移動到 garbage 列表中）。

3.4 新版功能.

gc.set_threshold(threshold0[, threshold1[, threshold2]])?

設(shè)置垃圾回收閾值（收集頻率）。 將 threshold0 設(shè)為零會禁用回收。

垃圾回收器把所有對象分類為三代，其依據(jù)是對象在多少次垃圾回收后幸存。 新建對象會被放在最年輕代（第 0 代）。 如果一個對象在一次垃圾回收后幸存，它會被移入下一個較老代。 由于第 2 代是最老代，這一代的對象在一次垃圾回收后仍會保留原樣。 為了確定何時要運行，垃圾回收器會跟蹤自上一次回收后對象分配和釋放的數(shù)量。 當分配數(shù)量減去釋放數(shù)量的結(jié)果值大于 threshold0 時，垃圾回收就會開始。 初始時只有第 0 代會被檢查。 如果自第 1 代被檢查后第 0 代已被檢查超過 threshold1 次，則第 1 也會被檢查。 對于第三代來說情況還會更復雜，請參閱 Collecting the oldest generation 來了解詳情。

gc.get_count()?

將當前回收計數(shù)以形為 (count0, count1, count2) 的元組返回。

gc.get_threshold()?

將當前回收閾值以形為 (threshold0, threshold1, threshold2) 的元組返回。

gc.get_referrers(*objs)?

返回直接引用任意一個 ojbs 的對象列表。這個函數(shù)只定位支持垃圾回收的容器；引用了其它對象但不支持垃圾回收的擴展類型不會被找到。

需要注意的是，已經(jīng)解除對 objs 引用的對象，但仍存在于循環(huán)引用中未被回收時，仍然會被作為引用者出現(xiàn)在返回的列表當中。若要獲取當前正在引用 objs 的對象，需要調(diào)用 collect() 然后再調(diào)用 get_referrers() 。

警告

在使用 get_referrers() 返回的對象時必須要小心，因為其中一些對象可能仍在構(gòu)造中因此處于暫時的無效狀態(tài)。不要把 get_referrers() 用于調(diào)試以外的其它目的。

引發(fā)一個 審計事件 gc.get_referrers，附帶參數(shù) objs。

gc.get_referents(*objs)?

返回被任意一個參數(shù)中的對象直接引用的對象的列表。返回的被引用對象是被參數(shù)中的對象的C語言級別方法（若存在） tp_traverse 訪問到的對象，可能不是所有的實際直接可達對象。只有支持垃圾回收的對象支持 tp_traverse  方法，并且此方法只會在需要訪問涉及循環(huán)引用的對象時使用。因此，可以有以下例子：一個整數(shù)對其中一個參數(shù)是直接可達的，這個整數(shù)有可能出現(xiàn)或不出現(xiàn)在返回的結(jié)果列表當中。

引發(fā)一個 審計事件 gc.get_referents，附帶參數(shù) objs。

gc.is_tracked(obj)?

當對象正在被垃圾回收器監(jiān)控時返回 True ，否則返回 False 。一般來說，原子類的實例不會被監(jiān)控，而非原子類（如容器、用戶自定義的對象）會被監(jiān)控。然而，會有一些特定類型的優(yōu)化以便減少垃圾回收器在簡單實例（如只含有原子性的鍵和值的字典）上的消耗。

>>>

>>> gc.is_tracked(0)
False
>>> gc.is_tracked("a")
False
>>> gc.is_tracked([])
True
>>> gc.is_tracked({})
False
>>> gc.is_tracked({"a": 1})
False
>>> gc.is_tracked({"a": []})
True

3.1 新版功能.

gc.is_finalized(obj)?

如果給定對象已被垃圾回收器終結(jié)則返回 True，否則返回 False。

>>>

>>> x = None
>>> class Lazarus:
...     def __del__(self):
...         global x
...         x = self
...
>>> lazarus = Lazarus()
>>> gc.is_finalized(lazarus)
False
>>> del lazarus
>>> gc.is_finalized(x)
True

3.9 新版功能.

gc.freeze()?

凍結(jié) gc 所跟蹤的所有對象 —— 將它們移至永久代并忽略所有未來的集合。 這可以在 POSIX fork() 調(diào)用之前使用以便令對寫入復制保持友好或加速收集。 并且在 POSIX fork() 調(diào)用之前的收集也可以釋放頁面以供未來分配，這也可能導致寫入時復制，因此建議在主進程中禁用 gc 并在 fork 之前凍結(jié)，而在子進程中啟用 gc。

3.7 新版功能.

gc.unfreeze()?

解凍永久代中的對象，并將它們放回到年老代中。

3.7 新版功能.

gc.get_freeze_count()?

返回永久代中的對象數(shù)量。

3.7 新版功能.

提供以下變量僅供只讀訪問（你可以修改但不應(yīng)該重綁定它們）：

gc.garbage?

一個回收器發(fā)現(xiàn)不可達而又無法被釋放的對象（不可回收對象）列表。 從 Python 3.4 開始，該列表在大多數(shù)時候都應(yīng)該是空的，除非使用了含有非 NULL tp_del 空位的 C 擴展類型的實例。

如果設(shè)置了 DEBUG_SAVEALL ，則所有不可訪問對象將被添加至該列表而不會被釋放。

在 3.2 版更改: 當 interpreter shutdown 即解釋器關(guān)閉時，若此列表非空，會產(chǎn)生 ResourceWarning ，即資源警告，在默認情況下此警告不會被提醒。如果設(shè)置了 DEBUG_UNCOLLECTABLE ，所有無法被回收的對象會被打印。

在 3.4 版更改: 根據(jù) PEP 442 ，帶有 __del__() 方法的對象最終不再會進入 gc.garbage 。

gc.callbacks?

在垃圾回收器開始前和完成后會被調(diào)用的一系列回調(diào)函數(shù)。這些回調(diào)函數(shù)在被調(diào)用時使用兩個參數(shù)： phase 和 info 。

phase 可為以下兩值之一：

"start": 垃圾回收即將開始。

"stop": 垃圾回收已結(jié)束。

info is a dict providing more information for the callback. The following keys are currently defined:

"generation"（代） ：正在被回收的最久遠的一代。

"collected"（已回收的 ）: 當*phase* 為 "stop" 時，被成功回收的對象的數(shù)目。

"uncollectable"（不可回收的）: 當 phase 為 "stop" 時，不能被回收并被放入 garbage 的對象的數(shù)目。

應(yīng)用程序可以把他們自己的回調(diào)函數(shù)加入此列表。主要的使用場景有：

統(tǒng)計垃圾回收的數(shù)據(jù)，如：不同代的回收頻率、回收所花費的時間。

使應(yīng)用程序可以識別和清理他們自己的在 garbage 中的不可回收類型的對象。

3.3 新版功能.

以下常量被用于 set_debug() ：

gc.DEBUG_STATS?

在回收完成后打印統(tǒng)計信息。當回收頻率設(shè)置較高時，這些信息會比較有用。

gc.DEBUG_COLLECTABLE?

當發(fā)現(xiàn)可回收對象時打印信息。

gc.DEBUG_UNCOLLECTABLE?

打印找到的不可回收對象的信息（指不能被回收器回收的不可達對象）。這些對象會被添加到 garbage 列表中。

在 3.2 版更改: 當 interpreter shutdown 時，即解釋器關(guān)閉時，若 garbage 列表中存在對象，這些對象也會被打印輸出。

gc.DEBUG_SAVEALL?

設(shè)置后，所有回收器找到的不可達對象會被添加進 garbage 而不是直接被釋放。這在調(diào)試一個內(nèi)存泄漏的程序時會很有用。

gc.DEBUG_LEAK?

調(diào)試內(nèi)存泄漏的程序時，使回收器打印信息的調(diào)試標識位。（等價于 DEBUG_COLLECTABLE | DEBUG_UNCOLLECTABLE | DEBUG_SAVEALL ）。