实验中遇到了Python内存泄漏的问题,网上找了一些资源对Python 的内存管理机制和内存优化进行了学习,先把内存管理机制进行了总结,内容很多是参考和复制参考文献中的内容。
1、变量与对象关系
在Python中,变量不同于C语言中的变量机制,对C语言来说,我们创建一个变量A时就会为为该变量申请一个内存空间,并将变量值 放入该空间中,当将该变量赋给另一变量B时会为B也申请一个新的内存空间,并将变量值放入到B的内存空间中,所以A和B的指针不一致,下图:
但是在Python中,变量是附在对象上的标签。当变量被绑定在一个对象上的时候,该变量的引用计数就是1。
在Python中变量通过变量指针引用对象,变量指针指向具体对象的内存空间,取对象的值。而对象,类型已知,每个对象都包含一个头部信息(头部信息:类型标识符和引用计数器)。变量单独来说只是一个符号或标签,没有太多的意义,当它绑定到对象上时,才会有具体作用,变量引用什么类型的对象,变量就是什么类型的。
一些需要注意的细节
- 当一个变量“引用”另一个变量时,两个变量所指的对象是一个地址和数值。
>>> var1 = 123
>>> var2 = var1
>>> id(var1)
1749839904
>>> id(var2)
1749839904
- 当一个变量var4“引用”另一个变量var3,var3赋予新的对象时,var3的id改变,var4任然不变。并且对比上图代码,我们可以知道对于某些类型对象,其在Python中的地址是不变的,比如123,数值型变量引用时其id地址就是1749839904,有兴趣的可以试试将123当做列表等类型,查看其Id有什么变化。
>>> var3 = 123
>>> var4 = var3
>>> id(var3)
1749839904
>>> id(var4)
1749839904
>>> var3 = 456
>>> id(var3)
48910864
>>> id(var4)
1749839904
- 通过is进行引用所指判断,is是用来判断两个引用所指的对象是否相同。
- Python缓存了整数和短字符串,每个对象在内存中只存有一份,引用所指对象就是相同的,即使使用赋值语句,也只是创造新的引用,而不是对象本身;
- Python没有缓存长字符串、列表及其他对象,可以由多个相同的对象,可以使用赋值语句创建出新的对象。
>>> var5 = 1
>>> var6 = 2
>>> print(var5 is var6)
True
>>> a = "hello"
>>> b = "hello"
>>> print(a is b)
True
>>> var7 = "hello world"
>>> var8 = "hello world"
>>> print(var7 is var8)
False
>>> var9 = []
>>> var10 =[]
>>> print(var9 is var10)
False
- 除此之外,在编程测试过程中也出现下图的情况,因为Python缓冲池等机制的影响导致如下原因,可以参考:https://blog.csdn.net/baidu20008/article/details/22432247?utm_source=blogxgwz0
>>> c=256
>>> d=256
>>> print(c is d)
True
>>> e=257
>>> f=257
>>> print(e is f)
False
2、引用计数
Python采用了类似Windows内核对象一样的方式来对内存进行管理。每个对象都有指向该对象的引用总数——引用计数。我们使用sys.getrefcount()查看对象的引用计数。
- 普通引用
>>> import sys
>>> a = [1,2,3]
>>> sys.getrefcount(a)
2
>>> b = a
>>> sys.getrefcount(a)
3
>>> sys.getrefcount(b)
3
当使用某个引用作为参数,传递给sys.getrefcount()时,参数实际上创建了一个临时的引用。因此,sys.getrefcount()得到的结果,会多1。
- 容器对象
Python的一个容器对象(比如:表、词典等),可以包含多个对象。
>>> a = [1,2,3,4]
>>> b = a
>>> print(a is b)
True
>>> a[0] = 5
>>> a
[5, 2, 3, 4]
>>> print(a is b)
True
>>> b
[5, 2, 3, 4]
在Python中,容器对象中包含的并不是元素对象本身,而是指向各个元素对象的引用。
下面一些情况下引用计数增加:
1.对象被创建:x=4
2.另外的别人被创建:y=x
3.被作为参数传递给函数:foo(x)
4.作为容器对象的一个元素:a=[1,x,'33']
引用计数减少:
1.一个本地引用离开了它的作用域。比如上面的foo(x)函数结束时,x指向的对象引用减1。
2.对象的别名被显式的销毁:del x ;或者del y
3.对象的一个别名被赋值给其他对象:x=789
4.对象从一个窗口对象中移除:myList.remove(x)
5.窗口对象本身被销毁:del myList,或者窗口对象本身离开了作用域。
3、垃圾回收
Python不同于C等语言,可以不用事先声明变量类型而直接对变量进行赋值。对Python来说,对象的类型和内存都是在运行时确定的,所以说Python是动态语言。
当Python中的对象越来越多,占据越来越大的内存,就会启动垃圾回收,将没用的对象清除。当Python的某个对象的引用计数降为0时,说明没有任何引用指向该对象,该对象就成为要被回收的垃圾。比如某个新建对象,被分配给某个引用,对象的引用计数变为1。如果引用被删除,对象的引用计数为0,那么该对象就可以被垃圾回收。
当内存中有不再使用的部分时,垃圾收集器就会把他们清理掉。它会去检查那些引用计数为0的对象,然后清除其在内存的空间。当然除了引用计数为0的会被清除,还有一种情况也会被垃圾收集器清掉:当两个对象相互引用时,他们本身其他的引用已经为0。
- 使用del
>>> var10 = [1234]
>>> del var10
>>> id(var10)
Traceback (most recent call last):
File "<pyshell#47>", line 1, in <module>
id(var10)
NameError: name 'var10' is not defined
del var10,已经没有任何引用指向[1234],该表引用计数变为0,Python扫描到这个引用计数为0的对象,就将它所占据的内存清空。 所以使用id函数时,会报错说var10没有被定义。
一些注意
1、垃圾回收时,Python不能进行其它的任务,频繁的垃圾回收将大大降低Python的工作效率;
2、Python只会在特定条件下,自动启动垃圾回收(垃圾对象少就没必要回收)
3、当Python运行时,会记录其中分配对象(object allocation)和取消分配对象(object deallocation)的次数。当两者的差值高于某个阈值时,垃圾回收才会启动。
gc模块中查看阈值的方法:
>>> import gc
>>> gc.get_threshold()
(700, 10, 10)
700是垃圾回收启动的阈值。每10次0代垃圾回收,会配合1次1代的垃圾回收;而每10次1代的垃圾回收,才会有1次的2代垃圾回收;对于Pyhon中分代的理解:Python将所有的对象分为0,1,2三代;所有的新建对象都是0代对象;当某一代对象经历过垃圾回收,依然存活,就被归入下一代对象。
也可以手动启动垃圾回收,直接调用gc.collect()函数。
>>> gc.collect()
6
4、内存池机制
Python中有分为大内存和小内存(256K界限):
- 大内存使用malloc进行分配
- 小内存使用内存池进行分配
- Python的内存池(金字塔)
Python的内存机制以金字塔行:
-1,-2层主要有操作系统进行操作。
第0层是C中的malloc,free等内存分配和释放函数进行操作。
第1层和第2层是内存池,有Python的接口函数PyMem_Malloc函数实现,当对象小于256K时有该层直接分配内存。
第3层是最上层,也就是我们对Python对象的直接操作。
在 C 中如果频繁的调用 malloc 与 free 时,是会产生性能问题的,再加上频繁的分配与释放小块的内存会产生内存碎片。Python 在这里主要干的工作有:
如果请求分配的内存在1~256字节之间就使用自己的内存管理系统,否则直接使用 malloc。
这里还是会调用 malloc 分配内存,但每次会分配一块大小为256k的大块内存。
对于简单的Python对象,例如数值、字符串,元组(tuple不允许被更改)采用的是复制的方式(深拷贝),即是当将另一个变量B赋值给变量A时,虽然A和B的内存空间仍然相同,但当A的值发生变化时,会重新给A分配空间,A和B的地址变得不再相同。而对于像字典(dict),列表(List)等,改变一个就会引起另一个的改变,也称之为浅拷贝。
参考资料
[1]https://www.cnblogs.com/geaozhang/p/7111961.html
[2]https://www.cnblogs.com/aomi/p/7353411.html
[3]https://blog.csdn.net/github_38976972/article/details/79633214?utm_source=blogxgwz5
[4]https://blog.csdn.net/github_38976972/article/details/79633214?utm_source=blogxgwz5