PHP5의 가비지 수집 알고리즘(가비지 수집)의 발전에 대한 간략한 토론

머리말

PHP는 관리되는 언어입니다. PHP 프로그래밍에서 프로그래머는 메모리 리소스 할당 및 해제를 수동으로 처리할 필요가 없습니다(C로 PHP 또는 Zend 확장을 작성할 때 제외). 가비지 수집 메커니즘(Garbage Collection) 자체를 구현합니다. 이제 공식 PHP 웹사이트(php.net)에 가면 현재 PHP5의 두 가지 버전인 PHP5.2와 PHP5.3이 별도로 업데이트된 것을 볼 수 있습니다. 이는 여전히 많은 프로젝트에서 PHP 5.2 버전을 사용하고 있기 때문입니다. , 5.3 버전은 5.2와 완전히 호환되지 않습니다. PHP5.3은 PHP5.2를 기반으로 많은 개선이 이루어졌는데, 그 중 가비지 컬렉션 알고리즘이 상대적으로 큰 변화입니다. 이 기사에서는 PHP5.2와 PHP5.3의 가비지 수집 메커니즘에 대해 각각 논의하고 이러한 발전과 개선이 PHP를 작성하는 프로그래머에게 미치는 영향과 그들이 주의해야 할 문제에 대해 논의할 것입니다.

PHP 변수 및 관련 메모리 개체의 내부 표현

가비지 수집은 궁극적으로 변수 및 관련 메모리 개체에 대한 작업이므로 PHP의 가비지 수집 메커니즘을 논의하기 전에 간략하게 소개하겠습니다. 내부 표현 PHP의 변수 및 해당 메모리 개체(C 소스 코드의 표현)

공식 PHP 문서에서는 PHP의 변수를 스칼라 유형과 복합 유형이라는 두 가지 범주로 나눕니다. 스칼라 유형에는 부울, 정수, 부동 소수점 유형 및 문자열이 포함됩니다. 복합 유형에는 배열, 객체 및 리소스가 포함되며 어떤 유형으로도 구분되지 않지만 별도의 범주가 되는 특수 NULL도 있습니다.

이러한 모든 유형은 PHP 내에서 zval이라는 구조로 균일하게 표시됩니다. PHP 소스 코드에서 이 구조의 이름은 "_zval_struct"입니다. zval의 구체적인 정의는 PHP 소스코드의 "Zend/zend.h" 파일에 있습니다. 다음은 관련 코드를 발췌한 것입니다.

typedef union _zvalue_value {
    long lval;                  /* long value */
    double dval;                /* double value */
    struct {
        char *val;
        int len;
    } str;
    HashTable *ht;              /* hash table value */
    zend_object_value obj;
} zvalue_value;
  
struct _zval_struct {
    /* Variable information */
    zvalue_value value;     /* value */
    zend_uint refcount__gc;
    zend_uchar type;    /* active type */
    zend_uchar is_ref__gc;
};

현재 zval(값의 유형은 _zvalue_value)의 값이 어떤 유형을 나타내는지는 "_zval_struct"의 유형에 따라 결정됩니다. _zval_struct는 C 언어에서 zval의 특정 구현입니다. 각 zval은 변수의 메모리 개체를 나타냅니다. 값과 유형 외에도 _zval_struct에 refcount__gc 및 is_ref__gc라는 두 개의 필드가 있음을 알 수 있습니다. 해당 접미사를 통해 이 두 필드가 가비지 수집과 관련이 있다는 결론을 내릴 수 있습니다. 그렇습니다. PHP의 가비지 수집은 전적으로 이 두 필드에 의존합니다. 그중 refcount__gc는 현재 이 zval을 참조하는 변수가 여러 개 있음을 나타내고, is_ref__gc는 현재 zval이 참조로 참조되는지 여부를 나타냅니다. 이는 PHP의 zval의 "Write-On-Copy" 메커니즘과 관련이 있습니다. 이 주제는 이 기사의 초점이므로 여기서는 자세히 설명하지 않겠습니다. 독자는 refcount__gc 필드의 역할만 기억하면 됩니다.

PHP5.2의 가비지 수집 알고리즘 - 참조 카운팅

PHP5.2에서 사용되는 메모리 재활용 알고리즘은 유명한 참조 카운팅입니다. 이 알고리즘을 중국어로 번역하면 "참조 카운팅"이라고 합니다. 아이디어는 매우 직관적이고 간결합니다. 각 메모리 개체에 카운터를 할당합니다. 메모리 개체가 생성되면 카운터는 1로 초기화됩니다(따라서 이때 새 변수가 참조할 때마다 항상 이 개체를 참조하는 변수가 있습니다). 이 메모리 개체에 대해 카운터는 1씩 증가하고 이 메모리 개체를 참조하는 변수가 줄어들 때마다 카운터는 1씩 감소합니다. 가비지 수집 메커니즘이 작동하면 카운터가 0인 모든 메모리 개체가 파괴되고 그들이 차지하는 메모리는 재활용됩니다. PHP의 메모리 개체는 zval이고 카운터는 refcount__gc입니다.

예를 들어 다음 PHP 코드는 PHP5.2 카운터의 작동 원리를 보여줍니다(카운터 값은 xdebug를 통해 얻음).

이 코드는 먼저 배열 a를 생성합니다. 그리고 a가 참조로 a를 가리키도록 합니다. 이때 a의 zval의 refcount는 2가 됩니다. 그러면 a가 처음에 가리키는 zval의 refcount는 1이 됩니다. , 그러나 아래 그림과 같이 순환 자기 참조를 형성하기 때문에 더 이상 작동할 방법이 없습니다.

其中灰色部分表示已经不复存在。由于a之前指向的zval的refcount为1（被其HashTable的第一个元素引用），这个zval就不会被GC销毁，这部分内存就泄露了。

这里特别要指出的是，PHP是通过符号表（Symbol Table）存储变量符号的，全局有一个符号表，而每个复杂类型如数组或对象有自己的符号表，因此上面代码中，a和a[0]是两个符号，但是a储存在全局符号表中，而a[0]储存在数组本身的符号表中，且这里a和a[0]引用同一个zval（当然符号a后来被销毁了）。希望读者朋友注意分清符号（Symbol）的zval的关系。

在PHP只用于做动态页面脚本时，这种泄露也许不是很要紧，因为动态页面脚本的生命周期很短，PHP会保证当脚本执行完毕后，释放其所有资源。但是PHP发展到目前已经不仅仅用作动态页面脚本这么简单，如果将PHP用在生命周期较长的场景中，例如自动化测试脚本或deamon进程，那么经过多次循环后积累下来的内存泄露可能就会很严重。这并不是我在耸人听闻，我曾经实习过的一个公司就通过PHP写的deamon进程来与数据存储服务器交互。

由于Reference Counting的这个缺陷，PHP5.3改进了垃圾回收算法。

PHP5.3中的垃圾回收算法——Concurrent Cycle Collection in Reference Counted Systems

PHP5.3的垃圾回收算法仍然以引用计数为基础，但是不再是使用简单计数作为回收准则，而是使用了一种同步回收算法，这个算法由IBM的工程师在论文Concurrent Cycle Collection in Reference Counted Systems中提出。

这个算法可谓相当复杂，从论文29页的数量我想大家也能看出来，所以我不打算（也没有能力）完整论述此算法，有兴趣的朋友可以阅读上面的提到的论文（强烈推荐，这篇论文非常精彩）。

我在这里，只能大体描述一下此算法的基本思想。

首先PHP会分配一个固定大小的“根缓冲区”，这个缓冲区用于存放固定数量的zval，这个数量默认是10,000，如果需要修改则需要修改源代码Zend/zend_gc.c中的常量GC_ROOT_BUFFER_MAX_ENTRIES然后重新编译。

由上文我们可以知道，一个zval如果有引用，要么被全局符号表中的符号引用，要么被其它表示复杂类型的zval中的符号引用。因此在zval中存在一些可能根（root）。这里我们暂且不讨论PHP是如何发现这些可能根的，这是个很复杂的问题，总之PHP有办法发现这些可能根zval并将它们投入根缓冲区。

当根缓冲区满额时，PHP就会执行垃圾回收，此回收算法如下：

1、对每个根缓冲区中的根zval按照深度优先遍历算法遍历所有能遍历到的zval，并将每个zval的refcount减1，同时为了避免对同一zval多次减1（因为可能不同的根能遍历到同一个zval），每次对某个zval减1后就对其标记为“已减”。

2、再次对每个缓冲区中的根zval深度优先遍历，如果某个zval的refcount不为0，则对其加1，否则保持其为0。

3、清空根缓冲区中的所有根（注意是把这些zval从缓冲区中清除而不是销毁它们），然后销毁所有refcount为0的zval，并收回其内存。

如果不能完全理解也没有关系，只需记住PHP5.3的垃圾回收算法有以下几点特性：

1、并不是每次refcount减少时都进入回收周期，只有根缓冲区满额后在开始垃圾回收。

2、可以解决循环引用问题。

3、可以总将内存泄露保持在一个阈值以下。

PHP5.2与PHP5.3垃圾回收算法的性能比较

由于我目前条件所限，我就不重新设计试验了，而是直接引用PHP Manual中的实验，关于两者的性能比较请参考PHP Manual中的相关章节：http://www.php.net/manual/en/features.gc.performance-considerations.php。

首先是内存泄露试验，下面直接引用PHP Manual中的实验代码和试验结果图：

<?php
class Foo
{
    public $var = &#39;3.1415962654&#39;;
}
  
$baseMemory = memory_get_usage();
  
for ( $i = 0; $i <= 100000; $i++ )
{
    $a = new Foo;
    $a->self = $a;
    if ( $i % 500 === 0 )
    {
        echo sprintf( &#39;%8d: &#39;, $i ), memory_get_usage() - $baseMemory, "\n";
    }
}
?>

PHP内存泄露试验

可以看到在可能引发累积性内存泄露的场景下，PHP5.2发生持续累积性内存泄露，而PHP5.3则总能将内存泄露控制在一个阈值以下（与根缓冲区大小有关）。

另外是关于性能方面的对比：

<?php
class Foo
{
    public $var = &#39;3.1415962654&#39;;
}
  
for ( $i = 0; $i <= 1000000; $i++ )
{
    $a = new Foo;
    $a->self = $a;
}
  
echo memory_get_peak_usage(), "\n";
?>

这个脚本执行1000000次循环，使得延迟时间足够进行对比。

然后使用CLI方式分别在打开内存回收和关闭内存回收的的情况下运行此脚本：

time php -dzend.enable_gc=0 -dmemory_limit=-1 -n example2.php
# and
time php -dzend.enable_gc=1 -dmemory_limit=-1 -n example2.php

在我的机器环境下，运行时间分别为6.4s和7.2s，可以看到PHP5.3的垃圾回收机制会慢一些，但是影响并不大。

与垃圾回收算法相关的PHP配置

可以通过修改php.ini中的zend.enable_gc来打开或关闭PHP的垃圾回收机制，也可以通过调用gc_enable()或gc_disable()打开或关闭PHP的垃圾回收机制。在PHP5.3中即使关闭了垃圾回收机制，PHP仍然会记录可能根到根缓冲区，只是当根缓冲区满额时，PHP不会自动运行垃圾回收，当然，任何时候您都可以通过手工调用gc_collect_cycles()函数强制执行内存回收。