• 首页
  • vue
  • TypeScript
  • JavaScript
  • scss
  • css3
  • html5
  • php
  • MySQL
  • redis
  • jQuery
  • 垃圾回收机制

    引用计数基本知识

    每个php变量存在一个叫"zval"的变量容器中。一个zval变量容器,除了包含变量的类型和值,还包括两个字节的额外信息。第一个是"is_ref",是个bool值,用来标识这个变量是否是属于引用集合(reference set)。通过这个字节,php引擎才能把普通变量和引用变量区分开来,由于php允许用户通过使用&来使用自定义引用,zval变量容器中还有一个内部引用计数机制,来优化内存使用。第二个额外字节是"refcount",用以表示指向这个zval变量容器的变量(也称符号即symbol)个数。所有的符号存在一个符号表中,其中每个符号都有作用域(scope),那些主脚本(比如:通过浏览器请求的的脚本)和每个函数或者方法也都有作用域。

    当一个变量被赋常量值时,就会生成一个zval变量容器,如下例这样:

    Example #1 生成一个新的zval容器

    <?php
    $a = "new string";
    ?>
    

    在上例中,新的变量a,是在当前作用域中生成的。并且生成了类型为 string 和值为new string的变量容器。在额外的两个字节信息中,"is_ref"被默认设置为FALSE,因为没有任何自定义的引用生成。"refcount"被设定为1,因为这里只有一个变量使用这个变量容器。注意到当"refcount"的值是1时,"is_ref"的值总是FALSE.如果你已经安装了» Xdebug,你能通过调用函数xdebug_debug_zval()显示"refcount"和"is_ref"的值。

    Example #2 显示zval信息

    <?php
    xdebug_debug_zval('a');
    ?>
    

    以上例程会输出:

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

    把一个变量赋值给另一变量将增加引用次数(refcount).

    Example #3 增加一个zval的引用计数

    <?php
    $a = "new string";
    $b = $a;
    xdebug_debug_zval( 'a' );
    ?>
    

    以上例程会输出:

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

    这时,引用次数是2,因为同一个变量容器被变量a和变量b关联。当没必要时,php不会去复制已生成的变量容器。变量容器在”refcount“变成0时就被销毁。当任何关联到某个变量容器的变量离开它的作用域(比如:函数执行结束),或者对变量调用了函数 unset()时,”refcount“就会减1,下面的例子就能说明:

    Example #4 减少引用计数

    <?php
    $a = "new string";
    $c = $b = $a;
    xdebug_debug_zval( 'a' );
    unset( $b, $c );
    xdebug_debug_zval( 'a' );
    ?>
    

    以上例程会输出:

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

    如果我们现在执行unset($a);,包含类型和值的这个变量容器就会从内存中删除。

    复合类型(Compound Types)

    当考虑像 array和object这样的复合类型时,事情就稍微有点复杂。与标量(scalar)类型的值不同,array和 object类型的变量把它们的成员或属性存在自己的符号表中。这意味着下面的例子将生成三个zval变量容器。

    Example #5 Creating a array zval

    <?php
    $a = array( 'meaning' => 'life', 'number' => 42 );
    xdebug_debug_zval( 'a' );
    ?>
    

    以上例程的输出类似于:

    a: (refcount=1, is_ref=0)=array (
       'meaning' => (refcount=1, is_ref=0)='life',
       'number' => (refcount=1, is_ref=0)=42
    )
    

    图示:

    从以上的xdebug输出信息,我们看到原有的数组元素和新添加的数组元素关联到同一个"refcount"2的zval变量容器。尽管 Xdebug的输出显示两个值为'life'的 zval 变量容器,其实是同一个。函数xdebug_debug_zval()不显示这个信息,但是你能通过显示内存指针信息来看到。

    删除数组中的一个元素,就是类似于从作用域中删除一个变量。删除后,数组中的这个元素所在的容器的“refcount”值减少,同样,当“refcount”为0时,这个变量容器就从内存中被删除,下面又一个例子可以说明:

    Example #7 从数组中删除一个元素

    <?php
    $a = array( 'meaning' => 'life', 'number' => 42 );
    $a['life'] = $a['meaning'];
    unset( $a['meaning'], $a['number'] );
    xdebug_debug_zval( 'a' );
    ?>
    

    以上例程的输出类似于:

    a: (refcount=1, is_ref=0)=array (
       'life' => (refcount=1, is_ref=0)='life'
    )
    

    现在,当我们添加一个数组本身作为这个数组的元素时,事情就变得有趣,下个例子将说明这个。例中我们加入了引用操作符,否则php将生成一个复制。

    Example #8 把数组作为一个元素添加到自己

    <?php
    $a = array( 'one' );
    $a[] =& $a;
    xdebug_debug_zval( 'a' );
    ?>
    

    以上例程的输出类似于:

    a: (refcount=2, is_ref=1)=array (
       0 => (refcount=1, is_ref=0)='one',
       1 => (refcount=2, is_ref=1)=...
    )
    

    图示:

    能看到数组变量(a)同时也是这个数组的第二个元素(1)指向的变量容器中“refcount”为2。上面的输出结果中的"..."说明发生了递归操作,显然在这种情况下意味着"..."指向原始数组。

    跟刚刚一样,对一个变量调用unset,将删除这个符号,且它指向的变量容器中的引用次数也减1。所以,如果我们在执行完上面的代码后,对变量$a调用unset,那么变量$a和数组元素"1"所指向的变量容器的引用次数减1,从"2"变成"1".下例可以说明:

    Example #9 Unsetting$a

    (refcount=1, is_ref=1)=array (
       0 => (refcount=1, is_ref=0)='one',
       1 => (refcount=1, is_ref=1)=...
    )
    

    图示:

    清理变量容器的问题(Cleanup Problems)

    尽管不再有某个作用域中的任何符号指向这个结构(就是变量容器),由于数组元素“1”仍然指向数组本身,所以这个容器不能被清除。因为没有另外的符号指向它,用户没有办法清除这个结构,结果就会导致内存泄漏。庆幸的是,php将在脚本执行结束时清除这个数据结构,但是在php清除之前,将耗费不少内存。如果你要实现分析算法,或者要做其他像一个子元素指向它的父元素这样的事情,这种情况就会经常发生。当然,同样的情况也会发生在对象上,实际上对象更有可能出现这种情况,因为对象总是隐式的被引用。

    如果上面的情况发生仅仅一两次倒没什么,但是如果出现几千次,甚至几十万次的内存泄漏,这显然是个大问题。这样的问题往往发生在长时间运行的脚本中,比如请求基本上不会结束的守护进程(deamons)或者单元测试中的大的套件(sets)中。后者的例子:在给巨大的eZ(一个知名的PHP Library)组件库的模板组件做单元测试时,就可能会出现问题。有时测试可能需要耗用2GB的内存,而测试服务器很可能没有这么大的内存。

    If a variable is not present in the current scope xdebug_debug_zval will return null.
    There seems to be no way to inspect the reference count of a specific class variable but you can view the reference count of all variables in the current class instance with xdebug_debug_zval('this');
    Result of "Example #8 Adding the array itself as an element of it self" will be another for PHP7:
    a: (refcount=2, is_ref=1)=array (
      0 => (refcount=2, is_ref=0)='one',
      1 => (refcount=2, is_ref=1)=...
    )
    insted of:
    a: (refcount=2, is_ref=1)=array (
      0 => (refcount=1, is_ref=0)='one',
      1 => (refcount=2, is_ref=1)=...
    )
    Internal value representation in PHP 7:
    https://nikic.github.io/2015/05/05/Internal-value-representation-in-PHP-7-part-1.html
    my php version is PHP 7.1.6 (cli), when I run 
    $a = 'new string';
    $b = 1;
    xdebug_debug_zval('a');
    xdebug_debug_zval('b');
    it shows:
    a: (refcount=0, is_ref=0)='new string'
    b: (refcount=0, is_ref=0)=1
    $a = 'new string';
    $b = 1;
    xdebug_debug_zval('a');
    xdebug_debug_zval('b');
    ouputs with PHP 7.3.12 (cli) 
    a: (interned, is_ref=0)='new string'
    b: (refcount=0, is_ref=0)=1
    my php versoin : HP 7.1.25 (cli) (built: Dec 7 2018 08:20:45) ( NTS )
    $a = 'new string';
    $b = 1;
    xdebug_debug_zval('a');
    xdebug_debug_zval('b');
    output:
    a: (refcount=2, is_ref=0)='new string'
    b: (refcount=0, is_ref=0)=1
    if $a is a string value, 'refcount' equal 2 by defalut.

    回收周期(Collecting Cycles)

    传统上,像以前的 php 用到的引用计数内存机制,无法处理循环的引用内存泄漏。然而 5.3.0 PHP 使用文章»引用计数系统中的同步周期回收(Concurrent Cycle Collection in Reference Counted Systems)中的同步算法,来处理这个内存泄漏问题。

    对算法的完全说明有点超出这部分内容的范围,将只介绍其中基础部分。首先,我们先要建立一些基本规则,如果一个引用计数增加,它将继续被使用,当然就不再在垃圾中。如果引用计数减少到零,所在变量容器将被清除(free)。就是说,仅仅在引用计数减少到非零值时,才会产生垃圾周期(garbage cycle)。其次,在一个垃圾周期中,通过检查引用计数是否减1,并且检查哪些变量容器的引用次数是零,来发现哪部分是垃圾。

    为避免不得不检查所有引用计数可能减少的垃圾周期,这个算法把所有可能根(possible roots 都是zval变量容器),放在根缓冲区(root buffer)中(用紫色来标记,称为疑似垃圾),这样可以同时确保每个可能的垃圾根(possible garbage root)在缓冲区中只出现一次。仅仅在根缓冲区满了时,才对缓冲区内部所有不同的变量容器执行垃圾回收操作。看上图的步骤 A。

    在步骤 B 中,模拟删除每个紫色变量。模拟删除时可能将不是紫色的普通变量引用数减"1",如果某个普通变量引用计数变成0了,就对这个普通变量再做一次模拟删除。每个变量只能被模拟删除一次,模拟删除后标记为灰(原文说确保不会对同一个变量容器减两次"1",不对的吧)。

    在步骤 C 中,模拟恢复每个紫色变量。恢复是有条件的,当变量的引用计数大于0时才对其做模拟恢复。同样每个变量只能恢复一次,恢复后标记为黑,基本就是步骤 B 的逆运算。这样剩下的一堆没能恢复的就是该删除的蓝色节点了,在步骤 D 中遍历出来真的删除掉。

    算法中都是模拟删除、模拟恢复、真的删除,都使用简单的遍历即可(最典型的深搜遍历)。复杂度为执行模拟操作的节点数正相关,不只是紫色的那些疑似垃圾变量。

    现在,你已经对这个算法有了基本了解,我们回头来看这个如何与PHP集成。默认的,PHP的垃圾回收机制是打开的,然后有个php.ini设置允许你修改它:zend.enable_gc

    当垃圾回收机制打开时,每当根缓存区存满时,就会执行上面描述的循环查找算法。根缓存区有固定的大小,可存10,000个可能根,当然你可以通过修改PHP源码文件Zend/zend_gc.c中的常量GC_ROOT_BUFFER_MAX_ENTRIES,然后重新编译PHP,来修改这个10,000值。当垃圾回收机制关闭时,循环查找算法永不执行,然而,可能根将一直存在根缓冲区中,不管在配置中垃圾回收机制是否激活。

    当垃圾回收机制关闭时,如果根缓冲区存满了可能根,更多的可能根显然不会被记录。那些没被记录的可能根,将不会被这个算法来分析处理。如果他们是循环引用周期的一部分,将永不能被清除进而导致内存泄漏。

    即使在垃圾回收机制不可用时,可能根也被记录的原因是,相对于每次找到可能根后检查垃圾回收机制是否打开而言,记录可能根的操作更快。不过垃圾回收和分析机制本身要耗不少时间。

    除了修改配置zend.enable_gc,也能通过分别调用gc_enable()和 gc_disable()函数来打开和关闭垃圾回收机制。调用这些函数,与修改配置项来打开或关闭垃圾回收机制的效果是一样的。即使在可能根缓冲区还没满时,也能强制执行周期回收。你能调用gc_collect_cycles()函数达到这个目的。这个函数将返回使用这个算法回收的周期数。

    允许打开和关闭垃圾回收机制并且允许自主的初始化的原因,是由于你的应用程序的某部分可能是高时效性的。在这种情况下,你可能不想使用垃圾回收机制。当然,对你的应用程序的某部分关闭垃圾回收机制,是在冒着可能内存泄漏的风险,因为一些可能根也许存不进有限的根缓冲区。因此,就在你调用gc_disable()函数释放内存之前,先调用gc_collect_cycles()函数可能比较明智。因为这将清除已存放在根缓冲区中的所有可能根,然后在垃圾回收机制被关闭时,可留下空缓冲区以有更多空间存储可能根。

    Memory leak: meaning you keep a reference to it thus preventing the GC from collecting it.
    ── Unused Objects ─── ─ In use Objects
    ↓          ↓        ↓
     _____________________________________
     |□□□□□□□□□□□□□□□□□|██■■■■■■■■■■■■■■■■|
     |□□□□□□□□□□□□□□□□□|██■■■■■■■■■■■■■■■■|
    ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
         ▲         ▲
       Unreferenced    Referenced
        Objects       Objects
    █ Memory leak
    After testing, breaking up memory intensive code into a separate function allows the garbage collection to work.
    For example the original code was like:-
    while(true){
      //do memory intensive code
    }
    can be turned into something like:-
    function intensive($parameters){
      //do memory intensive code
    }
    while(true){
      intensive($parameters);
    }

    性能方面考虑的因素

    在上一节我们已经简单的提到:回收可能根有细微的性能上影响,但这是把PHP 5.2与PHP 5.3比较时才有的。尽管在PHP 5.2中,记录可能根相对于完全不记录可能根要慢些,而PHP 5.3中对 PHP run-time 的其他修改减少了这个性能损失。

    这里主要有两个领域对性能有影响。第一个是内存占用空间的节省,另一个是垃圾回收机制执行内存清理时的执行时间增加(run-time delay)。我们将研究这两个领域。

    内存占用空间的节省

    首先,实现垃圾回收机制的整个原因是为了,一旦先决条件满足,通过清理循环引用的变量来节省内存占用。在PHP执行中,一旦根缓冲区满了或者调用gc_collect_cycles()函数时,就会执行垃圾回收。在下图中,显示了下面脚本分别在PHP 5.2 和 PHP 5.3环境下的内存占用情况,其中排除了脚本启动时PHP本身占用的基本内存。

    Example #1 Memory usage example

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

    在这个很理论性的例子中,我们创建了一个对象,这个对象中的一个属性被设置为指回对象本身。在循环的下一个重复(iteration)中,当脚本中的变量被重新复制时,就会发生典型性的内存泄漏。在这个例子中,两个变量容器是泄漏的(对象容器和属性容器),但是仅仅能找到一个可能根:就是被unset的那个变量。在10,000次重复后(也就产生总共10,000个可能根),当根缓冲区满时,就执行垃圾回收机制,并且释放那些关联的可能根的内存。这从PHP 5.3的锯齿型内存占用图中很容易就能看到。每次执行完10,000次重复后,执行垃圾回收,并释放相关的重复使用的引用变量。在这个例子中由于泄漏的数据结构非常简单,所以垃圾回收机制本身不必做太多工作。从这个图表中,你能看到 PHP 5.3的最大内存占用大概是9 Mb,而PHP 5.2的内存占用一直增加。

    执行时间增加(Run-Time Slowdowns)

    垃圾回收影响性能的第二个领域是它释放已泄漏的内存耗费的时间。为了看到这个耗时时多少,我们稍微改变了上面的脚本,有更多次数的重复并且删除了循环中的内存占用计算,第二个脚本代码如下:

    Example #2 GC性能影响

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

    我们将运行这个脚本两次,一次通过配置zend.enable_gc打开垃圾回收机制时,另一次是它关闭时。

    Example #3 执行以上脚本

    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

    在我的机器上,第一个命令持续执行时间大概为10.7秒,而第二个命令耗费11.4秒。时间上增加了7%。然而,执行这个脚本时内存占用的峰值降低了98%,从931Mb 降到 10Mb。这个基准不是很科学,或者并不能代表真实应用程序的数据,但是它的确显示了垃圾回收机制在内存占用方面的好处。好消息就是,对这个脚本而言,在执行中出现更多的循环引用变量时,内存节省的更多的情况下,每次时间增加的百分比都是7%。

    PHP内部 GC 统计信息

    在PHP内部,可以显示更多的关于垃圾回收机制如何运行的信息。但是要显示这些信息,你需要先重新编译PHP使benchmark和data-collecting code可用。你需要在按照你的意愿运行./configure前,把环境变量CFLAGS设置成-DGC_BENCH=1。下面的命令串就是做这个事:

    Example #4 重新编译PHP以启用GC benchmarking

    export CFLAGS=-DGC_BENCH=1
    ./config.nice
    make clean
    make

    当你用新编译的PHP二进制文件来重新执行上面的例子代码,在PHP执行结束后,你将看到下面的信息:

    Example #5 GC 统计数据

    GC Statistics
    -------------
    Runs:               110
    Collected:          2072204
    Root buffer length: 0
    Root buffer peak:   10000
          Possible            Remove from  Marked
            Root    Buffered     buffer     grey
          --------  --------  -----------  ------
    ZVAL   7175487   1491291    1241690   3611871
    ZOBJ  28506264   1527980     677581   1025731

    主要的信息统计在第一个块。你能看到垃圾回收机制运行了110次,而且在这110次运行中,总共有超过两百万的内存分配被释放。只要垃圾回收机制运行了至少一次,根缓冲区峰值(Root buffer peak)总是10000.

    结论

    通常,PHP中的垃圾回收机制,仅仅在循环回收算法确实运行时会有时间消耗上的增加。但是在平常的(更小的)脚本中应根本就没有性能影响。

    然而,在平常脚本中有循环回收机制运行的情况下,内存的节省将允许更多这种脚本同时运行在你的服务器上。因为总共使用的内存没达到上限。

    这种好处在长时间运行脚本中尤其明显,诸如长时间的测试套件或者daemon脚本此类。同时,对通常比Web脚本运行时间长的» PHP-GTK应用程序,新的垃圾回收机制,应该会大大改变一直以来认为内存泄漏问题难以解决的看法。

    The GC, unfortunately, as expounded in the examples above, has the tendency to promote lazy programming.
    Clearly the benefits of the GC to assist in memory management are there, and help to maintain a stable system, but it is no excuse to not plan and test your code properly.
    Always re-read your code critically and objectively to ensure that you are not introducing memory leaks unintentionally.
    There is a possibility to get GC performance stats without PHP recompilation. Starting from Xdebug version 2.6 you are able to enable stats collection into the file (default dir /tmp with name gcstats.%p):
    php -dxdebug.gc_stats_enable=1 your_script.php