如果對編程語言進行分類的話,一般可以分為靜態語言和動態語言,也可以分為編譯型語言和解釋型語言。但個人覺得還可以有一種劃分標準,就是是否自帶垃圾回收。關于有沒有垃圾回收,陳儒老師在《Python 2.5源碼剖析》中,總結得非常好。
對于像 C 和 C++ 這類語言,程序員被賦予了極大的自由,可以任意地申請內存。但權力的另一面對應著責任,程序員最后不使用的時候,必須負責將申請的內存釋放掉,并把無效指針設置為空。可以說,這一點是萬惡之源,大量內存泄漏、懸空指針、越界訪問的 bug 由此產生。
而現代的開發語言(比如 C#、Java)都帶有垃圾回收機制,將開發人員從維護內存分配和清理的繁重工作中解放出來,開發者不用再擔心內存泄漏的問題,但同時也剝奪了程序員和內存親密接觸的機會,并犧牲了一定的運行效率。不過好處就是提高了開發效率,并降低了 bug 發生的概率。
由于現在的垃圾回收機制已經非常成熟了,把對性能的影響降到了最低,因此大部分場景選擇的都是帶垃圾回收的語言。
而 Python 里面同樣具有垃圾回收,只不過它是為引用計數機制服務的。所以解釋器通過內部的引用計數和垃圾回收,代替程序員進行繁重的內存管理工作,關于垃圾回收我們后面會詳細說,先來看一下引用計數。
Python 一切皆對象,所有對象都有一個 ob_refcnt 字段,該字段維護著對象的引用計數,從而也決定對象的存在與消亡。下面來探討一下引用計數,當然引用計數在介紹 PyObject 的時候說的很詳細了,這里再回顧一下。
但需要說明的是,比起類型對象,我們更關注實例對象的行為。引用計數也是如此,只有實例對象,我們探討引用計數才是有意義的。
因為內置的類型對象超越了引用計數規則,永遠都不會被析構,或者銷毀,因為它們在底層是被靜態定義好的。
圖片
很明顯,內置的類型對象屬于永恒對象。關于永恒對象之前解釋過,指的是那些永遠不會被回收的對象,像 None、小整數對象池里面的整數、以及內置的類型對象,它們都是永恒對象。
如果對象是永恒對象,那么它的引用計數會直接被初始化為 uint32 最大值。當然,如果一個對象原本不是永恒對象,但它的引用計數之后達到了 uint32 最大值(有 2 ** 32 - 1 個變量在引用它),那么它也會被判定為永恒對象,但很明顯這只是理論情況,現實不可能出現,因為一個對象不可能有這么多的變量在引用它。
同理,我們自定義的類,雖然可以被回收,但是探討它的引用計數也是沒有價值的。我們舉個栗子:
class A: passdel A
首先 del 關鍵字只能作用于變量,不可以作用于對象,比如 e = 2.71,可以 del e,但是不可以 del 2.71,這是不符合語法規則的。因為 del 的作用是刪除變量,并讓其指向對象的引用計數減 1,所以我們只能 del 變量,不可以 del 對象。
同樣的,使用 def、class 關鍵字定義完之后拿到的也是變量,比如上面代碼中的 A,只要是變量,就可以被 del。但是 del 變量只是刪除了該變量,換言之就是讓該變量無法再被使用,至于變量指向的對象是否會被回收,就看是否還有其它的變量也指向它。
總結:對象是否被回收完全由解釋器判斷它的引用計數是否為 0 所決定。
我們一直說對象的 ob_refcnt 字段負責維護引用計數,當然這是沒問題的。但 Python 從 3.12 開始又引入了 ob_refcnt_split 字段,也負責維護引用計數。
圖片
ob_refcnt_split 是一個長度為 2、類型為 uint32 的數組,但只會用其中一個元素來維護引用計數。如果達到了 uint32 最大值,那么判定為永恒對象,相關源碼后續聊。
我們來看看永恒對象的初始化過程,以 list 類型對象為例,看看它的引用計數是怎么設置的。
// Objects/listobject.c// 引用計數和類型由宏 PyVarObject_HEAD_INIT 負責設置PyTypeObject PyList_Type = { PyVarObject_HEAD_INIT(&PyType_Type, 0) "list", sizeof(PyListObject), 0, ...}; // Include/object.h#define PyVarObject_HEAD_INIT(type, size) / { / PyObject_HEAD_INIT(type) / (size) / },#define PyObject_HEAD_INIT(type) / { / { _Py_IMMORTAL_REFCNT }, / (type) / }, #define _Py_IMMORTAL_REFCNT UINT_MAX
我們看到類型對象在初始化的時候,引用計數直接被設置成了 uint32 最大值。當然啦,這并不是說有 2 ** 32 - 1 個變量在引用,而是通過將引用計數設置為 uint32 最大值,來表示這是一個不會被銷毀的永恒對象。
操作引用計數無非就是將其加一或減一,至于什么時候加一、什么時候減一,在介紹 PyObject 的時候已經說的很詳細了,可以看一下。這里我們通過源碼,看看引用計數具體是怎么操作的。
在底層,解釋器會通過 Py_INCREF 和 Py_DECREF 兩個函數來增加和減少對象的引用計數,而當對象的引用計數減少到 0 后,Py_DECREF 將調用對應的析構函數來釋放該對象所占的內存和系統資源。這個析構函數由對象的類型對象中定義的函數指針來指定,也就是 tp_dealloc。
下面我們來看看底層實現,不過在介紹 Py_INCREF 和 Py_DECREF 之前,先來看幾個其它的函數,這些函數非常常見,有必要單獨說一下。
// Include/object.h// 返回對象的引用計數,說白了就是獲取對象的 ob_refcnt 字段// 因為該字段負責維護引用計數static inline Py_ssize_t Py_REFCNT(PyObject *ob) { return ob->ob_refcnt;}// 設置對象的引用計數static inline void Py_SET_REFCNT(PyObject *ob, Py_ssize_t refcnt) { // 如果對象是永恒對象,那么直接返回 // 不會再對永恒對象的引用計數做任何設置 if (_Py_IsImmortal(ob)) { return; } ob->ob_refcnt = refcnt;}// 返回對象的類型,獲取 ob_type 字段static inline PyTypeObject* Py_TYPE(PyObject *ob) { return ob->ob_type;}// 設置對象的類型static inline void Py_SET_TYPE(PyObject *ob, PyTypeObject *type) { ob->ob_type = type;}// 返回對象的 ob_sizestatic inline Py_ssize_t Py_SIZE(PyObject *ob) { // _PyVarObject_CAST(ob) 等價于 (PyVarObject *)(ob) return _PyVarObject_CAST(ob)->ob_size;}// 設置對象的 ob_sizestatic inline void Py_SET_SIZE(PyVarObject *ob, Py_ssize_t size) { ob->ob_size = size;}
這幾個函數是用來設置引用計數、類型和 ob_size 的,比較簡單,即使不看源碼也能猜出內部都做了什么。需要注意的是,這些函數在之前的 Python 源碼中都是以宏的形式存在,但在 3.12 里面變成內聯函數了,本質上沒有太大差異。
然后來看看 Py_INCREF 和 Py_DECREF,它們負責對引用計數執行加一和減一操作。
注意:這兩個函數里面存在宏判斷,我們這里只保留判斷之后的結果。
// Include/object.hstatic inline Py_ALWAYS_INLINE void Py_INCREF(PyObject *op){ // ob_refcnt_split 是長度為 2 的數組,但只會使用一個元素 // 至于使用哪一個,則取決于字節序,是大端存儲還是小端存儲 PY_UINT32_T cur_refcnt = op->ob_refcnt_split[PY_BIG_ENDIAN]; // 將當前引用計數加一 PY_UINT32_T new_refcnt = cur_refcnt + 1; // 如果 cur_refcnt 已經達到了 uint32 最大值,那么加一之后會產生環繞,繼續從零開始 // 所以如果 new_refcnt 為 0,證明當前對象的引用計數為 uint32 最大值 // 那么該對象就是永恒對象,而永恒對象不會被回收,引用計數也不再做處理,因此直接返回 if (new_refcnt == 0) { return; } // 否則說明不是引用計數,那么進行更新 op->ob_refcnt_split[PY_BIG_ENDIAN] = new_refcnt; // 稍后解釋 _Py_INCREF_STAT_INC();}
這里估計有人發現了一個問題,就是當前只更新了 ob_refcnt_split,而沒有更新 ob_refcnt。原因很簡單,因為這兩個字段組成的是共同體,它們占用同一份內存。
ob_refcnt 是 int64 整數,ob_refcnt_split 是長度為 2 的 uint32 數組,它們都是 8 字節,并且占用的是同一份 8 字節的內存。所以 ob_refcnt_split 里面的兩個元素正好對應 ob_refcnt 的低 32 位和高 32 位。
因此在修改 ob_refcnt_split 的時候,同時也修改了 ob_refcnt,所以整個操作只進行了一次。并且從源碼中也可以看出,對象的引用計數不會超過 uint32 最大值,因為當達到這個值的時候會被判定為永恒對象,而永恒對象的引用計數不會再做任何操作,因為永恒對象會永遠存在。
但還是那句話,除非一開始就將引用計數設置為 uint32 最大值,讓對象成為永恒對象,否則單靠創建變量是不可能讓對象的引用計數達到這一限制的,因為不管再復雜的項目,也不會出現一個對象被 2 ** 32 - 1 個變量指向的情況,所以 uint32 是完全夠用的。
然后在函數的最后出現了一個 _Py_INCREF_STAT_INC 函數,它負責對一些全局統計信息進行更新,目前無需關注。
以上是 Py_INCREF,負責將引用計數加一,再來看看 Py_DECREF,它負責將引用計數減一。
// Include/object.hstatic inline Py_ALWAYS_INLINE void Py_DECREF(PyObject *op){ // 如果對象是永恒對象,那么直接返回,因為永恒對象不會被回收 // 它的引用計數不會再發生變化,始終保持 uint32 最大值 if (_Py_IsImmortal(op)) { return; } // 更新一些全局統計信息,和 _Py_INCREF_STAT_INC 作用一樣 _Py_DECREF_STAT_INC(); // 重點來了,首先將 ob_refcnt 減一,然后判斷它是否等于 0 // 如果為 0,說明對象已經不被任何變量引用了,那么應該被銷毀 if (--op->ob_refcnt == 0) { // 調用 _Py_Dealloc 將對象銷毀,這個函數內部的邏輯很簡單 // 雖然里面存在很多宏判斷,導致代碼看起來很復雜 // 但如果只看編譯后的最終結果,那么代碼就只有下面三行 /* PyTypeObject *type = Py_TYPE(op); destructor dealloc = type->tp_dealloc; (*dealloc)(op); */ // 會獲取類型對象的 tp_dealloc,然后調用,銷毀實例對象 _Py_Dealloc(op); }}
以上就是 Py_INCREF 和 Py_DECREF 兩個函數的具體實現,但是它們不能接收空指針,如果希望能接收空指針,那么可以使用另外兩個函數。
圖片
Py_XINCREF 和 Py_XDECREF 會額外對指針做一次判斷,如果為空則什么也不做,不為空再調用 Py_INCREF 和 Py_DECREF。
在一個對象的引用計數為 0 時,與該對象對應的析構函數就會被調用。但是要特別注意的是,我們之前說調用析構函數之后會回收對象,或者銷毀對象、刪除對象等等,意思是將這個對象從內存中抹去,但并不意味著要釋放空間。換句話說就是對象沒了,但對象占用的內存卻有可能還在。
如果對象沒了,占用的內存也要釋放的話,那么頻繁申請、釋放內存空間會使 Python 的執行效率大打折扣,更何況 Python 已經背負了人們對其執行效率的不滿這么多年。
所以 Python 底層大量采用了緩存池的技術,使用這種技術可以避免頻繁地申請和釋放內存空間。因此在析構的時候,只是將對象占用的空間歸還到緩存池中,并沒有真的釋放。
這一點,在后面剖析內置實例對象的實現中,將會看得一清二楚,因為大部分內置的實例對象都會有自己的緩存池。
到此我們的基礎概念就算說完了,從下一篇文章開始就要詳細剖析內置對象的底層實現了,比如浮點數、復數、整數、布爾值、None、bytes 對象、bytearray 對象、字符串、元組、列表、字典、集合等等,所有的內置對象都會詳細地剖析一遍,看看它是如何實現的。
有了目前為止的這些基礎,我們后面就會輕松很多,先把對象、變量等概念梳理清楚,然后再來搞這些數據結構的底層實現。
本文鏈接:http://www.tebozhan.com/showinfo-26-91531-0.html一個 Python 對象會在何時被銷毀?
聲明:本網頁內容旨在傳播知識,若有侵權等問題請及時與本網聯系,我們將在第一時間刪除處理。郵件:2376512515@qq.com
上一篇: JDK并發編程類庫,有坑!!!