在上文的优化中，对每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.11ubuntu@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的内存的方法的详细内容，更多请关注 第一php社区 其它相关文章！