[python]--垃圾回收机制

Posted 2020-09-08

　　转自http://www.cnblogs.com/kaituorensheng/p/4449457.html

　　在python中,为了解决内存泄漏的问题,采用了对象引用计数,并基于引用计数实现自动垃圾回收.

　　内存泄漏:也称作"存储渗漏".用动态 存储分配函数动态开辟的空间,在使用完毕后未释放,结果导致一直占据该内存单元,直到程序结束.

　　内存泄漏形象的比喻是"操作系统可提供给所有进程的存储空间正在被某个进程榨干",最终结果是程序运行时间越长,占用存储空间越来越多,最终用尽全部存储空间,整个系统崩溃.所以"内存泄漏"是从操作系统的角度来看的.这里的存储空间并不是指物理内存,而是指虚拟内存大小,这个虚拟内存大小取决于磁盘交换区设定的大小,由程序申请的一块内存,如果没有任何一个指针指向它,那么这块内存就泄漏了.

　　内存泄漏分类:

　　　  常发性:

　　　　　　发生内存泄漏的代码会被多次执行到,每次被执行的时候都会导致一块内存泄漏.

　　　　偶发性:

　　　　　　发生内存泄漏的代码只有在某些特定环境或操作过程下才会发生.常发性和偶发性是相对的.对于特定的环境,偶发性的也许就变成常发性的.所以测试环境和测试方法对检测内存泄漏至关重要.

　　　　一次性:

　　　　　　发生内存泄漏的代码只会被执行一次,或者由于算法上的缺陷,导致总会有一块且仅一块内存发生泄漏.比如,在类的构造函数中分配内存,在析构函数中却没有释放该内存,所以内存泄漏只会发生一次.

　　　　隐式:

　　　　　　程序在运行过程中不停的分配内存,但是直到结束的时候才释放内存.严格的说这里并没有发生内存泄漏,因为最终程序释放了所有申请的内存.但是对于一个服务器程序,需要运行几天,几周甚至几个月,不及时释放内存也可能导致最终耗尽系统的所有内存.所以,我们称这类内存泄漏为隐式内存泄漏.

　　　　表现:

　　　　　　内存泄漏或者是说,资源耗尽后,系统会表现出什么现象呢?

　　　　　　cpu资源耗尽:估计是机器没有反应了,键盘,鼠标,以及网络等等.在中了计算机病毒的设备上非常常见.

　　　　　　进程id耗尽:没法创建新的进程了,串口或者telnet都没法创建了.

　　　　　　硬盘耗尽:机器要死了,交换内存没法用,日志也没法用了.

　　　　　　内存泄漏或者内存耗尽:新的连接无法创建,free的内存比较少,发生内存泄漏的程序很多,但是要想产生一定的后果,就需要这个进程是无限循环的,是个服务进程.当然,内核也是无限循环的,所以,如果内核发生了内存泄漏,情况就更加不妙.内存泄漏是一种很难定位和跟踪的错误,目前还没看到有什么好用的工具(当然,用户空间有一些工具,有静态分析的,也会动态分析的,但是找内核的内存泄漏,没有好的开源工具).

　　　　　　　　　由于Python有了自动垃圾回收功能,就造成了不少初学者误认为不必再受内存泄漏的骚扰了.但如果仔细查看一下Python文档对__del__()函数的描述,就知道这种好日子里也是有阴云的.

　　　　有__del__()函数的对象间的循环引用是导致内存泄漏的主凶.但没有__del__()函数的对象间的循环引用是可以被垃圾回收器回收掉的.

　　　　Python的扩展模块gc可以查看不能回收掉的对象的详细信息.

例子:没有出现内存泄漏的　　　

import gc 
import sys
class CGcLeak(object):
    def __init__(self):
        self._text = ‘#‘ * 10

    def __del__(self):
        pass
def make_circle_ref():
    _gcleak = CGcLeak()
    print "_gcleak ref count0: %d" %(sys.getrefcount(_gcleak))
    del _gcleak
    try:
        print "_gcleak ref count1 :%d" %(sys.getrefcount(_gcleak))
    except UnboundLocalError:           # 本地变量xxx引用前没定义
        print "_gcleak is invalid!"
def test_gcleak():
    gc.enable()                         #设置垃圾回收器调试标志
    gc.set_debug(gc.DEBUG_COLLECTABLE | gc.DEBUG_UNCOLLECTABLE | gc.DEBUG_INSTANCES | gc.DEBUG_OBJECTS)

    print "begin leak test..."
    make_circle_ref()

    print "\\nbegin collect..."
    _unreachable = gc.collect()
    print "unreachable object num:%d" %(_unreachable)
    print "garbage object num:%d" %(len(gc.garbage))   #gc.garbage是一个list对象，列表项是垃圾收集器发现的不可达（即垃圾对象）、但又不能释放(不可回收)的对象，通常gc.garbage中的对象是引用对象还中的对象。因Python不知用什么顺序来调用对象的__del__函数，导致对象始终存活在gc.garbage中，造成内存泄露 if __name__ == "__main__": test_gcleak()。如果知道一个安全次序，那么就可以打破引用焕，再执行del gc.garbage[:]从而清空垃圾对象列表
if __name__ == "__main__":
    test_gcleak()

begin leak test...
_gcleak ref count0: 2         #对象_gcleak的引用计数为2
_gcleak is invalid!           #因为执行了del函数，_gcleak变为了不可达的对象

begin collect...              #开始垃圾回收
unreachable object num:0      #本次垃圾回收发现的不可达的对象个数为0
garbage object num:0          #整个解释器中垃圾对象的个数为0

结果

例2：对自己的循环引用造成内存泄露

import gc
import sys

class CGcLeak(object):
    def __init__(self):
        self._text = ‘#‘ * 10

    def __del__(self):
        pass

def make_circle_ref():
    _gcleak = CGcLeak()
    _gcleak._self = _gcleak     #自己循环引用自己
    print "_gcleak ref count0: %d" %(sys.getrefcount(_gcleak))
    del _gcleak
    try:
        print "_gcleak ref count1 :%d" %(sys.getrefcount(_gcleak))
    except UnboundLocalError:
        print "_gcleak is invalid!"

def test_gcleak():
    gc.enable()
    gc.set_debug(gc.DEBUG_COLLECTABLE | gc.DEBUG_UNCOLLECTABLE | gc.DEBUG_INSTANCES | gc.DEBUG_OBJECTS)

    print "begin leak test..."
    make_circle_ref()

    print "\\nbegin collect..."
    _unreachable = gc.collect()
    print "unreachable object num:%d" %(_unreachable)
    print "garbage object num:%d" %(len(gc.garbage))

if __name__ == "__main__":
    test_gcleak()

View Code

begin leak test...
gc: uncollectable <CGcLeak 00000000026366A0>
_gcleak ref count0: 3
_gcleak is invalid!
gc: uncollectable <dict 0000000002667BD8>

begin collect...
unreachable object num:2       #本次回收不可达的对象个数为2
garbage object num:1           #整个解释器中垃圾个数为1

结果

例3：多个对象间的循环引用造成内存泄露

import gc
import sys

class CGcLeakA(object):
    def __init__(self):
        self._text = ‘$‘ * 10

    def __del__(self):
        pass

class CGcLeakB(object):
    def __init__(self):
        self._text = ‘$‘ * 10

    def __del__(self):
        pass

def make_circle_ref():
    _a = CGcLeakA()
    _b = CGcLeakB()
    _a.s = _b
    _b.d = _a
    print "ref count0:a=%d b=%d" %(sys.getrefcount(_a), sys.getrefcount(_b))
    del _a
    del _b
    try:
        print "ref count1:a%d" %(sys.getrefcount(_a))
    except UnboundLocalError:
        print "_a is invalid!"

def test_gcleak():
    gc.enable()
    gc.set_debug(gc.DEBUG_COLLECTABLE | gc.DEBUG_UNCOLLECTABLE | gc.DEBUG_INSTANCES | gc.DEBUG_OBJECTS)

    print "begin leak test..."
    make_circle_ref()

    print "\\nbegin collect..."
    _unreachable = gc.collect()
    print "unreachable object num:%d" %(_unreachable)
    print "garbage object num:%d" %(len(gc.garbage))

if __name__ == "__main__":
    test_gcleak()

View Code

begin leak test...
ref count0:a=3 b=3
_a is invalid!
 
begin collect...
unreachable object num:4
garbage object num:2
gc: uncollectable <CGcLeakA 00000000022766D8>
gc: uncollectable <CGcLeakB 0000000002276710>
gc: uncollectable <dict 00000000022A7E18>
gc: uncollectable <dict 00000000022DF3C8>

结果

结论:

　　Python 的 gc 有比较强的功能，比如设置 gc.set_debug(gc.DEBUG_LEAK) 就可以进行循环引用导致的内存泄露的检查。如果在开发时进行内存泄露检查；在发布时能够确保不会内存泄露，那么就可以延长 Python 的垃圾回收时间间隔、甚至主动关闭垃圾回收机制，从而提高运行效率。