Tipos Compostos

As coisas ficam um pouco mais complexas com tipos compostos como arrays e objects. Ao contrário dos valores escalares, arrays e objects armazenam suas propriedades em uma tabela de símbolos própria. Isto significa que o exemplo a seguir cria três contêineres zval:

Exemplo #5 Criando um zval de array

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

O exemplo acima produzirá algo semelhante a:

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

Ou graficamenet

Os três contêineres zval são: a, meaning, e number. Regras similares se aplicam para aumento e redução de "refcounts". Abaixo, outro elemento é adicionado ao array, e define seu valor ao conteúdo de um elemento já existente:

Exemplo #6 Adicionando elemento já existente a um array

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

O exemplo acima produzirá algo semelhante 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'
)

Ou graficamente

Pela saída do Xdebug acima, pode-se perceber que tanto o elemento antigo do array quanto o novo agora apontam para um contêiner zval cujo "refcount" é 2. Embora a saída do Xdebug mostre dois contêineres zval com valor 'life', eles são o mesmo. A função xdebug_debug_zval() não mostra isso, mas pode-se ver isso mostrando o ponteiro de memória.

Remover o elemento de um array é como remover um símbolo de um escopo. Fazendo isso, o "refcount" de um contêiner ao qual um elemento do array aponta é reduzido. Novamente, quando o "refcount" atinge zero, o contêiner da variável é removido da memória. Um exemplo para mostrar isto:

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

Agora, as coisas ficam interessantes se o próprio array for adicionado como um elemento do array, o que é mostrado no exemplo a seguir, onde também um operador de referência foi inserido, senão o PHP criaria uma cópia:

Exemplo #8 Adicionando o próprio array como um elemento de si mesmo

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

O exemplo acima produzirá algo semelhante a:

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

Ou graficamente

Pode-se perceber que a variável do array (a) assim como o segundo elemento (1) agora apontam para um contêiner de veriável que tem um "refcount" de 2. Os "..." no exemplo acima mostram que há recursão envolvida, e que, obviamente, neste caso significa que os "..." apontam de volta ao array original.

Como antes, tirar a atribuição de uma variável remove o símbolo, e a contagem de referência do contêiner da variável à qual o símbolo aponta é reduzida em uma unidade. Então, se a variável $a perder a atribuição após execução do código acima, a contagem de referência do contêiner da variável à qual $a e o elemento "1" apontam será diminuída em uma unidade, de "2" para "1". Isto pode ser representado assim:

Exemplo #9 Removendo a atribuição de $a

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

Ou graficamente

Problemas na Limpeza

Embora não haja mais um símbolo em nenhum escopo apontando para esta estrutura, ela não pode ser limpa porque o elemento "1" do array ainda aponta para este mesmo array. Como não há símbolo externo apontando para ela, não há como um usuário limpar esta estrutura; e aí acontece o vazamento de memória. Felizmente, o PHP irá limpar esta estrutura de dados no final da requisição, mas até lá, ela irá ocupar um espaço valioso na memória. Esta situação ocorre frequentemente quando se está implementando algoritmos de interpretação ou outros onde existe um elemento "filho" apontando de volta para um elemento "pai". A mesma situação também pode com certeza ocorrer com objetos, onde na verdade existe mais probabilidade de ocorrer, já que objetos são sempre implicitamente usados "por referência".

Isso pode não ser um problema quanto acontecer somente uma ou duas vezes, mas se houver milhares, ou até milhões dessas perdas de memória, obviamente começa a ser um problema. É especialmente problemático em scripts de execução longa, como daemons onde a requisição basicamente nunca termina, ou em grande conjuntos de testes de unidades. Este último já causou problemas durante a execução de testes de unidades para o componente Template da bilioteca eZ Components. Em alguns casos, era necessário mais de 2GB de memória, que o servidor de testes não tinha.