本文較為詳細(xì)的分析了python內(nèi)存管理機(jī)制。分享給大家供大家參考。具體分析如下：

內(nèi)存管理，對于Python這樣的動態(tài)語言，是至關(guān)重要的一部分，它在很大程度上甚至決定了Python的執(zhí)行效率，因為在Python的運行中，會創(chuàng)建和銷毀大量的對象，這些都涉及到內(nèi)存的管理。

小塊空間的內(nèi)存池

在Python中，許多時候申請的內(nèi)存都是小塊的內(nèi)存，這些小塊內(nèi)存在申請后，很快又會被釋放，由于這些內(nèi)存的申請并不是為了創(chuàng)建對象，所以并沒有對象一級的內(nèi)存池機(jī)制。

Python內(nèi)存池全景

這就意味著Python在運行期間會大量地執(zhí)行malloc和free的操作，頻繁地在用戶態(tài)和核心態(tài)之間進(jìn)行切換，這將嚴(yán)重影響Python的執(zhí)行效率。為了加速Python的執(zhí)行效率，Python引入了一個內(nèi)存池機(jī)制，用于管理對小塊內(nèi)存的申請和釋放。這也就是之前提到的Pymalloc機(jī)制。

在Python 2.5中，Python內(nèi)部默認(rèn)的小塊內(nèi)存與大塊內(nèi)存的分界點定在256個字節(jié)，這個分界點由前面我們看到的名為SMALL_REQUEST_THRESHOLD的符號控制。

也就是說，當(dāng)申請的內(nèi)存小于256字節(jié)時，PyObject_Malloc會在內(nèi)存池中申請內(nèi)存；當(dāng)申請的內(nèi)存大于256字節(jié)時，PyObject_Malloc的行為將蛻化為malloc的行為。當(dāng)然，通過修改Python源代碼，我們可以改變這個默認(rèn)值，從而改變Python的默認(rèn)內(nèi)存管理行為。

在一個對象的引用計數(shù)減為0時，與該對象對應(yīng)的析構(gòu)函數(shù)就會被調(diào)用。

但是要特別注意的是，調(diào)用析構(gòu)函數(shù)并不意味著最終一定會調(diào)用free釋放內(nèi)存空間，如果真是這樣的話，那頻繁地申請、釋放內(nèi)存空間會使 Python的執(zhí)行效率大打折扣（更何況Python已經(jīng)多年背負(fù)了人們對其執(zhí)行效率的不滿）。一般來說，Python中大量采用了內(nèi)存對象池的技術(shù)，使用這種技術(shù)可以避免頻繁地申請和釋放內(nèi)存空間。因此在析構(gòu)時，通常都是將對象占用的空間歸還到內(nèi)存池中。

"這個問題就是:Python的arena從來不釋放pool。這個問題為什么會引起類似于內(nèi)存泄漏的現(xiàn)象呢?？紤]這樣一種情形，申請10*1024*1024個16字節(jié)的小內(nèi)存，這就意味著必須使用160M的內(nèi)存，由于Python沒有默認(rèn)將前面提到的限制內(nèi)存池的WITH_MEMORY_LIMITS編譯符號打開，所以Python會完全使用arena來滿足你的需求，這都沒有問題，關(guān)鍵的問題在于過了一段時間，你將所有這些16字節(jié)的內(nèi)存都釋放了，這些內(nèi)存都回到arena的控制中，似乎沒有問題。

但是問題恰恰就在這時出現(xiàn)了。因為arena始終不會釋放它維護(hù)的pool集合，所以這160M的內(nèi)存始終被Python占用，如果以后程序運行中再也不需要160M如此巨大的內(nèi)存，這點內(nèi)存豈不是就浪費了？"

Python內(nèi)存管理規(guī)則：del的時候,把list的元素釋放掉,把管理元素的大對象回收到py對象緩沖池里。

希望本文所述對大家的Python程序設(shè)計有所幫助。

最新評論