一、概述
在5.2及更早版本的PHP中，没有专门的垃圾回收器GC（Garbage Collection），引擎在判断一个变量空间是否能够被释放的时候是依据这个变量的zval的refcount_gc的值，如果refcount_gc为0，那么变量的空间可以被释放，否则就不释放，这是一种非常简单的GC实现。然而这种GC实现方案中，出现了变量内存泄漏情况（Bug:http://bugs.php.net/bug.php?id=33595），引擎将无法回收这些内存，于是在PHP5.3中使用了新的GC，新GC有专门的机制负责清理垃圾数据，防止内存泄漏。
介绍新的GC前，必须先了解PHP的内部存储，可以看TIPI深入理解PHP内核 [变量的结构和类型] 。
二、什么是垃圾
首先需要定义一下“垃圾”的概念，新的GC负责清理的垃圾是指变量的容器zval还存在，但是又没有任何变量名指向此zval。因此GC判断是否为垃圾的一个重要标准是有没有变量名指向变量容器zval。
假设有一段PHP代码，使用了一个临时变量$tmp存储了一个字符串，在处理完字符串之后，$tmp变量对我们没有意义，但这个变量实际还存在，$tmp符号依然指向它所对应的zval，GC会认为PHP代码中可能还会使用到此变量，所以不会将其定义为垃圾。
如果在PHP代码中使用完$tmp后，调用unset删除这个变量，那么$tmp是不是就成为一个垃圾了呢。很可惜，GC仍然不认为$tmp是一个垃圾，因为$tmp在unset之后，refcount_gc减少1变成了0(假设没有别的变量和$tmp指向相同的zval)，这时GC会直接将$tmp对应的zval的内存空间释放，$tmp和其对应的zval就根本不存在了。此时的$tmp也不是新的GC所要对付的那种“垃圾”。那么新的GC究竟要对付什么样的垃圾呢，下面将生产一个这样的垃圾。
三、顽固垃圾的产生过程
接下来将结合手册中的一个例子来介绍垃圾的产生过程：
<?php
$a = "new string";
?>代码中，$a变量内部存储信息为
a: (refcount_gc=1, is_ref_gc=0)='new string'当把$a赋值给另外一个变量的时候，$a对应的zval的refcount_gc会加1
<?php
$a = "new string";
$b = $a;
?>此时$a和$b变量对应的内部存储信息为
a,b: (refcount_gc=2, is_ref=0)='new string'当用unset删除$b变量时，$b对应的zval的refcount_gc会减1。
<?php
$a = "new string"; //a: (refcount_gc=1, is_ref_gc=0)='new string'
$b = $a; //a,b: (refcount_gc=2, is_ref=0)='new string'
unset($b); //a: (refcount_gc=1, is_ref=0)='new string'
?>对于普通的变量来说，这一切很正常，但是在复合类型变量（数组和对象）中，会发生比较有意思的事情：
<?php
$a = array('meaning' => 'life', 'number' => 42);
?>a内部存储信息为:
a: (refcount=1, is_ref=0)=array (
'meaning' => (refcount=1, is_ref=0)='life',
'number' => (refcount=1, is_ref=0)=42
)数组变量本身($a)在引擎内部实际上是一个哈希表，这张表中有两个zval项 meaning和number，
所以实际上那一行代码中一共生成了3个zval,这3个zval都遵循变量的引用和计数原则，用图来表示:
下面在$a中添加一个元素，并将现有的一个元素的值赋给新的元素:
<?php
$a = array('meaning' => 'life', 'number' => 42);
$a['life'] = $a['meaning'];
?>那么$a的内部存储为:
a: (refcount=1, is_ref=0)=array (
'meaning' => (refcount=2, is_ref=0)='life',
'number' => (refcount=1, is_ref=0)=42,
'life' => (refcount=2, is_ref=0)='life'
)其中的meaning元素和life元素之指向同一个zval：
如果将数组的引用赋值给数组中的一个元素，有意思的事情就会发生：
<?php
$a = array('one');
$a[] = &$a;
?>这样$a数组就有两个元素，一个索引为0，值为字符one，另外一个索引为1，为$a自身的引用，内部存储如下:
a: (refcount=2, is_ref=1)=array (
0 => (refcount=1, is_ref=0)='one',
1 => (refcount=2, is_ref=1)=…
)
“…”表示1指向a自身，是一个环形引用：
这时对$a进行unset,那么$a会从符号表中删除，同时$a指向的zval的refcount_gc减少1.
<?php
$a = array('one');
$a[] = &$a;
unset($a);
?>那么问题就产生了，$a已经不在符号表中，用户无法再访问此变量，但是$a之前指向的zval的refcount_gc变为1而不是0，因此不能被回收，从而产生内存泄露，新的GC要做的工作就是清理此类垃圾。
下面简单的介绍一下算法思路，在较新的PHP手册中有简单的介绍新的GC使用的垃圾清理算法，这个算法名为 Concurrent Cycle Collection in Reference Counted Systems（引用计数系统中的同步周期回收）。
首先有几个基本的准则：
1：如果一个zval的refcount_gc增加，那么此zval还在使用，不属于垃圾
2：如果一个zval的refcount减少到0， 那么zval可以被释放掉，不属于垃圾
3：如果一个zval的refcount减少之后大于0，那么此zval还不能被释放，此zval可能成为一个垃圾
算法介绍：
A：为避免不得不检查所有引用计数可能减少的垃圾周期，这个算法把所有可能根(possible roots 都是zval变量容器),放在根缓冲区(root buffer)中(用紫色来标记，称为疑似垃圾)，这样可以同时确保每个可能的垃圾根(possible garbage root)在缓冲区中只出现一次。仅仅在根缓冲区满了时，才对缓冲区内部所有不同的变量容器执行垃圾回收操作。
B：模拟删除每个紫色变量。模拟删除时可能将不是紫色的普通变量引用数减”1”，如果某个普通变量引用计数变成0了，就对这个普通变量再做一次模拟删除。每个变量只能被模拟删除一次，模拟删除后标记为灰。
C：模拟恢复每个紫色变量。恢复是有条件的，当变量的引用计数大于0时才对其做模拟恢复。同样每个变量只能恢复一次，恢复后标记为黑，基本就是步骤 B 的逆运算。这样剩下的一堆没能恢复的就是该删除的蓝色节点了，在步骤 D 中遍历出来真的删除掉。
算法中都是模拟删除、模拟恢复、真的删除，都使用简单的遍历即可（最典型的深搜遍历）。复杂度为执行模拟操作的节点数正相关，不只是紫色的那些疑似垃圾变量。
转载自：https://www.cnblogs.com/orlion/p/5350844.html
参考文档：
http://www.php-internals.com/book/
https://www.cnblogs.com/orlion/p/5350844.html
http://php.net/manual/zh/features.gc.refcounting-basics.php
http://php.net/manual/zh/features.gc.collecting-cycles.php