在上篇博客中，提到了對一個腳本進行的多次優化。當時以為已經優化得差不多了，但是當測試人員測試時，我才發現，踩到了Python的一個大坑。

在上文的優化中，對每500個用戶，會進行一些計算并記錄結果在磁盤文件中。原本以為這么做，這些結果就在磁盤文件中了，而不會再繼續占用內存；但實際上，Python的大坑就是Python不會自動清理這些內存。這是由其本身實現決定的。具體原因網上多有文章介紹，這里就不copy了。

本篇博客將貼一個筆者的實驗腳本，用以說明Python確實存在這么一個不釋放內存的現象，另外也提出一個解決方案，即：先del，再顯式調用gc.collect(). 腳本和具體效果見下。

實驗環境一：Win 7， Python 2.7

from time import sleep, time

import gc

def mem(way=1):

print time()

for i in range(10000000):

if way == 1:

pass

else: # way 2, 3

del i

print time()

if way == 1 or way == 2:

pass

else: # way 3

gc.collect()

print time()

if __name__ == "__main__":

print "Test way 1: just pass"

mem(way=1)

sleep(20)

print "Test way 2: just del"

mem(way=2)

sleep(20)

print "Test way 3: del, and then gc.collect()"

mem(way=3)

sleep(20)

運行結果如下：

Test way 1: just pass

1426688589.47

1426688590.25

1426688590.25

Test way 2: just del

1426688610.25

1426688611.05

1426688611.05

Test way 3: del, and then gc.collect()

1426688631.05

1426688631.85

1426688631.95

對于way 1和way 2，結果是完全一樣的，程序內存消耗峰值是326772KB，在sleep 20秒時，內存實時消耗是244820KB；

對于way 3，程序內存消耗峰值同上，但是sleep時內存實時消耗就只有6336KB了。

實驗環境二： Ubuntu 14.10， Python 2.7.3

運行結果：

Test way 1: just pass

1426689577.46

1426689579.41

1426689579.41

Test way 2: just del

1426689599.43

1426689601.1

1426689601.1

Test way 3: del, and then gc.collect()

1426689621.12

1426689622.8

1426689623.11

ubuntu@my_machine:~$ ps -aux | grep test_mem

Warning: bad ps syntax, perhaps a bogus '-'? See http://procps.sf.net/faq.html

ubuntu 9122 10.0 6.0 270916 245564 pts/1 S+ 14:39 0:03 python test_mem.py

ubuntu 9134 0.0 0.0 8104 924 pts/2 S+ 14:40 0:00 grep --color=auto test_mem

ubuntu@my_machine:~$ ps -aux | grep test_mem

Warning: bad ps syntax, perhaps a bogus '-'? See http://procps.sf.net/faq.html

ubuntu 9122 10.0 6.0 270916 245564 pts/1 S+ 14:39 0:03 python test_mem.py

ubuntu 9134 0.0 0.0 8104 924 pts/2 S+ 14:40 0:00 grep --color=auto test_mem

ubuntu@my_machine:~$ ps -aux | grep test_mem

Warning: bad ps syntax, perhaps a bogus '-'? See http://procps.sf.net/faq.html

ubuntu 9122 11.6 0.1 30956 5608 pts/1 S+ 14:39 0:05 python test_mem.py

結論：

以上說明，當調用del時，其實Python并不會真正release內存，而是將其繼續放在其內存池中；只有在顯式調用gc.collect()時，才會真正release內存。

進一步：

其實回到上一篇博客的腳本中，也讓其引入gc.collect()，然后寫個監控腳本監測內存消耗情況：

while ((1)); do ps -aux | sort -n -k5,6 | grep my_script; free; sleep 5; done

結果發現：內存并不會在每500個用戶一組執行完后恢復，而是一直持續消耗到僅存約70MB時，gc才好像起作用。本環境中，機器使用的是Cloud instance，總內存2G，可用內存約為1G，本腳本內存常用消耗是900M - 1G。換句話說，對于這個腳本來說，gc并沒有立即起作用，而是在系統可用內存從1 - 1.2G下降到只剩70M左右時，gc才開始發揮作用。這點確實比較奇怪，不知道和該腳本是在Thread中使用的gc.collect()是否有關，或者是gc發揮作用原本就不是可控的。筆者尚未做相關實驗，可能在下篇博客中繼續探討。

但是，可以肯定的是，若不使用gc.collect(), 原腳本將會將系統內存耗盡而被殺死。這一點從syslog中可以明顯看出。

以上就是本文的全部內容，希望對大家的學習有所幫助，也希望大家多多支持找一找教程網。

總結

以上是生活随笔為你收集整理的python手动回收内存哪家好_谈谈如何手动释放Python的内存的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。