孤独求学人

PHP 垃圾回收 机制:Zend GC详解

2012-11-17 杜世伟 Php

概述

在5.2及更早版本的PHP中，没有专门的垃圾回收器GC（Garbage Collection），引擎在判断一个变量空间

是否能够被释放的时候是依据这个变量的zval的refcount的值，如果refcount为0，那么变量的空间可以被释放

，否则就不释放，这是一种非常简单的GC实现。然而在这种简单的GC实现方案中，出现了意想不到的变量内

存泄漏情况（Bug:http://bugs.php.net/bug.php?id=33595），引擎将无法回收这些内存，于是在PHP5.3中出

现了新的GC，新的GC有专门的机制负责清理垃圾数据，防止内存泄漏。本文将详细的阐述PHP5.3中新的

GC运行机制。

目前很少有详细的资料介绍新的GC，本文将是目前国内最为详细的从源码角度介绍PHP5.3中GC原理的文章

。其中关于垃圾产生以及算法简介部分由笔者根据手册翻译而来，当然其中融入了本人的一些看法。手册中相

关内容：Garbage Collection

在介绍这个新的GC之前，读者必须先了解PHP中变量的内部存储相关知识，请先阅读 PHP原理之变量分离

/引用

什么算垃圾

首先我们需要定义一下“垃圾”的概念，新的GC负责清理的垃圾是指变量的容器zval还存在，但是又没有任何

变量名指向此zval。因此GC判断是否为垃圾的一个重要标准是有没有变量名指向变量容器zval。

假设我们有一段PHP代码，使用了一个临时变量$tmp存储了一个字符串，在处理完字符串之后，就不需要这

个$tmp变量了，$tmp变量对于我们来说可以算是一个“垃圾”了，但是对于GC来说，$tmp其实并不是一个垃圾

，$tmp变量对我们没有意义，但是这个变量实际还存在，$tmp符号依然指向它所对应的zval，GC会认为PHP代

码中可能还会使用到此变量，所以不会将其定义为垃圾。

那么如果我们在PHP代码中使用完$tmp后，调用unset删除这个变量，那么$tmp是不是就成为一个垃圾了呢

。很可惜，GC仍然不认为$tmp是一个垃圾，因为$tmp在unset之后，refcount减少1变成了0(这里假设没有别

的变量和$tmp指向相同的zval),这个时候GC会直接将$tmp对应的zval的内存空间释放，$tmp和其对应的zval就

根本不存在了。此时的$tmp也不是新的GC所要对付的那种“垃圾”。那么新的GC究竟要对付什么样的垃圾呢，

下面我们将生产一个这样的垃圾。

顽固垃圾的产生过程

如果读者已经阅读了变量内部存储相关的内容，想必对refcount和isref这些变量内部的信息有了一定的了解

。这里我们将结合手册中的一个例子来介绍垃圾的产生过程：

<?php

$a = "new string";

?>

在这么简单的一个代码中，$a变量内部存储信息为

a: (refcount=1, is_ref=0)='new string'

当把$a赋值给另外一个变量的时候，$a对应的zval的refcount会加1

<?php

$a = "new string";

$b = $a;

?>
此时$a和$b变量对应的内部存储信息为

a,b: (refcount=2, is_ref=0)='new string'

当我们用unset删除$b变量的时候，$b对应的zval的refcount会减少1

<?php

$a = "new string"; //a: (refcount=1, is_ref=0)='new string'

$b = $a; //a,b: (refcount=2, is_ref=0)='new string'

unset($b); //a: (refcount=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减少1

<?php

$a = array('one');

$a[] = &$a;

unset($a);

?>

那么问题也就产生了，$a已经不在符号表中了，用户无法再访问此变量，但是$a之前指向的zval的refcount变为1而不是0，因此不能被回收，这样产生了内存泄露：

这样，这么一个zval就成为了一个真是意义的垃圾了，新的GC要做的工作就是清理这种垃圾。

为解决这种垃圾，产生了新的GC

在PHP5.3版本中，使用了专门GC机制清理垃圾，在之前的版本中是没有专门的GC，那么垃圾产生的时候，没有办法清理，内存就白白浪费掉了。在PHP5.3源代码中多了以下文件:{PHPSRC}/Zend/zend_gc.h {PHPSRC}/Zend/zend_gc.c, 这里就是新的GC的实现，我们先简单的介绍一下算法思路，然后再从源码的角度详细介绍引擎中如何实现这个算法的。

新的GC算法

在较新的PHP手册中有简单的介绍新的GC使用的垃圾清理算法，这个算法名为 Concurrent Cycle Collection in Reference Counted Systems ， 这里不详细介绍此算法，根据手册中的内容来先简单的介绍一下思路：

首先我们有几个基本的准则：

1：如果一个zval的refcount增加，那么此zval还在使用，不属于垃圾

2：如果一个zval的refcount减少到0， 那么zval可以被释放掉，不属于垃圾

3：如果一个zval的refcount减少之后大于0，那么此zval还不能被释放，此zval可能成为一个垃圾

只有在准则3下，GC才会把zval收集起来，然后通过新的算法来判断此zval是否为垃圾。那么如何判断这么一个

变量是否为真正的垃圾呢？

简单的说，就是对此zval中的每个元素进行一次refcount减1操作，操作完成之后，如果zval的refcount=0，那么

这个zval就是一个垃圾。这个原理咋看起来很简单，但是又不是那么容易理解，起初笔者也无法理解其含义，

直到挖掘了源代码之后才算是了解。如果你现在不理解没有关系，后面会详细介绍，这里先把这算法的几个步

骤描叙一下,首先引用手册中的一张图:

A：为了避免每次变量的refcount减少的时候都调用GC的算法进行垃圾判断，此算法会先把所有前面准则3情况

下的zval节点放入一个节点(root)缓冲区(root buffer)，并且将这些zval节点标记成紫色，同时算法必须确保每一

个zval节点在缓冲区中之出现一次。当缓冲区被节点塞满的时候，GC才开始开始对缓冲区中的zval节点进行垃

圾判断。

B：当缓冲区满了之后，算法以深度优先对每一个节点所包含的zval进行减1操作，为了确保不会对同一个

zval的refcount重复执行减1操作，一旦zval的refcount减1之后会将zval标记成灰色。需要强调的是，这个步骤

中，起初节点zval本身不做减1操作，但是如果节点zval中包含的zval又指向了节点zval（环形引用），那么这个

时候需要对节点zval进行减1操作。

C：算法再次以深度优先判断每一个节点包含的zval的值，如果zval的refcount等于0，那么将其标记成白色(代

表垃圾)，如果zval的refcount大于0，那么将对此zval以及其包含的zval进行refcount加1操作，这个是对非垃圾

的还原操作，同时将这些zval的颜色变成黑色（zval的默认颜色属性）

D：遍历zval节点，将C中标记成白色的节点zval释放掉。

这ABCD四个过程是手册中对这个算法的介绍，这还不是那么容易理解其中的原理，这个算法到底是个什么意

思呢？我自己的理解是这样的：

比如还是前面那个变成垃圾的数组$a对应的zval,命名为zval_a, 如果没有执行unset， zval_a的refcount为2,分

别由$a和$a中的索引1指向这个zval。 用算法对这个数组中的所有元素（索引0和索引1）的zval的refcount进

行减1操作，由于索引1对应的就是zval_a，所以这个时候zval_a的refcount应该变成了1，这样zval_a就不是一

个垃圾。如果执行了unset操作，zval_a的refcount就是1，由zval_a中的索引1指向zval_a,用算法对数组中的所

有元素（索引0和索引1）的zval的refcount进行减1操作，这样zval_a的refcount就会变成0，于是就发现

zval_a是一个垃圾了。 算法就这样发现了顽固的垃圾数据。

举了这个例子，读者大概应该能够知道其中的端倪：

对于一个包含环形引用的数组，对数组中包含的每个元素的zval进行减1操作，之后如果发现数组自身的zval的

refcount变成了0，那么可以判断这个数组是一个垃圾。

这个道理其实很简单，假设数组a的refcount等于m, a中有n个元素又指向a,如果m等于n,那么算法的结果是m减

n，m-n=0，那么a就是垃圾，如果m>n,那么算法的结果m-n>0,所以a就不是垃圾了

m=n代表什么？ 代表a的refcount都来自数组a自身包含的zval元素,代表a之外没有任何变量指向它，代表用户

代码空间中无法再访问到a所对应的zval，代表a是泄漏的内存，因此GC将a这个垃圾回收了。

(ps:我的理解是:在引用的情况会出现内存泄漏,新的算法遍历缓冲区,对指向的zval的refcount减1,如果zval的is_ref>0,说明存在被引用的情况,再用refcount-is_ref如果等于0说明是垃圾。如果单纯的是其他的变量指向zval,refcount-1到0就正常是释放了)

PHP中运用新的GC的算法

在PHP中，GC默认是开启的，你可以通过ini文件中的 zend.enable_gc 项来开启或则关闭GC。当GC开启的

时候，垃圾分析算法将在节点缓冲区(roots buffer)满了之后启动。缓冲区默认可以放10,000个节点，当然你也

可以通过修改Zend/zend_gc.c中的GC_ROOT_BUFFER_MAX_ENTRIES 来改变这个数值，需要重新编译链接

PHP。当GC关闭的时候，垃圾分析算法就不会运行，但是相关节点还会被放入节点缓冲区，这个时候如果缓冲

区节点已经放满，那么新的节点就不会被记录下来，这些没有被记录下来的节点就永远也不会被垃圾分析算法

分析。如果这些节点中有循环引用，那么有可能产生内存泄漏。之所以在GC关闭的时候还要记录这些节点，是

因为简单的记录这些节点比在每次产生节点的时候判断GC是否开启更快，另外GC是可以在脚本运行中开启的

，所以记录下这些节点，在代码运行的某个时候如果又开启了GC，这些节点就能被分析算法分析。当然垃圾分

析算法是一个比较耗时的操作。

在PHP代码中我们可以通过gc_enable()和gc_disable()函数来开启和关闭GC，也可以通过调用

gc_collect_cycles()在节点缓冲区未满的情况下强制执行垃圾分析算法。这样用户就可以在程序的某些部分关闭

或则开启GC，也可强制进行垃圾分析算法。session的销毁机制就是用概率开启GC进程对session进行过期销

毁：它并没有一个daemon线程来定期的扫描Session信息并判断其是否失效，当一个有效的请求发生时，PHP

会根据全局变量 session.gc_probability和session.gc_divisor的值，来决定是否启用一个GC, 在默认情况下，

session.gc_probability=1, session.gc_divisor =100也就是说有1%的可能性启动GC(也就是说100个请求中只有

一个gc会伴随100个中的某个请求而启动).

GC的工作就是扫描所有的Session信息，用当前时间减去session最后修改的时间，同

session.gc_maxlifetime参数进行比较，如果生存时间超过gc_maxlifetime(默认24分钟),就将该session删除。

但是，如果你Web服务器有多个站点，多个站点时,GC处理session可能会出现意想不到的结果，原因就是：

GC在工作时，并不会区分不同站点的session.

那么这个时候怎么解决呢？

1. 修改session.save_path,或使用session_save_path()让每个站点的session保存到一个专用目录，

2. 提供GC的启动率，自然，GC的启动率提高，系统的性能也会相应减低，不推荐。

3. 在代码中判断当前session的生存时间，利用session_destroy()删除.

新的GC算法的性能

1.防止泄漏节省内存

新的GC算法的目的就是为了防止循环引用的变量引起的内存泄漏问题，在PHP中GC算法，当节点缓冲区满

了之后，垃圾分析算法会启动，并且会释放掉发现的垃圾，从而回收内存，在PHP手册上给了一段代码和内存

使用状况图：

2：运行效率影响

启用了新的GC后，垃圾分析算法将是一个比较耗时的操作，手册中给了一段测试代码：

(v) = ((gc_root_buffer*)((((zend_uintptr_t)(v)) & GC_COLOR) | ((zend_uintptr_t)(a))))

为什么需要这么一个复杂的过程，而且设置指针值为何还要牵扯到GC_COLOR颜色这个宏？

这里就得先说说节点的颜色信息保存方式。

在前面GC的算法简介中，提到了需要为节点上色，而实际在我们节点结构gc_root_buffer中并没有哪一个字段

用来标识节点的颜色，这里GC运用了一个小的技巧：利用节点指针的低两位来标识颜色属性。可能读者会有疑

问，用指针中的位来保存颜色属性，那么设置颜色后，指针不就变化了吗，那么还能查找到指针对应的结构吗

？ 这个还真能查到！ 为什么？ 这个和malloc分配的内存地址属性有一定的关系，glib的malloc分配的内存地址

都会有一定的对齐，这个对齐值为2 * SIZE_SZ,在不同位的机器上这个值是不一样的，但是可以确保的是分配

出来的指针的最低两位肯定是0，然后看看颜色相关的宏，GC_COLOR为0x03, 3只需要两个二进制位就能够保

存，所以拿指针的最低两位来保存颜色值是没有任何问题的，但是在使用指针的时候一定要先把指针最低的两

位还原成0，否则指针指向的值是错误的。

这样我们就能理解为什么GC_ADDRESS需要这么复杂了。因为v中的低2位保存了v的颜色信息，如果直接把

a赋给v会覆盖掉颜色信息，通过((zend_uintptr_t)(v)) & GC_COLOR可以保留低两位的颜色信息，同时其它的

位都变成了0，将这个结果同a进行"|"操作，就能将a的赋给v,同时保留了v的颜色信息。

知道了颜色信息的存储方式，那么就应该很容易理解如何设置和获取颜色信息，这里就不多介绍了。

4.节点缓冲区

GC会将收集到的节点存放到一个缓冲区中，缓冲区满的时候就开始进行垃圾分析算法。这个缓冲区实际上放

在一个全局的结构中：

用宏GC_G(v)可以访问结构中的v字段。

简单的介绍这个结构中几个重要的字段的含义:

zend_bool gc_enabled:

是否开启GC

zend_bool gc_active:

GC是否正在进行垃圾分析

gc_root_buffer *buf：

节点缓冲区指针，在GC初始化的时候，会分配10,000个gc_root_buffer结构的空间，buf为第1个节点的地址

gc_root_buffer roots;

GC每次开始垃圾分析算法的时候，都是从这个节点开始进行(注意不是直接在缓冲区中按顺序来分析节点，

缓冲区值是存放节点信息内容，roots是分析的节点入口，是一个双链表的入口)

其他节点和垃圾分析过程中的一些临时数据有关，这里暂不介绍。

5.GC的初始化

首先在初始化之前会有一个全局变量

extern ZEND_API zend_gc_globals gc_globals;

在整个GC运行期间都依赖这个全局变量结构。

初始化是调用的gc_init函数，如果缓冲区指针字段为空并且GC开启，那么就分配缓冲区，然后调用gc_reset初始化全局结构gc_globals中的相关字段。

6.节点放入缓冲区的时机

那么现在就是一个比较关键的一步了，GC何时为zval设置节点信息，并将节点信息设置放入缓冲区等待分析

处理。从前面介绍的GC算法的原理中，准则3：“如果一个zval的refcount减少之后大于0，那么此zval还不能被

释放，此zval可能成为一个垃圾”。我们大概可以知道当一个zval的refcount减少的时候，GC有可能为zval分配

节点并放入缓冲区。那么在什么情况下zval的refcount会减少。 在我们调用unset的时候，会从当前符号的哈希

表中删除变量名对应的项，并对该项调用一个析构函数，所以这个refcount减少的操作发生在这个析构函数中

。通过建立变量符号哈希表的代码段可以知道这个析构函数是什么。这个析构函数最终的实现在

Zend/zend_execute_API.c中：

这个函数中：

Z_DELREF_PP(zval_ptr) ：对zval的refcount减1，减1之后

1.如果zval的refcount等于0,根据前面的准则2，这个变量的空间可以直接被释放掉，在释放之前需要注意，有

可能这个变量在之前已经被放入了节点缓冲区，所以需要调用

GC_REMOVE_ZVAL_FROM_BUFFER(*zval_ptr)从节点缓冲区中删除相关节点信息，然后调用zval_dtor和

efree_rel释放掉变量zval中变量占用的空间和zval结构自身的空间。

2.如果zval的refcount等于1,根据前面的准则3，这个变量有可能会成为一个垃圾，于是调用

GC_ZVAL_CHECK_POSSIBLE_ROOT(*zval_ptr)为其设置节点信息并放入缓冲区

因此，最终是通过GC_ZVAL_CHECK_POSSIBLE_ROOT宏来产生节点并放入缓冲等待处理，相关的宏和函数

代码为：

内联函数gc_zval_check_possible_root会先判断zval的类型，如果是数组或则对象类型才有可能给zval分配节

点信息并放入缓冲区。只有这两种类型才可能产生环形引用。虽然GC直接处理对象是数组和对象类型，但是在

这些数组和对象中包含的任何类型变量都在GC的职责范围之内，这个内联函数最终掉用的是

gc_zval_possible_root函数，下面重点分析此函数中的主要流程：

1：

if (UNEXPECTED(GC_G(free_list) != NULL &&
GC_ZVAL_ADDRESS(zv) != NULL &&
GC_ZVAL_GET_COLOR(zv) == GC_BLACK) &&
(GC_ZVAL_ADDRESS(zv) < GC_G(buf) ||
GC_ZVAL_ADDRESS(zv) >= GC_G(last_unused))) {
/* The given zval is a garbage that is going to be deleted by
* currently running GC */
return;
}

首先检查zval节点信息是否已经放入到节点缓冲区，如果已经放入到节点缓冲区，则直接返回，这样保证节点

缓冲区中的每个zval节点只出现一次。

2：

if (zv->type == IS_OBJECT) {
GC_ZOBJ_CHECK_POSSIBLE_ROOT(zv);
return;
}

如果zval是对象类型，则走对象类型相关的流程，本文只以数组类型为例讲解，所以这个流程不阐述，读者可

以举一反三。

3:

if (GC_ZVAL_GET_COLOR(zv) != GC_PURPLE) {
GC_ZVAL_SET_PURPLE(zv);

...

}

如果zval没有被标记为紫色，就将其标记为紫色，表示zval被放入到节点缓冲，否则不做后面的操作。

4:

如果zval的节点信息指针为空，则需要为zval分配一个gc_root_buffer节点信息。这之后会有一些判断机制，如

果发现节点缓冲区已经满了说明需要启动垃圾分析流程了，垃圾分析流程在函数

gc_collect_cycles(TSRMLS_C); 如果缓冲区没有满，则不会进入垃圾分析流程，为zval分配的节点信息会被加

入到GC_G(roots)为入口的双链表中。

从这个函数我们发现了垃圾分析算法是当发现缓冲区满的时候就立即触发，垃圾分析跟代码执行流是同步过程

，也就是只有垃圾分析结束之后，代码才会继续执行。所以在我们的PHP代码中，如果某个unset正好使GC的

节点缓冲区满，触发了垃圾分析流程，那么这个unset耗费的时间将比一般的unset多很多。

gc_collect_cycles函数是真正的垃圾分析流程，这个函数定义为:

这里只简单的介绍其中关键的流程:

1.gc_mark_roots（）

这个函数对节点信息的链表进行一次深度优先遍历，将其中的zval的refcount减1，为了避免对同一个zval重复减操作，在操作之后将zval标记成灰色。（对节点自身的zval可以重复减操作，这个是此算法的基础）

2.gc_scan_roots()

这个函数对节点信息的链表再次进行深度优先遍历，如果发现zval的refcount大于等于1，则对该zval和其包含

的zval的refcount加1操作，这个是对非垃圾的一个信息还原，然后将这些zval颜色属性去掉(设置成black)。如

果发现zval的refcount等于0，则就标记成白色，这些是后面将要清理掉的垃圾。

3.gc_collect_roots()

遍历节点信息链表,将前面一个步骤中标记为白色的节点信息放到GC_G(zval_to_free)为入口的链表中，这个

链表用来存放将要释放的垃圾。 然后释放掉全部的节点信息，缓冲区被清空。分析结束后将重新收集节点信息

4.释放步骤3中收集到垃圾数据。

转自:http://blog.csdn.net/phpkernel/article/details/5734743

标签: PHP 垃圾 回收