由于面试中遇到了垃圾回收的问题，转载学习和总结这个问题。

　　在C/C++中采用用户自己管理维护内存的方式。自己管理内存极其*，可以任意申请内存，但也为大量内存泄露、悬空指针等bug埋下隐患。

　　因此在现在的高级语言（java、C#等）都采用了垃圾收集机制。

　　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++)          //增加计数

#define Py_DECREF(op)      \                         //减少计数

     if (--(op)->ob_refcnt != )    \

         ;        \

     else         \

         __Py_Dealloc((PyObject *)(op))

　　引用计数为0时，该对象声明就结束了。

1、引用计数机制优点

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

2、引用计数机制缺点

• 维护引用计数消耗资源
• 循环引用

list1 = []

list2 = []

list1.append(list2)

list2.append(list1)

　　list1与list2相互引用，如果不存在其他对象对它们的引用，list1与list2的引用计数也仍然为1，所占用的内存永远无法被回收，这将是致命的。

　　对于如今的强大硬件，缺点1尚可接受，但是循环引用导致内存泄露，注定python还将引入新的回收机制（标记清除和分代收集）。

　　转载地址:http://my.oschina.net/hebianxizao/blog/57367?fromerr=KJozamtm

二、Garbage collection(GC)

　　英文原文： visualizing garbage collection in ruby and python

　　中文：画说 Ruby 与 Python 垃圾回收

　　GC系统所承担的工作远比“垃圾回收”多得多。它们负责三个重要任务：

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

　　如果将应用程序比作人的身体：所有你所写的那些优雅的代码，业务逻辑，算法，应该就是大脑。垃圾回收就是应用程序那颗跃动的心。像心脏为身体其他器官提供血液和营养物那样，垃圾回收器为你的应该程序提供内存和对象。如果垃圾回收器停止工作或运行迟缓,像动脉阻塞,你的应用程序效率也会下降，直至最终死掉。

1、简单代码示例

　　运用实例来帮助理论理解，下面是一个简单类，分别用python和ruby写成：

2、Ruby——可用列表

　　在ruby中执行上面的Node.new(1)时，Ruby到底做了什么？Ruby是如何为我们创建新的对象的呢？

　　出乎意料的是它做的非常少。实际上，早在代码开始执行前，Ruby就提前创建了成百上千个对象，并把它们串在链表上，名曰：可用列表。下图所示为可用列表的概念图：

　　想象一下每个白色方格都标着一个“未使用预创建对象”。当调用Node.new时，Ruby只需要取一个预创建对象给我们使用即可：

　　上图中左侧灰格表示我们代码中使用的当前对象，同时其他白格是未使用对象。(请注意：无疑我的示意图是对实际的简化。实际上，Ruby会用另一个对象来装载字符串"ABC",另一个对象装载Node类定义，还有一个对象装载了代码中分析出的抽象语法树，等等)

　　

　　这个简单的用链表来预分配对象的算法已经发明了超过50年，发明者是计算机科学家John McCarthy，一开始是用Lisp语言实现。

　　Lisp不仅是最早的函数式编程语言，在计算机科学领域也有许多创举。其一就是利用垃圾回收机制自动化进行程序内存管理的概念。

　　标准版的Ruby，也就是众所周知的"Matz's Ruby Interpreter"(MRI),所使用的GC算法与McCarthy在1960年的实现方式很类似。

　　Ruby的垃圾回收机制像Lisp一样，预先创建一些对象，然后在你分配新对象或者变量的时候供你使用。

3、Python——对象分配

　　

　　Ruby把无用的对象留在内存里，直到下一次GC执行。随着我们创建越来越多的对象，Ruby会持续寻可用列表里取预创建对象给我们。因此，可用列表会逐渐变短:

　　

　　甚至变得更短：

　　

　　一直在为变量n1赋新值，Ruby把旧值留在原处。"ABC","JKL"和"MNO"三个Node实例还滞留在内存中。Ruby不会立即清除代码中不再使用的旧对象！

　　Ruby开发者们就像是住在一间凌乱的房间，地板上摞着衣服，要么洗碗池里都是脏盘子。作为一个Ruby程序员，无用的垃圾对象会一直环绕着你。

（2）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发明的可用列表算法在同一年出现。就像Mike-Bernstein在6月份哥谭市Ruby大会杰出的垃圾回收机制演讲中说的: "1960年是垃圾收集器的黄金年代..."

　　再让n2引用n1:

　　

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

三、标记——清除算法

　　

　　此刻所有Ruby预创建对象都被程序用过了（都变灰了），可用列表中空空如也（没有白格子）。

　　Ruby祭出另一McCarthy发明的算法，名曰：标记-清除。首先Ruby把程序停下来，Ruby用"地球停转垃圾回收大法"。之后Ruby轮询所有指针，变量和代码产生别的引用对象和其他值。同时Ruby通过自身的虚拟机便利内部指针。标记出这些指针引用的每个对象，在图中使用M表示。

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

　　

　　Ruby将这个可用位图存放在独立的内存区域中，以便充分利用Unix的写时拷贝化。有关此事的更多内容请关注我另一博文《Why You Should Be Excited About Garbage Collection in Ruby 2.0》。

　　如果说被标记的对象是存活的，剩下的未被标记的对象只能是垃圾。下图中用白格子来标识垃圾对象：

　　

　　Ruby来清除这些无用的垃圾对象，把它们送回到可用列表中：

　　

　　Ruby实际上不会吧对象从这拷贝到那。而是通过调整内部指针，将其指向一个新链表的方式，来将垃圾对象归位到可用列表中的。

现在等到下回再创建对象的时候Ruby又可以把这些垃圾对象分给我们使用了。在Ruby里，对象们六道轮回，转世投胎，享受多次人生。

四、标记—删除 vs 引用计数

　　咋一看，python的GC算法似乎远胜于Ruby：宁舍洁宇而居秽室乎？为什么Ruby宁愿定期强制程序停止运行，也不使用Python的算法呢？

　　引用计数并不像第一眼看上去那样简单。有许多原因使得不许多语言不像Python这样使用引用计数GC算法：

　　1、引用计数GC算法不好实现。

　　Python不得不在每个对象内部留一些空间来处理引用数。这样付出了一小点儿空间上的代价。但更糟糕的是，每个简单的操作（像修改变量或引用）都会变成一个更复杂的操作，因为Python需要增加一个计数，减少另一个，还可能释放对象。

　　2、引用计数GC算法相对较慢。

　　虽然Python随着程序执行GC很稳健（一把脏碟子放在洗碗盆里就开始洗啦），但这并不一定更快。Python不停地更新着众多引用数值。特别是当你不再使用一个大数据结构的时候，比如一个包含很多元素的列表，Python可能必须一次性释放大量对象。减少引用数就成了一项复杂的递归过程了。

　　3、引用计数GC算法并不总是奏效。

　　引用计数不能处理环形数据结构--也就是含有循环引用的数据结构。

五、Python的代式垃圾回收

　　英文原文地址: Generational GC in Python and Ruby
　　中文原文: 对比Ruby和Python的垃圾回收（2）：代式垃圾回收机制

1、python 引用计数算法

　　标准Ruby(也被称为Matz的Ruby解释器或是MRI)使用名为标记回收(Mark and Sweep)的垃圾回收算法，这个算法是为1960年原版本的Lisp所开发。

　　Python使用一种有53年历史的GC算法，这种算法的思路非常不同，称之为引用计数。

　　Python在引用计数之外，还用了另一个名为 Generational Garbage Collection 的算法。这意味着Python的垃圾回收器用不同的方式对待新创建的以及旧有的对象。

　　在Python中，每个对象都保存了一个称为引用计数的整数值，来追踪到底有多少引用指向了这个对象。

　　无论何时，如果我们程序中的一个变量或其他对象引用了目标对象，Python将会增加这个计数值，而当程序停止使用这个对象，则Python会减少这个计数值。一旦计数值被减到零，Python将会释放这个对象以及回收相关内存空间。

2、引用计数存在的问题（循环数据结构）

　　从二十世纪六十年代起，计算机科学界就面临一个严重的理论问题：针对引用计数算法来说，如果一个数据结构引用了它自身，则这个数据结构是一个循环数据结构，那么某些引用计数值是肯定无法变成零的。如下例所示：

　　上面代码中的构造器（Python中叫init），在一个实例变量中存储一个单独的属性。在类定义之后创建两个节点，ABC和DEF，在图中为左边的矩形框。

　　两个节点的引用计数都被初始化为1，因为各有两个引用指向各个节点（n1和n2）。再在节点中定义两个附加的属性：next和prev。

　　Python中可以在代码运行的时候动态定义实例变量或对象属性。设置 n1.next 指向 n2，同时设置 n2.prev 指回 n1。现在，我们的两个节点使用循环引用的方式构成了一个双端链表。同时请注意到 ABC 以及 DEF 的引用计数值已经增加到了2。这里有两个指针指向了每个节点：首先是 n1 以及 n2，其次就是 next 以及 prev。

　　然后假定程序不再使用这两个节点，将n1和n2都设置为None。

　　此时，python如同往常一样将每个节点的引用计数减少到1。

　　一个“孤岛”或是一组未使用的、互相指向的对象，但是谁都没有外部引用。换句话说，我们的程序不再使用这些节点对象了，所以我们希望Python的垃圾回收机制能够足够智能去释放这些对象并回收它们占用的内存空间。但是这不可能，因为所有的引用计数都是1而不是0。Python的引用计数算法不能够处理互相指向自己的对象。

3、python中的零代（Generation Zero）

　　代码也许会在不经意间包含循环引用而且程序员往往未意识到。

　　事实上，Python程序运行的时候它将会建立一定数量的“浮点数垃圾”，Python的GC不能够处理未使用的对象因为应用计数值不会到零。

　　因此python要引入 Generation GC 算法。如Ruby使用一个链表(free list)来持续追踪未使用的、*的对象一样，Python使用一种不同的链表来持续追踪活跃的对象。而不将其称之为“活跃列表”，Python的内部C代码将其称为零代(Generation Zero)。每次当你创建一个对象或其他什么值的时候，Python会将其加入零代链表。

　　从上边可以看到当我们创建ABC节点的时候，Python将其加入零代链表。请注意到这并不是一个真正的列表，并不能直接在你的代码中访问，事实上这个链表是一个完全内部的Python运行时。

　　相似的，当我们创建DEF节点的时候，Python将其加入同样的链表：

　　此时，零代包含了两个节点对象。(他还将包含Python创建的每个其他值，与一些Python自己使用的内部值。)

4、检测循环引用

　　随后，Python会循环遍历零代列表上的每个对象，检查列表中每个互相引用的对象，根据规则减掉其引用计数。在这个过程中，Python会一个接一个的统计内部引用的数量以防过早地释放对象。

（1）循环检测示例

（2）python的GC处理零代链表

　　通过识别内部引用，Python能够减少许多零代链表对象的引用计数。在上图的第一行中你能够看见ABC和DEF的引用计数已经变为零了，这意味着收集器可以释放它们并回收内存空间了。剩下的活跃的对象则被移动到一个新的链表：一代链表。

　　从某种意义上说，Python的GC算法类似于Ruby所用的标记回收算法。周期性地从一个对象到另一个对象追踪引用以确定对象是否还是活跃的，正在被程序所使用的，这正类似于Ruby的标记过程。

5、弱代假说(weak generational hypothesis)

　　代垃圾回收算法的核心行为：垃圾回收器会更频繁的处理新对象。一个新的对象即是你的程序刚刚创建的，而一个来的对象则是经过了几个时间周期之后仍然存在的对象。

　　python会在当一个对象从零代移动到一代，或是从一代移动到二代的过程中提升（promote）这个对象。这么做的缘故是弱代假说。

　　弱代假说由两个观点构成：年轻的对象通常死得也快，而老对象则很可能存活更长时间。

　　假定现在用Python或Ruby创建一个新对象：

　　根据假说，我的代码很可能仅仅会使用ABC很短的时间。这个对象也许仅仅只是一个方法中的中间结果，并且随着方法的返回这个对象就将变成垃圾了。大部分的新对象都是如此般地很快变成垃圾。

　　然而，偶尔程序会创建一些很重要的，存活时间比较长的对象-例如web应用中的session变量或是配置项。

　　通过频繁的处理零代链表中的新对象，Python的垃圾收集器将把时间花在更有意义的地方：它处理那些很快就可能变成垃圾的新对象。同时只在很少的时候，当满足阈值的条件，收集器才回去处理那些老变量。

六、Ruby的代式垃圾回收

1、Ruby的*链

　　Ruby 2.1版本将会首次使用基于代的垃圾回收算法！当*链使用完之后，Ruby会标记你的程序仍然在使用的对象。

　　从这张图上我们可以看到有三个活跃的对象，因为指针n1、n2、n3仍然指向着它们。剩下的用白色矩形表示的对象即是垃圾。(实际情况会复杂得多，*链可能会包含上千个对象，并且有复杂的引用指向关系，这里的简图只是帮助我们了解Ruby的GC机制背后的简单原理，而不会将我们陷入细节之中)

　　Ruby会将垃圾对象移动回*链中，这样的话它们就能在程序申请新对象的时候被循环使用了。

2、Ruby2.1基于代的GC机制

　　从2.1版本开始，Ruby的GC代码增加了一些附加步骤：它将留下来的活跃对象晋升(promote)到成熟代(mature generation)中。(在MRI的C源码中使用了old这个词而不是mature)，接下来的图展示了两个Ruby2.1对象代的概念图：

　　在左边是一个跟*链不相同的场景，我们可以看到垃圾对象是用白色表示的，剩下的是灰色的活跃对象。灰色的对象刚刚被标记。

　　一旦“标记清除”过程结束，Ruby2.1将剩下的标记对象移动到成熟区：

　　跟Python中使用三代来划分不同，Ruby2.1只用了两代，左边是年轻的新一代对象，而右边是成熟代的老对象。一旦Ruby2.1标记了对象一次，它就会被认为是成熟的。Ruby会打赌剩下的活跃对象在相当长的一段时间内不会很快变成垃圾对象。

　　注意：Ruby2.1并不会真的在内存中拷贝对象，这些代表不同代的区域并不是由不同的物理内存区域构成。(有一些别的编程语言的GC实现或是Ruby的其他实现，可能会在对象晋升的时候采取拷贝的操作)。Ruby2.1的内部实现不会将在标记&清除过程中预先标记的对象包含在内。一旦一个对象已经被标记过一次了，那么那将不会被包含在接下来的标记清除过程中。

　　假定你的Ruby程序接着运行着，创造了更多新的，更年轻的对象。则GC的过程将会在新的一代中出现，如图：

3、白障

　　假定你的代码创建了一个新的年轻的对象，并且将其作为一个已存在的成熟对象的子嗣加入。举个例子，这种情况将会发生在，当你往一个已经存在了很长时间的数组中增加了一个新值的时候：

　　左边的是新对象，而成熟的对象在右边。在左边标记过程已经识别出了5个新的对象目前仍然是活跃的(灰色)。但有两个对象已经变成垃圾了(白色)。

　　但是如何处理正中间这个新建对象？这是刚刚那个问题提到的对象，它是垃圾还是活跃对象呢？

　　它是活跃对象，因为有一个从右边成熟对象的引用指向它。但是我们前面说过已经被标记的成熟对象是不会被包含在标记清除过程中的(一直到全局回收)。这意味着类似这种的新建对象会被错误的认为是垃圾而被释放，从而造成数据丢失。

　　Ruby2.1 通过监视成熟对象，观察你的代码是否会添加一个从它们到新建对象的引用来克服这个问题。

　　Ruby2.1 使用了一个名为白障(white barriers)的老式GC技术来监视成熟对象的变化 – 无论任意时刻当你添加了从一个对象指向另一个对象的引用时(无论是新建或是修改一个对象)，白障就会被触发。白障将会检测是否源对象是一个成熟对象，如果是的话则将这个成熟对象添加到一个特殊的列表中。随后，Ruby2.1会将这些满足条件的成熟对象包括到下一次标记清除的范围内，以防止新建对象被错误的标记为垃圾而清除。

　　Ruby2.1 的白障实现相当复杂，主要是因为已有的C扩展并未包含这部分功能。Koichi Sasada以及Ruby的核心团队使用了一个比较巧妙的方案来解决这个问题。如果想了解更多的内容，请阅读这些相关材料：Koichi在EuRuKo 2013上的演讲Koichi’s fascinating presentation。

七、总结