禁用python的gc機制後,python有gc嗎

本文目錄一覽：

• 1、python為啥運行效率不高
• 2、Python 的內存管理機制
• 3、pythonmemory運行到99%停住了
• 4、BAT面試題28：Python是如何進行內存管理的
• 5、如何讓python的GC機制崩潰
• 6、Python的垃圾回收機制原理

python為啥運行效率不高

原因：1、python是動態語言；2、python是解釋執行，但是不支持JIT；3、python中一切都是對象，每個對象都需要維護引用計數，增加了額外的工作。4、python GIL；5、垃圾回收。

當我們提到一門編程語言的效率時：通常有兩層意思，第一是開發效率，這是對程序員而言，完成編碼所需要的時間；另一個是運行效率，這是對計算機而言，完成計算任務所需要的時間。編碼效率和運行效率往往是魚與熊掌的關係，是很難同時兼顧的。不同的語言會有不同的側重，python語言毫無疑問更在乎編碼效率，life is short，we use python。

雖然使用python的編程人員都應該接受其運行效率低的事實，但python在越多越來的領域都有廣泛應用，比如科學計算 、web伺服器等。程序員當然也希望python能夠運算得更快，希望python可以更強大。

首先，python相比其他語言具體有多慢，這個不同場景和測試用例，結果肯定是不一樣的。這個網址給出了不同語言在各種case下的性能對比，這一頁是python3和C++的對比，下面是兩個case：

從上圖可以看出，不同的case，python比C++慢了幾倍到幾十倍。

python運算效率低，具體是什麼原因呢，下列羅列一些：

第一：python是動態語言

一個變數所指向對象的類型在運行時才確定，編譯器做不了任何預測，也就無從優化。舉一個簡單的例子：　r = a + b。　a和b相加，但a和b的類型在運行時才知道，對於加法操作，不同的類型有不同的處理，所以每次運行的時候都會去判斷a和b的類型，然後執行對應的操作。而在靜態語言如C++中，編譯的時候就確定了運行時的代碼。

另外一個例子是屬性查找，關於具體的查找順序在《python屬性查找》中有詳細介紹。簡而言之，訪問對象的某個屬性是一個非常複雜的過程，而且通過同一個變數訪問到的python對象還都可能不一樣（參見Lazy property的例子）。而在C語言中，訪問屬性用對象的地址加上屬性的偏移就可以了。

第二：python是解釋執行，但是不支持JIT（just in time compiler）。雖然大名鼎鼎的google曾經嘗試Unladen Swallow 這個項目，但最終也折了。

第三：python中一切都是對象，每個對象都需要維護引用計數，增加了額外的工作。

第四：python GIL，GIL是Python最為詬病的一點，因為GIL，python中的多線程並不能真正的並發。如果是在IO bound的業務場景，這個問題並不大，但是在CPU BOUND的場景，這就很致命了。所以筆者在工作中使用python多線程的情況並不多，一般都是使用多進程（pre fork），或者在加上協程。即使在單線程，GIL也會帶來很大的性能影響，因為python每執行100個opcode（默認，可以通過sys.setcheckinterval()設置）就會嘗試線程的切換，具體的源代碼在ceval.c::PyEval_EvalFrameEx。

 第五：垃圾回收，這個可能是所有具有垃圾回收的編程語言的通病。python採用標記和分代的垃圾回收策略，每次垃圾回收的時候都會中斷正在執行的程序，造成所謂的頓卡。infoq上有一篇文章，提到禁用Python的GC機制後，Instagram性能提升了10%。感興趣的讀者可以去細讀。

推薦課程：Python機器學習(Mooc禮欣、嵩天教授)

Python 的內存管理機制

Python採用自動內存管理，即Python會自動進行垃圾回收，不需要像C、C++語言一樣需要程序員手動釋放內存，手動釋放可以做到實時性，但是存在內存泄露、空指針等風險。

Python自動垃圾回收也有自己的優點和缺點：優點：

缺點：

Python的垃圾回收機制採用 以引用計數法為主，分代回收為輔 的策略。

先聊引用計數法，Python中每個對象都有一個核心的結構體，如下

一個對象被創建時，引用計數值為1，當一個變數引用一個對象時，該對象的引用計數ob_refcnt就加一，當一個變數不再引用一個對象時，該對象的引用計數ob_refcnt就減一，Python判斷是否回收一個對象，會將該對象的引用計數值ob_refcnt減一判斷結果是否等於0，如果等於0就回收，如果不等於0就不回收，如下：

一個對象在以下三種情況下引用計數會增加：

一個對象在以下三種情況引用計數會減少：

驗證案例：

運行結果：

事實上，關於垃圾回收的測試，最好在終端環境下測試，比如整數257，它在PyCharm中用下面的測試代碼列印出來的結果是4，而如果在終端環境下列印出來的結果是2。這是因為終端代表的是原始的Python環境，而PyCharm等IDE做了一些特殊處理，在Python原始環境中，整數緩存的範圍是在 [-5, 256] 的雙閉合區間內，而PyCharm做了特殊處理之後，PyCharm整數緩存的範圍變成了 [-5, 無窮大]，但我們必須以終端的測試結果為主，因為它代表的是原始的Python環境，並且代碼最終也都是要發布到終端運行的。

好，那麼回到終端，我們來看兩種特殊情況

前面學習過了，整數緩存的範圍是在 [-5, 256] 之間，這些整數對象在程序載入完全就已經駐留在內存之中，並且直到程序結束退出才會釋放佔有的內存，測試案例如下：

如果字元串的內容只由字母、數字、下劃線構成，那麼它只會創建一個對象駐留在內存中，否則，每創建一次都是一個新的對象。

引用計數法有缺陷，它無法解決循環引用問題，即A對象引用了B對象，B對象又引用了A對象，這種情況下，A、B兩個對象都無法通過引用計數法來進行回收，有一種解決方法是程序運行結束退出時進行回收，代碼如下：

前面講過，Python垃圾回收機制的策略是 以引用計數法為主，以分代回收為輔 。分代回收就是為了解決循環引用問題的。

Python採用分代來管理對象的生命周期：第0代、第1代、第2代，當一個對象被創建時，會被分配到第一代，默認情況下，當第0代的對象達到700個時，就會對處於第0代的對象進行檢測和回收，將存在循環引用的對象釋放內存，經過垃圾回收後，第0代中存活的對象會被分配為第1代，同樣，當第1代的對象個數達到10個時，也會對第1代的對象進行檢測和回收，將存在循環引用的對象釋放內存，經過垃圾回收後，第1代中存活的對象會被分配為第2代，同樣，當第二代的對象個數達到10個時，也會對第2代的對象進行檢測和回收，將存在循環引用的對象釋放內存。Python就是通過這樣一種策略來解決對象之間的循環引用問題的。

測試案例：

運行結果：

如上面的運行結果，當第一代中對象的個數達到699個即將突破臨界值700時（在列印699之前就已經回收了，所以看不到698和699）進行了垃圾回收，回收掉了循環引用的對象。

第一代、第二代、第三代分代回收都是有臨界值的，這個臨界值可以通過調用 gc.get_threshold 方法查看，如下：

當然，如果對默認臨界值不滿意，也可以調用 gc.set_threshold 方法來自定義臨界值，如下：

最後，簡單列出兩個gc的其它方法，了解一下，但禁止在程序代碼中使用

以上就是對Python垃圾回收的簡單介紹，當然，深入研究肯定不止這些內容，目前，了解到這個程度也足夠了。

pythonmemory運行到99%停住了

因為遇到MemoryError的問題了。

解決方法。1.回收一些暫時不用的內存。2.修改數據類型的長度。3.讀文件的時候可以逐行讀取或者分塊讀取，避免一次性把數據都讀入到內存里，導致程序崩掉。4.修改磁碟虛擬內存。

python的psutil包可以查看內存的使用情況，直接點任務管理器也可以查看電腦的內存使用佔比，還可以kill掉一些不用的進程來釋放內存。但是如果想要釋放掉python佔用的內存，比如一些使用過後續又不再需要的數據，可以導入gc包直接刪除掉數據並回收內存。

BAT面試題28：Python是如何進行內存管理的

Python的內存管理，一般從以下三個方面來說：

1)對象的引用計數機制(四增五減)

2)垃圾回收機制(手動自動，分代回收)

3)內存池機制(大m小p)

1)對象的引用計數機制

要保持追蹤內存中的對象，Python使用了引用計數這一簡單的技術。sys.getrefcount(a)可以查看a對象的引用計數，但是比正常計數大1，因為調用函數的時候傳入a，這會讓a的引用計數+1

2)垃圾回收機制

吃太多，總會變胖，Python也是這樣。當Python中的對象越來越多，它們將佔據越來越大的內存。不過你不用太擔心Python的體形，它會在適當的時候「減肥」，啟動垃圾回收(garbage

collection)，將沒用的對象清除

從基本原理上，當Python的某個對象的引用計數降為0時，說明沒有任何引用指向該對象，該對象就成為要被回收的垃圾了

比如某個新建對象，它被分配給某個引用，對象的引用計數變為1。如果引用被刪除，對象的引用計數為0，那麼該對象就可以被垃圾回收。

然而，減肥是個昂貴而費力的事情。垃圾回收時，Python不能進行其它的任務。頻繁的垃圾回收將大大降低Python的工作效率。如果內存中的對象不多，就沒有必要總啟動垃圾回收。

所以，Python只會在特定條件下，自動啟動垃圾回收。當Python運行時，會記錄其中分配對象(object

allocation)和取消分配對象(object deallocation)的次數。當兩者的差值高於某個閾值時，垃圾回收才會啟動。

我們可以通過gc模塊的get_threshold()方法，查看該閾值。

3)內存池機制

Python中有分為大內存和小內存：(256K為界限分大小內存)

1、大內存使用malloc進行分配

2、小內存使用內存池進行分配

python中的內存管理機制都有兩套實現，一套是針對小對象，就是大小小於256K時，pymalloc會在內存池中申請內存空間;當大於256K時，則會直接執行系統的malloc的行為來申請內存空間。

如何讓python的GC機制崩潰

（Memory Leak，內存泄漏）

為什麼會產生內存泄漏？

當一個對象已經不需要再使用本該被回收時，另外一個正在使用的對象持有它的引用從而導致它不能被回收，這導致本該被回收的對象不能被回收而停留在堆內存中，這就產生了內存泄漏。

內存泄漏對程序的影響？

內存泄漏是造成應用程序OOM的主要原因之一。我們知道Android系統為每個應用程序分配的內存是有限的，而當一個應用中產生的內存泄漏比較多時，這就難免會導致應用所需要的內存超過系統分配的內存限額，這就造成了內存溢出從而導致應用Crash。

如何檢查和分析內存泄漏？

因為內存泄漏是在堆內存中，所以對我們來說並不是可見的。通常我們可以藉助MAT、LeakCanary等工具來檢測應用程序是否存在內存泄漏。

1、MAT是一款強大的內存分析工具，功能繁多而複雜。

2、LeakCanary則是由Square開源的一款輕量級的第三方內存泄漏檢測工具，當檢測到程序中產生內存泄漏時，它將以最直觀的方式告訴我們哪裡產生了內存泄漏和導致誰泄漏了而不能被回收。

常見的內存泄漏及解決方法

1、單例造成的內存泄漏

由於單例的靜態特性使得其生命周期和應用的生命周期一樣長，如果一個對象已經不再需要使用了，而單例對象還持有該對象的引用，就會使得該對象不能被正常回收，從而導致了內存泄漏。

示例：防止單例導致內存泄漏的實例

// 使用了單例模式

public class AppManager {

private static AppManager instance;

private Context context;

private AppManager(Context context) {

this.context = context;

}

public static AppManager getInstance(Context context) {

if (instance != null) {

instance = new AppManager(context);

}

return instance;

}

}

這樣不管傳入什麼Context最終將使用Application的Context，而單例的生命周期和應用的一樣長，這樣就防止了內存泄漏。？？？

2、非靜態內部類創建靜態實例造成的內存泄漏

例如，有時候我們可能會在啟動頻繁的Activity中，為了避免重複創建相同的數據資源，可能會出現如下寫法：

public class MainActivity extends AppCompatActivity {

private static TestResource mResource = null;

@Override

protected void onCreate(Bundle savedInstanceState) {

super.onCreate(savedInstanceState);

setContentView(R.layout.activity_main);

if(mResource == null){

mResource = new TestResource();

}

//…

}

class TestResource {

//…

}

}

這樣在Activity內部創建了一個非靜態內部類的單例，每次啟動Activity時都會使用該單例的數據。雖然這樣避免了資源的重複創建，但是這種寫法卻會造成內存泄漏。因為非靜態內部類默認會持有外部類的引用，而該非靜態內部類又創建了一個靜態的實例，該實例的生命周期和應用的一樣長，這就導致了該靜態實例一直會持有該Activity的引用，從而導致Activity的內存資源不能被正常回收。

解決方法：將該內部類設為靜態內部類或將該內部類抽取出來封裝成一個單例，如果需要使用Context，就使用Application的Context。

3、Handler造成的內存泄漏

示例：創建匿名內部類的靜態對象

public class MainActivity extends AppCompatActivity {

private final Handler handler = new Handler() {

@Override

public void handleMessage(Message msg) {

// …

}

};

@Override

protected void onCreate(Bundle savedInstanceState) {

super.onCreate(savedInstanceState);

setContentView(R.layout.activity_main);

new Thread(new Runnable() {

@Override

public void run() {

// …

handler.sendEmptyMessage(0x123);

}

});

}

}

1、從Android的角度

當Android應用程序啟動時，該應用程序的主線程會自動創建一個Looper對象和與之關聯的MessageQueue。當主線程中實例化一個Handler對象後，它就會自動與主線程Looper的MessageQueue關聯起來。所有發送到MessageQueue的Messag都會持有Handler的引用，所以Looper會據此回調Handle的handleMessage()方法來處理消息。只要MessageQueue中有未處理的Message，Looper就會不斷的從中取出並交給Handler處理。另外，主線程的Looper對象會伴隨該應用程序的整個生命周期。

2、 Java角度

在Java中，非靜態內部類和匿名類內部類都會潛在持有它們所屬的外部類的引用，但是靜態內部類卻不會。

對上述的示例進行分析，當MainActivity結束時，未處理的消息持有handler的引用，而handler又持有它所屬的外部類也就是MainActivity的引用。這條引用關係會一直保持直到消息得到處理，這樣阻止了MainActivity被垃圾回收器回收，從而造成了內存泄漏。

解決方法：將Handler類獨立出來或者使用靜態內部類，這樣便可以避免內存泄漏。

4、線程造成的內存泄漏

示例：AsyncTask和Runnable

public class MainActivity extends AppCompatActivity {

@Override

protected void onCreate(Bundle savedInstanceState) {

super.onCreate(savedInstanceState);

setContentView(R.layout.activity_main);

new Thread(new MyRunnable()).start();

new MyAsyncTask(this).execute();

}

class MyAsyncTask extends AsyncTaskVoid, Void, Void {

// …

public MyAsyncTask(Context context) {

// …

}

@Override

protected Void doInBackground(Void… params) {

// …

return null;

}

@Override

protected void onPostExecute(Void aVoid) {

// …

}

}

class MyRunnable implements Runnable {

@Override

public void run() {

// …

}

}

}

AsyncTask和Runnable都使用了匿名內部類，那麼它們將持有其所在Activity的隱式引用。如果任務在Activity銷毀之前還未完成，那麼將導致Activity的內存資源無法被回收，從而造成內存泄漏。

解決方法：將AsyncTask和Runnable類獨立出來或者使用靜態內部類，這樣便可以避免內存泄漏。

5、資源未關閉造成的內存泄漏

對於使用了BraodcastReceiver，ContentObserver，File，Cursor，Stream，Bitmap等資源，應該在Activity銷毀時及時關閉或者註銷，否則這些資源將不會被回收，從而造成內存泄漏。

1）比如在Activity中register了一個BraodcastReceiver，但在Activity結束後沒有unregister該BraodcastReceiver。

2）資源性對象比如Cursor，Stream、File文件等往往都用了一些緩衝，我們在不使用的時候，應該及時關閉它們，以便它們的緩衝及時回收內存。它們的緩衝不僅存在於 java虛擬機內，還存在於java虛擬機外。如果我們僅僅是把它的引用設置為null，而不關閉它們，往往會造成內存泄漏。

3）對於資源性對象在不使用的時候，應該調用它的close()函數將其關閉掉，然後再設置為null。在我們的程序退出時一定要確保我們的資源性對象已經關閉。

4）Bitmap對象不在使用時調用recycle()釋放內存。2.3以後的bitmap應該是不需要手動recycle了，內存已經在java層了。

6、使用ListView時造成的內存泄漏

初始時ListView會從BaseAdapter中根據當前的屏幕布局實例化一定數量的View對象，同時ListView會將這些View對象緩存起來。當向上滾動ListView時，原先位於最上面的Item的View對象會被回收，然後被用來構造新出現在下面的Item。這個構造過程就是由getView()方法完成的，getView()的第二個形參convertView就是被緩存起來的Item的View對象（初始化時緩存中沒有View對象則convertView是null）。

構造Adapter時，沒有使用緩存的convertView。

解決方法：在構造Adapter時，使用緩存的convertView。

7、集合容器中的內存泄露

我們通常把一些對象的引用加入到了集合容器（比如ArrayList）中，當我們不需要該對象時，並沒有把它的引用從集合中清理掉，這樣這個集合就會越來越大。如果這個集合是static的話，那情況就更嚴重了。

解決方法：在退出程序之前，將集合里的東西clear，然後置為null，再退出程序。

8、WebView造成的泄露

當我們不要使用WebView對象時，應該調用它的destory()函數來銷毀它，並釋放其佔用的內存，否則其長期佔用的內存也不能被回收，從而造成內存泄露。

解決方法：為WebView另外開啟一個進程，通過AIDL與主線程進行通信，WebView所在的進程可以根據業務的需要選擇合適的時機進行銷毀，從而達到內存的完整釋放。

如何避免內存泄漏？

1、在涉及使用Context時，對於生命周期比Activity長的對象應該使用Application的Context。凡是使用Context優先考慮Application的Context，當然它並不是萬能的，對於有些地方則必須使用Activity的Context。對於Application，Service，Activity三者的Context的應用場景如下：

其中，NO1表示Application和Service可以啟動一個Activity，不過需要創建一個新的task任務隊列。而對於Dialog而言，只有在Activity中才能創建。除此之外三者都可以使用。

2、對於需要在靜態內部類中使用非靜態外部成員變數（如：Context、View )，可以在靜態內部類中使用弱引用來引用外部類的變數來避免內存泄漏。

3、對於不再需要使用的對象，顯示的將其賦值為null，比如使用完Bitmap後先調用recycle()，再賦為null。

4、保持對對象生命周期的敏感，特別注意單例、靜態對象、全局性集合等的生命周期。

5、對於生命周期比Activity長的內部類對象，並且內部類中使用了外部類的成員變數，可以這樣做避免內存泄漏：

1）將內部類改為靜態內部類

2）靜態內部類中使用弱引用來引用外部類的成員變數

Python的垃圾回收機制原理

1.Python的垃圾回收機制原理

Python無需我們手動回收內存，它的垃圾回收是如何實現的呢？

引用計數為主（缺點：循環引用無法解決）

引入標記清除和分代回收解決引用計數問題

引用計數為主+標記清除和分代回收為輔

垃圾回收（GC）

（1）引用計數

a = [1] # [1]對象引用計數增加1，ref=1

b = a # [1]對象引用計數增加1，ref=2

b = None # [1]對象引用計數減少1，ref=1

del a # [1]對象引用計數減少1，ref=0

a = [1],當把列表 [1] 賦值給 a 的時候，它的引用計數就會增加1，此時列表 [1] 對象的引用計數ref=1 ； b = a 又把 a 賦值給 b ，a和b 同時引用了列表[1]對象，ref又增加1，此時 ref =2。繼續執行 b = None， 讓b指向None，這個時候它就不會指向原來的列表[1]對象，列表[1]對象的引入計數就會減少1，又變成ref=1。執行del a ，引用計數就會減少1，這個時候 ref = 0。當對象的引用計數為0就可以回收掉，

注意：del 作用就會減少對象引用計數，並不是銷毀對象。只有當引用計數為0的時候，Python解釋器才回去把對象佔用的內存回收掉。

// object.h

struct _object {

Py_ssize_t ob_refcnt; # 引用計數值

}PyObject;

① 什麼時候引用計數增加呢？

② 什麼時候引用計數會減少呢？

（2）引用計數無法解決循環引用問題

循環引用

a = [1] # 對象[1]引用計數增加1，ref=1

b = [2] # 對象[2]引用計數增加1，ref=1

a.append(b) # b被a引用，對象[2]引用計數增加1，ref=2

b.append(a) # a又被b引用，對象[1]引用計數增加1，ref=2

del a # 對象[1]引用計數減少1，ref=1

del b # 對象[2]引用計數減少1，ref=1

（3）標記清除（Mark and Sweep）

（4）分代回收

import gc