gccollectpython

⑴ python如何让程序一直运行且内存资源自动释放

这当然是和代码写法有关，不贴出来就无法解决

⑵ python的内存管理机制

论坛

活动

招聘

专题

打开CSDN APP
Copyright © 1999-2020, CSDN.NET, All Rights Reserved

登录

XCCS_澍
关注
Python 的内存管理机制及调优手段？ 原创
2018-08-05 06:50:53

XCCS_澍

码龄7年

关注
内存管理机制：引用计数、垃圾回收、内存池。
一、引用计数：
    引用计数是一种非常高效的内存管理手段， 当一个 Python 对象被引用时其引用计数增加 1， 当其不再被一个变量引用时则计数减 1. 当引用计数等于 0 时对象被删除。
二、垃圾回收 ：
1. 引用计数
      引用计数也是一种垃圾收集机制，而且也是一种最直观，最简单的垃圾收集技术。当 Python 的某个对象的引用计数降为 0 时，说明没有任何引用指向该对象，该对象就成为要被回收的垃圾了。比如某个新建对象，它被分配给某个引用，对象的引用计数变为 1。如果引用被删除，对象的引用计数为 0，那么该对象就可以被垃圾回收。不过如果出现循环引用的话，引用计数机制就不再起有效的作用了
2. 标记清除
     如果两个对象的引用计数都为 1，但是仅仅存在他们之间的循环引用，那么这两个对象都是需要被回收的，也就是说，它们的引用计数虽然表现为非 0，但实际上有效的引用计数为 0。所以先将循环引用摘掉，就会得出这两个对象的有效计数。
3. 分代回收
     从前面“标记-清除”这样的垃圾收集机制来看，这种垃圾收集机制所带来的额外操作实际上与系统中总的内存块的数量是相关的，当需要回收的内存块越多时，垃圾检测带来的额外操作就越多，而垃圾回收带来的额外操作就越少；反之，当需回收的内存块越少时，垃圾检测就将比垃圾回收带来更少的额外操作。

⑶ 如何释放Python占用的内存

在上文的优化中，对每500个用户，会进行一些计算并记录结果在磁盘文件中。原本以为这么做，这些结果就在磁盘文件中了，而不会再继续占用内存；但实际上，python的大坑就是Python不会自动清理这些内存。这是由其本身实现决定的。具体原因网上多有文章介绍，这里就不了。
本篇博客将贴一个笔者的实验脚本，用以说明Python确实存在这么一个不释放内存的现象，另外也提出一个解决方案，即：先del，再显式调用gc.collect(). 脚本和具体效果见下。

实验环境一：Win 7， Python 2.7

[python] view plain
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)

运行结果如下：

[plain] view plain
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

运行结果：

[plain] view plain
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

[plain] view plain
ubuntu@my_machine:~$ ps -aux | grep test_mem
Warning: bad ps syntax, perhaps a bogus '-'? See
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
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
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()，然后写个监控脚本监测内存消耗情况：

[plain] view plain
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的内存

象的引用计数减少；

函数运行结束，所有局部变量都被销毁，对象的引用计数也就随之减少。例如 foo(x) 运行结束，x 被销毁；
当变量被赋值给另一个对象时，原对象的引用计数也会减少。例如 x = 4，这时候 3 这个对象的引用计数就减 1 了；

使用 del 删除一个变量也会导致对象引用减少。例如 del x；

对象从集合对象中移除。例如 lst.remove(x)；

包含对象的集合对象被销毁。例如 del lst；
这些操作都可能使对象变成垃圾回收对象，由垃圾收集器负责收集，当然垃圾收集器也负责处理循环引用对象。
要立即释放，可以使用下面的代码
import gc
gc.collect()