Составные типы данных

Всё несколько усложняется с составными типами данных, например с массивами (array) и объектами (object). В отличие от скалярных (scalar) значений, массивы и объекты хранят свойства в своих таблицах имён. То есть следующий пример создаст сразу три zval-контейнера:

Пример #5 Создание 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
)

Графически:

Результат — три контейнера: a, meaning и number. Похожие правила применяются и для увеличения и уменьшения refcounts. Ниже мы добавляем ещё один элемент массива и устанавливаем ему значение уже существующего элемента:

Пример #6 Добавление уже существующего элемента в массив

<?php
$a = array( 'meaning' => 'life', 'number' => 42 );
$a['life'] = $a['meaning'];
xdebug_debug_zval( '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'
)

Графически:

Из вывода Xdebug видно, что и старый и новый элементы массива сейчас указывают на контейнер, чей refcount равен 2. Хотя показано два контейнера со значением 'life', но это один контейнер. Функция xdebug_debug_zval() не выводит информации об этом, но вы можете проверить это также отобразив указатели памяти.

Элемент удаляется из массива аналогично удалению имени переменной из области видимости: уменьшается refcount-контейнер, на который ссылается элемент массива. При достижении нуля в бите refcount, контейнер удаляется из памяти. Пример:

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

Ситуация станет интереснее, если добавить массив новым элементом в самого себя. В следующем примере использован оператор присваивания по ссылке, чтобы PHP не создал копию массива.

Пример #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 к переменной $a после этого примера, счётчик ссылок контейнера, на который указывают переменная $a и элемент 1, изменится с 2 на 1:

Пример #9 Удаление $a

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

Графически:

Суть проблемы

Хотя во всех областях видимости больше нет имени переменной, ссылающейся на данную структуру, она не может быть очищена, т. к. элемент массива с ключом 1 по-прежнему ссылается на этот массив. Т. к. теперь нет никакой возможности пользователю удалить эти данные, случится утечка памяти. К счастью, PHP удалит эти данные при завершении запроса, но до этого момента данные будут занимать ценное место в памяти. Такая ситуация часто бывает, когда реализуются алгоритмы парсинга или другие, где есть дочерние элементы, ссылающиеся на родительские. Ещё чаще такая ситуация случается с объектами, потому что они всегда неявно используются по ссылке.

Не проблема, если такое случается раз или два, но если существуют тысячи или даже миллионы таких утечек памяти, то они уже станут проблемой. Особенно в долгоработающих скриптах, например, демонах, где запрос не заканчивается, или в крупных наборах модульных тестов. Последний случай вызвал проблемы при запуске модульных тестов для компонента Template из библиотеки ez Components. Иногда может потребоваться больше 2 ГБ памяти, которая не всегда есть на тестовом сервере.