PHP5의 가비지 수집 메커니즘의 진화 분석-PHP 튜토리얼-php.cn

머리말

PHP는 관리되는 언어입니다. PHP 프로그래밍에서 프로그래머는 메모리 리소스 할당 및 해제를 수동으로 처리할 필요가 없습니다(C로 PHP 또는 Zend 확장을 작성할 때 제외). 이는 PHP 자체가 가비지 수집 메커니즘을 구현함을 의미합니다. (쓰레기 수집). 이제 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;
};

로그인 후 복사

Union "_zvalue_value"는 PHP에서 모든 변수의 값을 나타내는 데 사용됩니다. 여기서 Union을 사용하는 이유는 zval이 한 번에 한 가지 유형의 변수만 나타낼 수 있기 때문입니다. _zvalue_value에는 5개의 필드만 있는 것을 볼 수 있는데, PHP에는 NULL을 포함하여 8개의 데이터 유형이 있습니다. 그렇다면 PHP는 내부적으로 8개의 유형을 표현하기 위해 어떻게 5개의 필드를 사용합니까? 이는 PHP 디자인의 가장 영리한 측면 중 하나입니다. 필드를 재사용하여 필드를 줄이는 목적을 달성합니다. 예를 들어, PHP 내에서 부울 유형, 정수 및 자원(리소스의 식별자가 저장되는 경우)은 lval 필드를 통해 저장됩니다. str은 문자열을 저장하는 데 사용됩니다. PHP에서 배열은 실제로 해시 테이블입니다. obj는 객체 유형을 저장합니다. 모든 필드가 0 또는 NULL로 설정되면 PHP에서는 NULL을 의미하므로 8가지 유형의 값을 저장하는 데 5개의 필드가 사용됩니다.

현재 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에서 사용되는 메모리 재활용 알고리즘은 유명한 참조 계산입니다. 이 알고리즘을 중국어로 번역하면 그 아이디어가 매우 직관적이고 간결합니다. 각 A 카운터는 메모리 개체에 할당됩니다. 메모리 개체가 생성되면 카운터는 1로 초기화됩니다(따라서 이 시점에서 새 변수가 이 메모리 개체를 참조할 때마다 항상 이 개체를 참조하는 변수가 있습니다). 카운터는 1씩 증가하며, 이 메모리 개체를 참조하는 변수가 감소할 때마다 카운터는 1씩 감소합니다. 가비지 수집 메커니즘이 작동하면 카운터가 0인 모든 메모리 개체가 삭제되고 해당 개체가 차지하는 메모리가 삭제됩니다. 재활용됩니다. PHP의 메모리 개체는 zval이고 카운터는 refcount__gc입니다.

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

<?php
 
$val1 = 100; //zval(val1).refcount_gc = 1;
$val2 = $val1; //zval(val1).refcount_gc = 2,zval(val2).refcount_gc = 2(因为是Write on copy，当前val2与val1共同引用一个zval)
$val2 = 200; //zval(val1).refcount_gc = 1,zval(val2).refcount_gc = 1(此处val2新建了一个zval)
unset($val1); //zval(val1).refcount_gc = 0($val1引用的zval再也不可用，会被GC回收)
 
?>
Reference Counting简单直观，实现方便，但却存在一个致命的缺陷，就是容易造成内存泄露。很多朋友可能已经意识到了，如果存在循环引用，那么Reference Counting就可能导致内存泄露。例如下面的代码：
<?php
$a = array();
$a[] = & $a;
unset($a);
 
?>

로그인 후 복사

이 코드는 먼저 배열 a를 생성한 다음 a의 첫 번째 요소를 허용합니다. 이때 a의 zval의 refcount는 2가 되고, 이때 a가 처음에 가리키는 zval의 refcount는 1이 되지만 더 이상 연산을 할 수 없게 된다. 그림에 표시된 대로:

PHP5의 가비지 수집 메커니즘의 진화 분석

회색 부분은 더 이상 존재하지 않음을 의미합니다. a가 가리키는 zval의 참조 횟수가 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";
    }
}
?>

로그인 후 복사

PHP5의 가비지 수집 메커니즘의 진화 분석

可以看到在可能引发累积性内存泄露的场景下，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를 수동으로 호출할 수 있습니다. () 함수는 메모리 재활용을 강제합니다.

위 내용은 PHP5의 가비지 수집 메커니즘의 진화 분석의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!