Python中的内存管理

jopen 10年前

引用计数和垃圾回收机制:http://www.cnblogs.com/vamei/p/3232088.html

内存池机制:http://developer.51cto.com/art/201007/213585.htm

python的内存管理机制主要包括引用计数机制、垃圾回收机制、内存池机制。

引用计数机制:

    对于常见的赋值语句,如a=1。整数1为对象,而a是一个引用。利用赋值语句,引用a指向对象1.可以使用内置函数id()返回对象的内存地址。在 python中,整数和短小的字符,python都会缓存这些对象,以便重复使用。长的字符串和其他对象可以有多个相同的对象,可以使用赋值语句创建出新的对象。当我们创建多个等于1的引用时,实际上是让所有这些引用指向同一个对象。为了检验两个引用指向同一个对象,我们可以用is关键字。is用于判断两个引用所指向的对象是否相同。

    在python中,每个对象都有存有指向该对象的引用总数,及引用计数。我们可以使用sys包中的getrefcount()来查看某个对象的引用计数。需要注意的是,当使用某个引用作为参数传递给getrefcount()时,参数实际上创建了一个临时的引用。因此,getrefcount()所得到的结果,会比期望的多1.

    python的一个容器对象,比如列表,词典等,可以包括多个对象。实际上,容器对象中包含的并不是元素对象本身,是指向各个元素对象的引用。

    某个对象的引用计数可能减少。比如,可以使用del关键字删除某个引用:>>>a=[1,2,3]  >>>b=a   >>>del a

del也可以用于删除容器元素中的元素,比如:del a[0]

    如果某个引用指向对象A,当这个引用被重新定向到某个其他对象B时,对象A的引用计数减少:

    >>>a=[1,2,3]    >>>b=a     >>>sys.getrefcount(b)   >>>a=1     >>>getrefcount(b)


垃圾回收机制:

   当python中的对象越来越多,它们将占据越来越大的内存,python会启动垃圾回收机制。从基本原理上,当python的某个对象的引用计数降为0时,说明没有任何引用指向该对象,该对象就成为要被回收的垃圾了。例如:

>>>a=[1,2,3]

>>>del a

del a后,已经没有任何引用指向之前建立的[1,2,3]这个表。用户不可能通过任何方式接触或者动用这个对象。当垃圾回收启动时,python扫描到这个引用计数为0的对象,就将它所占据的内存清空。

    垃圾回收时,Python不能进行其它的任务。频繁的垃圾回收将大大降低Python的工作效率。如果内存中的对象不多,就没有必要总启动垃圾回收。所以,Python只会在特定条件下,自动启动垃圾回收。当Python运行时,会记录其中分配对象(object allocation)和取消分配对象(object deallocation)的次数。当两者的差值高于某个阈值时,垃圾回收才会启动。

    我们可以通过gc模块的get_threshold()方法,查看该阈值:

import gc  print(gc.get_threshold())

返回(700, 10, 10),后面的两个10是与分代回收相关的阈值,后面可以看到。700即是垃圾回收启动的阈值。可以通过gc中的set_threshold()方法重新设置。我们也可以手动启动垃圾回收,即使用gc.collect()

Python同时采用了分代(generation) 回收的策略。这一策略的基本假设是,存活时间越久的对象,越不可能在后面的程序中变成垃圾。我们的程序往往会产生大量的对象,许多对象很快产生和消失,但也有一些对象长期被使用。出于信任和效率,对于这样一些“长寿”对象,我们相信它们的用处,所以减少在垃圾回收中扫描它们的频率。

Python将所有的对象分为0,1,2三代。所有的新建对象都是0代对象。当某一代对象经历过垃圾回收,依然存活,那么它就被归入下一代对象。垃圾回收启动时,一定会扫描所有的0代对象。如果0代经过一定次数垃圾回收,那么就启动对0代和1代的扫描清理。当1代也经历了一定次数的垃圾回收后,那么会启动对0,1,2,即对所有对象进行扫描。

这两个次数即上面get_threshold()返回的(700, 10, 10)返回的两个10。也就是说,每10次0代垃圾回收,会配合1次1代的垃圾回收;而每10次1代的垃圾回收,才会有1次的2代垃圾回收。

同样可以用set_threshold()来调整,比如对2代对象进行更频繁的扫描。

import gc  gc.set_threshold(700, 10, 5)

孤立的引用环:

引用环的存在会给上面的垃圾回收机制带来很大的困难。这些引用环可能构成无法使用,但引用计数不为0的一些对象。为了回收这样的引用环,Python复制每个对象的引用计数,可以记为gc_ref。假设,每个对象i,该计数为gc_ref_i。Python会遍历所有的对象i。对于每个对象i引用的对象j,将相应的gc_ref_j减1。在结束遍历后,gc_ref不为0的对象,和这些对象引用的对象,以及继续更下游引用的对象,需要被保留。而其它的对象则被垃圾回收。

内存池机制:

在Python中,许多时候申请的内存都是小块的内存,这些小块内存在申请后,很快又会被释放,由于这些内存的申请并不是为了创建对象,所以并没有对象一级的内存池机制。

这就意味着Python在运行期间会大量地执行malloc和free的操作,频繁地在用户态和核心态之间进行切换,这将严重影响Python的执行效率。为了加速Python的执行效率,Python引入了一个内存池机制,用于管理对小块内存的申请和释放。这也就是之前提到的Pymalloc机制。

在Python 2.5中,Python内部默认的小块内存与大块内存的分界点定在256个字节,这个分界点由前面我们看到的名为SMALL_REQUEST_THRESHOLD的符号控制。

也就是说,当申请的内存小于256字节时,PyObject_Malloc会在内存池中申请内存;当申请的内存大于256字节时,PyObject_Malloc的行为将蜕化为malloc的行为。当然,通过修改Python源代码,我们可以改变这个默认值,从而改变 Python的默认内存管理行为。

在一个对象的引用计数减为0时,与该对象对应的析构函数就会被调用。

但是要特别注意的是,调用析构函数并不意味着最终一定会调用free释放内存空间,如果真是这样的话,那频繁地申请、释放内存空间会使 Python的执行效率大打折扣(更何况Python已经多年背负了人们对其执行效率的不满)。一般来说,Python中大量采用了内存对象池的技术,使用这种技术可以避免频繁地申请和释放内存空间。因此在析构时,通常都是将对象占用的空间归还到内存池中。

" 这个问题就是:Python的arena从来不释放pool。这个问题为什么会引起类似于内存泄漏的现象呢。考虑这样一种情形,申请 10*1024*1024个16字节的小内存,这就意味着必须使用160M的内存,由于Python没有默认将前面提到的限制内存池的 WITH_MEMORY_LIMITS编译符号打开,所以Python会完全使用arena来满足你的需求,这都没有问题,关键的问题在于过了一段时间,你将所有这些16字节的内存都释放了,这些内存都回到arena的控制中,似乎没有问题。

但是问题恰恰就在这时出现了。因为arena始终不会释放它维护的pool集合,所以这160M的内存始终被Python占用,如果以后程序运行中再也不需要160M如此巨大的内存,这点内存岂不是就浪费了?"

Python内存管理规则:del的时候,把list的元素释放掉,把管理元素的大对象回收到py对象缓冲池里。