【python进阶】Garbage collection垃圾回收1

前言

GC垃圾回收在python中是很重要的一部分，一样我将分两次去讲解Garbage collection垃圾回收，此篇为Garbage collection垃圾回收第一篇，下面开始今天的说明~~~

1.Garbage collection(GC垃圾回收)

如今的⾼级语⾔如java，c#等，都采⽤了垃圾收集机制，⽽再也不是c，c++⾥ ⽤户⾃⼰管理维护内存的⽅式。⾃⼰管理内存极其⾃由，能够任意申请内存，但如同⼀把双刃剑，为⼤量内存泄露，悬空指针等bug埋下隐患。 对于⼀个字符串、列表、类甚⾄数值都是对象，且定位简单易⽤的语⾔，⾃然不会让⽤户去处理如何分配回收内存的问题。 python⾥也同java⼀样采⽤了垃圾收集机制，不过不⼀样的是: python采⽤的是引⽤计数机制为主，标记-清除和分代收集两种机制为辅的策略。
引⽤计数机制：
python⾥每⼀个东⻄都是对象，它们的核⼼就是⼀个结构体： PyObject

typedef struct_object{
    int ob_refcnt;                
    struct_typeobject *ob_type; 
}PyObject;

PyObject是每一个对象必有的内容，其中ob_refcnt就是作为引⽤计数。当⼀个对象有新的引⽤时，它的ob_refcnt就会增长，当引⽤它的对象被删除，它的 ob_refcnt就会减小.

#define Py_INCREF(op)     ((op)->ob_refcnt++)    //增长计数 
#defien Py_DECREF(op) \ //减小计数
    if(--(op)->ob_refcnt!=0)\
        ;\
    else \
        _Py_Dealloc((PyObject *)(op))

当引⽤计数为0时，该对象⽣命就结束了。

引⽤计数机制的优势：

• 简单 

• 实时性：⼀旦没有引⽤，内存就直接释放了。不⽤像其余机制等到特定时机。实时性还带来⼀个好处：处理回收内存的时间分摊到了平时。

引⽤计数机制的缺点：

• 维护引⽤计数消耗资源 

• 循环引⽤

list1 = []
list2 = []
list1.append(list2)
list2.append(list1)

list1与list2相互引⽤，若是不存在其余对象对它们的引⽤，list1与list2的引⽤ 计数也仍然为1，所占⽤的内存永远⽆法被回收，这将是致命的。 对于现在的强⼤硬件，缺点1尚可接受，可是循环引⽤致使内存泄露，注定python还将 引⼊新的回收机制。(标记清除和分代收集)

2.画说Ruby与Python垃圾回收

英⽂原⽂: visualizing garbage collection in ruby and python

2.1.应⽤程序那颗跃动的⼼

GC系统所承担的⼯做远⽐"垃圾回收"多得多。实际上，它们负责三个重要任务：

• 为新⽣成的对象分配内存
• 识别那些垃圾对象
• 从垃圾对象那回收内存

若是将应⽤程序⽐做⼈的身体：全部你所写的那些优雅的代码，业务逻辑， 算法，应该就是⼤脑。以此类推，垃圾回收机制应该是那个身体器官呢?(我从RuPy听众那听到了很多有趣的答案：腰⼦、⽩⾎球)
我认为垃圾回收就是应⽤程序那颗跃动的⼼。像⼼脏为身体其余器官提供⾎ 液和养分物那样，垃圾回收器为你的应该程序提供内存和对象。若是⼼脏停跳，过不了⼏秒钟⼈就完了。若是垃圾回收器停⽌⼯做或运⾏迟缓,像动脉阻塞,你的应⽤程序效率也会降低，直⾄最终死掉。

2.2.一个简单的例子

运⽤实例⼀贯有助于理论的理解。下⾯是⼀个简单类，分别⽤Python和Ruby写成，咱们今天就以此为例：

顺便提⼀句，两种语⾔的代码竟能如此相像：Ruby和Python在表达同⼀事物上真的只是略有不一样。可是在这两种语⾔的内部实现上是否也如此类似呢？

2.3.Ruby的对象分配

当咱们执⾏上⾯的Node.new(1)时，Ruby到底作了什么？Ruby是如何为咱们 建立新的对象的呢？ 出乎意料的是它作的⾮常少。实际上，早在代码开始执⾏前，Ruby就提早建立了成百上千个对象，并把它们串在链表上，名⽈：可⽤列表。下图所示为可⽤列表的概念图：

想象⼀下每一个⽩⾊⽅格上都标着⼀个"未使⽤预建立对象"。当咱们调⽤ Node.new ,Ruby只需取⼀个预建立对象给咱们使⽤便可：

上图中左侧灰格表示咱们代码中使⽤的当前对象，同时其余⽩格是未使⽤对象。(请注意：⽆疑个人示意图是对实际的简化。实际上，Ruby会⽤另⼀个 对象来装载字符串"ABC",另⼀个对象装载Node类定义，还有⼀个对象装载了代码中分析出的抽象语法树，等等)
若是咱们再次调⽤ Node.new，Ruby将递给咱们另⼀个对象：

这个简单的⽤链表来预分配对象的算法已经发明了超过50年，⽽发明⼈这是 赫赫有名的计算机科学家John McCarthy，⼀开始是⽤Lisp实现的。Lisp不只 是最先的函数式编程语⾔，在计算机科学领域也有许多创举。其⼀就是利⽤垃圾回收机制⾃动化进⾏程序内存管理的概念。

标准版的Ruby，也就是众所周知的"Matz's Ruby Interpreter"(MRI),所使⽤的 GC算法与McCarthy在1960年的实现⽅式很相似。⽆论好坏，Ruby的垃圾回 收机制已经53岁⾼龄了。像Lisp⼀样，Ruby预先建立⼀些对象，而后在你分配新对象或者变量的时候供你使⽤。

2.4.Python的对象分配

咱们已经了解了Ruby预先建立对象并将它们存放在可⽤列表中。那Python⼜怎么样呢？
尽管因为许多缘由Python也使⽤可⽤列表(⽤来回收⼀些特定对象⽐如list)， 但在为新对象和变量分配内存的⽅⾯Python和Ruby是不一样的。
例如咱们⽤Pyhon来建立⼀个Node对象：

与Ruby不一样，当建立对象时Python⽴即向操做系统请求内存.(Python实际 上实现了⼀套⾃⼰的内存分配系统，在操做系统堆之上提供了⼀个抽象层。 可是我今天不展开说了)
当咱们建立第⼆个对象的时候，再次像OS请求内存：

看起来够简单吧，在咱们建立对象的时候，Python会花些时间为咱们找到并分配内存。

2.5.Ruby开发者住在凌乱的房间里

Ruby把⽆⽤的对象留在内存⾥，直到下⼀次GC执⾏
回过来看Ruby。随着咱们建立愈来愈多的对象，Ruby会持续寻可⽤列表⾥ 取预建立对象给咱们。所以，可⽤列表会逐渐变短:

...而后更短：

请注意我⼀直在为变量n1赋新值，Ruby把旧值留在原处。"ABC","JKL"和"MNO"三个Node实例还滞留在内存中。Ruby不会⽴即清除代码中再也不使⽤的旧对象！Ruby开发者们就像是住在⼀间凌乱的房间，地板上摞着⾐服，要么洗碗池⾥都是脏盘⼦。做为⼀个Ruby程序员，⽆⽤的垃圾对象会⼀直环绕着你。

2.6.Python开发者住在卫生之家庭

⽤完的垃圾对象会⽴即被Python打扫⼲净
Python与Ruby的垃圾回收机制颇为不一样。让咱们回到前⾯提到的三个Python Node对象：

在内部，建立⼀个对象时，Python老是在对象的C结构体⾥保存⼀个整数， 称为引⽤数 。期初，Python将这个值设置为1：

值为1说明分别有个⼀个指针指向或是引⽤这三个对象。假如咱们如今建立⼀个新的Node实例，JKL：

与以前⼀样，Python设置JKL的引⽤数为1。然⽽，请注意因为咱们改变了n1 指向了JKL，再也不指向ABC，Python就把ABC的引⽤数置为0了。 此刻， Python垃圾回收器⽴刻挺身⽽出！每当对象的引⽤数减为0，Python⽴即将其释放，把内存还给操做系统：

上⾯Python回收了ABC Node实例使⽤的内存。记住，Ruby弃旧对象原地于不顾，也不释放它们的内存。
Python的这种垃圾回收算法被称为引⽤计数。是George-Collins在1960年发明的，恰巧与John McCarthy发明的可⽤列表算法在同⼀年出现。就像MikeBernstein在6⽉份哥谭市Ruby⼤会杰出的垃圾回收机制演讲中说的: "1960年是垃圾收集器的⻩⾦年代..."。

Python开发者⼯做在卫⽣之家,你能够想象，有个患有轻度OCD(⼀种强迫症) 的室友⼀刻不停地跟在你身后打扫，你⼀放下脏碟⼦或杯⼦，有个家伙已经 准备好把它放进洗碗机了！
如今来看第⼆例⼦。加⼊咱们让n2引⽤n1：

上图中左边的DEF的引⽤数已经被Python减小了，垃圾回收器会⽴即回收DEF实例。同时JKL的引⽤数已经变为了2 ，由于n1和n2都指向它。

2.7.标记-清除

最终那间凌乱的房间充斥着垃圾，再不能岁⽉静好了。在Ruby程序运⾏了⼀阵⼦之后，可⽤列表最终被⽤光光了:

此刻全部Ruby预建立对象都被程序⽤过了(它们都变灰了)，可⽤列表⾥空空如也（没有⽩格⼦了）。
此刻Ruby祭出另⼀McCarthy发明的算法，名⽈：标记-清除。⾸先Ruby把程 序停下来，Ruby⽤"地球停转垃圾回收⼤法"。以后Ruby轮询全部指针，变量 和代码产⽣别的引⽤对象和其余值。同时Ruby经过⾃身的虚拟机便利内部指针。标记出这些指针引⽤的每一个对象。我在图中使⽤M表示。

上图中那三个被标M的对象是程序还在使⽤的。在内部，Ruby实际上使⽤⼀串位值，被称为:可⽤位图(译注：还记得《编程珠玑》⾥的为突发排序吗，这 对离散度不⾼的有限整数集合具备很强的压缩效果，⽤以节约机器的资源)，来跟踪对象是否被标记了。

若是说被标记的对象是存活的，剩下的未被标记的对象只能是垃圾，这意味 着咱们的代码再也不会使⽤它了。我会在下图中⽤⽩格⼦表示垃圾对象：

接下来Ruby清除这些⽆⽤的垃圾对象，把它们送回到可⽤列表中：

在内部这⼀切发⽣得迅雷不及掩⽿，由于Ruby实际上不会吧对象从这拷⻉到 那。⽽是经过调整内部指针，将其指向⼀个新链表的⽅式，来将垃圾对象归位到可⽤列表中的。
如今等到下回再建立对象的时候Ruby⼜能够把这些垃圾对象分给咱们使⽤了。在Ruby⾥，对象们六道轮回，转世投胎，享受屡次⼈⽣。

2.8.标记-删除 vs. 引⽤计数

乍⼀看，Python的GC算法貌似远胜于Ruby的：宁舍洁宇⽽居秽室乎？为何Ruby宁愿按期强制程序停⽌运⾏，也不使⽤Python的算法呢？
然⽽，引⽤计数并不像第⼀眼看上去那样简单。有许多缘由使得不准多语⾔ 不像Python这样使⽤引⽤计数GC算法：

⾸先，它很差实现。Python不得不在每一个对象内部留⼀些空间来处理引⽤数。这样付出了⼀⼩点⼉空间上的代价。但更糟糕的是，每一个简单的操做(像修改变量或引⽤)都会变成⼀个更复杂的操做，由于Python须要增长⼀ 个计数，减小另⼀个，还可能释放对象。
第⼆点，它相对较慢。虽然Python随着程序执⾏GC很稳健（⼀把脏碟⼦放在 洗碗盆⾥就开始洗啦），但这并不⼀定更快。Python不停地更新着众多引⽤ 数值。特别是当你再也不使⽤⼀个⼤数据结构的时候，⽐如⼀个包含不少元素的列表，Python可能必须⼀次性释放⼤量对象。减小引⽤数就成了⼀项复杂的递归过程了。
最后，它不是总奏效的。引⽤计数不能处理环形数据结构--也就是含有循环引⽤的数据结构。

3.Python中的循环数据结构以及引⽤计数

3.1.循环引⽤

经过上篇，咱们知道在Python中，每一个对象都保存了⼀个称为引⽤计数的整数值，来追踪到底有多少引⽤指向了这个对象。⽆论什么时候，若是咱们程序中的⼀个变量或其余对象引⽤了⽬标对象，Python将会增长这个计数值，⽽当 程序停⽌使⽤这个对象，则Python会减小这个计数值。⼀旦计数值被减到 零，Python将会释放这个对象以及回收相关内存空间。
从六⼗年代开始，计算机科学界就⾯临了⼀个严重的理论问题，那就是针对 引⽤计数这种算法来讲，若是⼀个数据结构引⽤了它⾃身，即若是这个数据 结构是⼀个循环数据结构，那么某些引⽤计数值是确定⽆法变成零的。为了更好地理解这个问题，让咱们举个例⼦。下⾯的代码展现了⼀些上周咱们所⽤到的节点类：

咱们有⼀个"构造器"(在Python中叫作 __init__ )，在⼀个实例变量中存储⼀个单独的属性。在类定义以后咱们建立两个节点，ABC以及DEF，在图中为左边的矩形框。两个节点的引⽤计数都被初始化为1，由于各有两个引⽤指向各个节点(n1和n2)。
如今，让咱们在节点中定义两个附加的属性，next以及prev：

跟Ruby不一样的是，Python中你能够在代码运⾏的时候动态定义实例变量或对象属性。这看起来彷佛有点像Ruby缺失了某些有趣的魔法。(声明下我不是 ⼀个Python程序员，因此可能会存在⼀些命名⽅⾯的错误)。咱们设置 n1.next 指向 n2，同时设置 n2.prev 指回 n1。如今，咱们的两个节点使⽤循 环引⽤的⽅式构成了⼀个 双向链表 。同时请注意到 ABC 以及 DEF 的引⽤计 数值已经增长到了2。这⾥有两个指针指向了每一个节点：⾸先是 n1 以及 n2， 其次就是 next 以及 prev。
如今，假定咱们的程序再也不使⽤这两个节点了，咱们将 n1 和 n2 都设置为 null(Python中是None)。

好了，Python会像往常⼀样将每一个节点的引⽤计数减小到1。

3.2.在Python中的零代(Generation Zero)

请注意在以上刚刚说到的例⼦中，咱们以⼀个不是很常⻅的状况结尾：咱们 有⼀个“孤岛”或是⼀组未使⽤的、互相指向的对象，可是谁都没有外部引 ⽤。换句话说，咱们的程序再也不使⽤这些节点对象了，因此咱们但愿Python 的垃圾回收机制可以⾜够智能去释放这些对象并回收它们占⽤的内存空间。 可是这不可能，由于全部的引⽤计数都是1⽽不是0。Python的引⽤计数算法 不可以处理互相指向⾃⼰的对象。
这就是为何Python要引⼊ Generational GC 算法的缘由！正如Ruby使⽤ ⼀个链表(free list)来持续追踪未使⽤的、⾃由的对象⼀样，Python使⽤⼀种 不一样的链表来持续追踪活跃的对象。⽽不将其称之为“活跃列表”，Python的 内部C代码将其称为零代(Generation Zero)。每次当你建立⼀个对象或其余什么值的时候，Python会将其加⼊零代链表：

从上边能够看到当咱们建立ABC节点的时候，Python将其加⼊零代链表。请 注意到这并非⼀个真正的列表，并不能直接在你的代码中访问，事实上这个链表是⼀个彻底内部的Python运⾏时。 类似的，当咱们建立DEF节点的时候，Python将其加⼊一样的链表：

如今零代包含了两个节点对象。(他还将包含Python建立的每一个其余值，与⼀些Python⾃⼰使⽤的内部值)

3.3.检测循环引⽤

随后，Python会循环遍历零代列表上的每一个对象，检查列表中每一个互相引⽤的对象，根据规则减掉其引⽤计数。在这个过程当中，Python会⼀个接⼀个的 统计内部引⽤的数量以防过早地释放对象。
为了便于理解，来看⼀个例⼦：

从上⾯能够看到 ABC 和 DEF 节点包含的引⽤数为1.有三个其余的对象同时 存在于零代链表中，蓝⾊的箭头指示了有⼀些对象正在被零代链表以外的其余对象所引⽤。(接下来咱们会看到，Python中同时存在另外两个分别被称为 ⼀代和⼆代的链表)。这些对象有着更⾼的引⽤计数由于它们正在被其余指针所指向着。
接下来你会看到Python的GC是如何处理零代链表的。

经过识别内部引⽤，Python可以减小许多零代链表对象的引⽤计数。在上图 的第⼀⾏中你可以看⻅ABC和DEF的引⽤计数已经变为零了，这意味着收集器能够释放它们并回收内存空间了。剩下的活跃的对象则被移动到⼀个新的 链表：⼀代链表。
从某种意义上说，Python的GC算法相似于Ruby所⽤的标记回收算法。周期性地从⼀个对象到另⼀个对象追踪引⽤以肯定对象是否仍是活跃的，正在被程序所使⽤的，这正相似于Ruby的标记过程。

4.Python中的GC阈值

Python何时会进⾏这个标记过程？随着你的程序运⾏，Python解释器保 持对新建立的对象，以及由于引⽤计数为零⽽被释放掉的对象的追踪。从理论上说，这两个值应该保持⼀致，由于程序新建的每一个对象都应该最终被释放掉。
固然，事实并⾮如此。由于循环引⽤的缘由，而且由于你的程序使⽤了⼀些 ⽐其余对象存在时间更⻓的对象，从⽽被分配对象的计数值与被释放对象的计数值之间的差别在逐渐增⻓。⼀旦这个差别累计超过某个阈值，则Python的收集机制就启动了，而且触发上边所说到的零代算法，释放“浮动的垃圾”，而且将剩下的对象移动到⼀代列表。

随着时间的推移，程序所使⽤的对象逐渐从零代列表移动到⼀代列表。⽽ Python对于⼀代列表中对象的处理遵循一样的⽅法，⼀旦被分配计数值与被 释放计数值累计到达⼀定阈值，Python会将剩下的活跃对象移动到⼆代列表。
经过这种⽅法，你的代码所⻓期使⽤的对象，那些你的代码持续访问的活跃 对象，会从零代链表转移到⼀代再转移到⼆代。经过不一样的阈值设置， Python能够在不一样的时间间隔处理这些对象。Python处理零代最为频繁，其 次是⼀代而后才是⼆代。
弱代假说
来看看代垃圾回收算法的核⼼⾏为：垃圾回收器会更频繁的处理新对象。⼀个新的对象便是你的程序刚刚建立的，⽽⼀个来的对象则是通过了⼏个时间 周期以后仍然存在的对象。Python会在当⼀个对象从零代移动到⼀代，或是 从⼀代移动到⼆代的过程当中提高(promote)这个对象。
为何要这么作？这种算法的根源来⾃于弱代假说(weak generational hypothesis)。这个假说由两个观点构成：⾸先是年亲的对象一般死得也快， ⽽⽼对象则颇有可能存活更⻓的时间。
假定如今我⽤Python或是Ruby建立⼀个新对象：

根据假说，个人代码极可能仅仅会使⽤ABC很短的时间。这个对象也许仅仅 只是⼀个⽅法中的中间结果，而且随着⽅法的返回这个对象就将变成垃圾了。⼤部分的新对象都是如此般地很快变成垃圾。然⽽，偶尔程序会建立⼀ 些很重要的，存活时间⽐较⻓的对象-例如web应⽤中的session变量或是配置项。经过频繁的处理零代链表中的新对象，Python的垃圾收集器将把时间花在更 有意义的地⽅：它处理那些很快就可能变成垃圾的新对象。同时只在不多的 时候，当满⾜阈值的条件，收集器才回去处理那些⽼变量。