Python内存管理机制

实验中遇到了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