垃圾回收:用通俗的语言解释内存管理和垃圾回收的过程
在Python的C源码中有一个名为refchain的环状双向链表
,这个链表比较牛逼了,因为Python程序中一旦创建对象都会把这个对象添加到refchain这个链表中。也就是说他保存着所有的对象。例如:
age = 18
hobby = "python"
在refchain中的所有对象内部都有一个ob_refcnt
用来保存当前对象的引用计数器,顾名思义就是自己被引用的次数,例如:
age = 18
hobby = 'python'
hobby_1 = hobby
上述代码表示内存中有 18 和 “python” 两个值,他们的引用计数器分别为:1、2 。
当值被多次引用时候,不会在内存中重复创建数据,而是引用计数器+1
。 当对象被销毁时候同时会让引用计数器-1
,如果引用计数器为0,则将对象从refchain链表中摘除,同时在内存中进行销毁(暂不考虑缓存等特殊情况)。
age = 18
number = age #对象18的引用计数器 + 1
del age #对象18的引用计数器 - 1
def run(arg):
print(arg)
run(number) #刚开始执行函数时,对象18引用计数器 + 1,当函数执行完毕之后,对象18引用计数器 - 1 。
num_list = [11,22,number] #对象18的引用计数器 + 1
当发生以下四种情况的时候,该对象的引用计数器+1
与上述情况相对应,当发生以下四种情况时,该对象的引用计数器-1
当指向该对象的内存的引用计数器为0的时候,该内存将会被Python虚拟机销毁
基于引用计数器进行垃圾回收非常方便和简单,但他还是存在循环引用
的问题,导致无法正常的回收一些数据,例如:
v1 = [11,22,33] #refchain中创建一个列表对象,由于v1=对象,所以列表引对象用计数器为1.
v2 = [44,55,66] #refchain中再创建一个列表对象,因v2=对象,所以列表对象引用计数器为1.
v1.append(v2) #把v2追加到v1中,则v2对应的[44,55,66]对象的引用计数器加1,最终为2.
v2.append(v1) #把v1追加到v1中,则v1对应的[11,22,33]对象的引用计数器加1,最终为2.
del v1 #引用计数器-1
del v2 #引用计数器-1
对于上述代码会发现,执行del
操作之后,没有变量再会去使用那两个列表对象,但由于循环引用的问题,他们的引用计数器不为0,所以他们的状态:永远不会被使用、也不会被销毁。项目中如果这种代码太多,就会导致内存一直被消耗,直到内存被耗尽,程序崩溃。
为了解决循环引用的问题,引入了标记清除
技术,专门针对那些可能存在循环引用的对象进行特殊处理,可能存在循环应用的类型有:列表、元组、字典、集合、自定义类等那些能进行数据嵌套的类型。
标记清除:创建特殊链表专门用于保存 列表、元组、字典、集合、自定义类等对象,之后再去检查这个链表中的对象是否存在循环引用,如果存在则让双方的引用计数器均 - 1 。
分代回收:对标记清除中的链表进行优化,将那些可能存在循引用的对象拆分到3个链表,链表称为:0/1/2三代,每代都可以存储对象和阈值,当达到阈值时,就会对相应的链表中的每个对象做一次扫描,除循环引用各自减1并且销毁引用计数器为0的对象。
// 分代的C源码
#define NUM_GENERATIONS 3
struct gc_generation generations[NUM_GENERATIONS] = {
/* PyGC_Head, threshold, count */
{{(uintptr_t)_GEN_HEAD(0), (uintptr_t)_GEN_HEAD(0)}, 700, 0}, // 0代
{{(uintptr_t)_GEN_HEAD(1), (uintptr_t)_GEN_HEAD(1)}, 10, 0}, // 1代
{{(uintptr_t)_GEN_HEAD(2), (uintptr_t)_GEN_HEAD(2)}, 10, 0}, // 2代
};
特别注意:0代和1、2代的threshold和count表示的意义不同。
根据C语言底层并结合图来讲解内存管理和垃圾回收的详细过程。
第一步:当创建对象age=19
时,会将对象添加到refchain链表中。
第二步:当创建对象num_list = [11,22]
时,会将列表对象添加到 refchain 和 generations 0代中。
第三步:新创建对象使generations的0代链表上的对象数量大于阈值700时,要对链表上的对象进行扫描检查。
当0代大于阈值后,底层不是直接扫描0代,而是先判断2、1是否也超过了阈值。
对拼接起来的链表在进行扫描时,主要就是剔除循环引用和销毁垃圾,详细过程为:
gc_refs
中,保护原引用计数器。gc_refs
减 1 。gc_refs
为 0 的对象移动到unreachable
链表中;不为0的对象直接升级到下一代链表中。unreachable
链表中的对象的 析构函数 和 弱引用,不能被销毁的对象升级到下一代链表,能销毁的保留在此链表。
__del__
方法的对象,需要执行之后再进行销毁处理。unreachable
中的每个对象销毁并在refchain链表中移除(不考虑缓存机制)。至此,垃圾回收的过程结束。
从上文大家可以了解到当对象的引用计数器为0时,就会被销毁并释放内存。而实际上他不是这么的简单粗暴,因为反复的创建和销毁会使程序的执行效率变低。Python中引入了“缓存机制”机制。
例如:引用计数器为0时,不会真正销毁对象,而是将他放到一个名为 free_list
的链表中,之后会再创建对象时不会在重新开辟内存,而是在free_list中将之前的对象来并重置内部的值来使用。
float类型,维护的free_list链表最多可缓存100个float对象。
v1 = 3.14 # 开辟内存来存储float对象,并将对象添加到refchain链表。
print( id(v1) ) # 内存地址:4436033488
del v1 # 引用计数器-1,如果为0则在rechain链表中移除,不销毁对象,而是将对象添加到float的free_list.
v2 = 9.999 # 优先去free_list中获取对象,并重置为9.999,如果free_list为空才重新开辟内存。
print( id(v2) ) # 内存地址:4436033488
# 注意:引用计数器为0时,会先判断free_list中缓存个数是否满了,未满则将对象缓存,已满则直接将对象销毁。
int类型,不是基于free_list,而是维护一个small_ints链表保存常见数据(小数据池),小数据池范围:-5 <= value < 257
。即:重复使用这个范围的整数时,不会重新开辟内存。
v1 = 38 # 去小数据池small_ints中获取38整数对象,将对象添加到refchain并让引用计数器+1。
print( id(v1)) #内存地址:4514343712
v2 = 38 # 去小数据池small_ints中获取38整数对象,将refchain中的对象的引用计数器+1。
print( id(v2) ) #内存地址:4514343712
# 注意:在解释器启动时候-5~256就已经被加入到small_ints链表中且引用计数器初始化为1,代码中使用的值时直接去small_ints中拿来用并将引用计数器+1即可。另外,small_ints中的数据引用计数器永远不会为0(初始化时就设置为1了),所以也不会被销毁。
str类型,维护unicode_latin1[256]
链表,内部将所有的ascii字符
缓存起来,以后使用时就不再反复创建。
v1 = "A"
print( id(v1) ) # 输出:4517720496
del v1
v2 = "A"
print( id(v1) ) # 输出:4517720496
# 除此之外,Python内部还对字符串做了驻留机制,针对那么只含有字母、数字、下划线的字符串(见源码Objects/codeobject.c),如果内存中已存在则不会重新在创建而是使用原来的地址里(不会像free_list那样一直在内存存活,只有内存中有才能被重复利用)。
v1 = "wupeiqi"
v2 = "wupeiqi"
print(id(v1) == id(v2)) # 输出:True
v1 = [11,22,33]
print( id(v1) ) # 输出:4517628816
del v1
v2 = ["武","沛齐"]
print( id(v2) ) # 输出:4517628816
v1 = (1,2)
print( id(v1) )
del v1 # 因元组的数量为2,所以会把这个对象缓存到free_list[2]的链表中。
v2 = ("武沛齐","Alex") # 不会重新开辟内存,而是去free_list[2]对应的链表中拿到一个对象来使用。
print( id(v2) )
v1 = {"k1":123}
print( id(v1) ) # 输出:4515998128
del v1
v2 = {"name":"武沛齐","age":18,"gender":"男"}
print( id(v1) ) # 输出:4515998128
转载https://pythonav.com/wiki/detail/6/88/#2.8%20dict%E7%B1%BB%E5%9E%8B
https://www.cnblogs.com/wupeiqi/articles/11507404.html