Types composés

Les choses se compliquent dans le cas de types composés comme array et object. À la différence des valeurs scalar, les array et object stockent leurs propriétés dans une table de symboles qui leur est propre. Ceci signifie que l'exemple qui suit crée trois conteneurs zval :

Exemple #5 Création d'une zval array

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

Résultat de l'exemple ci-dessus est similaire à :

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

Ou graphiquement

Les trois conteneurs zval sont : a, meaning, et number. Les mêmes règles s'appliquent pour l'incrémentation et la décrémentation des "refcounts". Ci-après, nous ajoutons un autre élément au tableau, et nous renseignons sa valeur avec le contenu d'un élément déjà existant du tableau :

Exemple #6 Ajout d'un élément déjà existant au tableau

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

Résultat de l'exemple ci-dessus est similaire à :

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 graphiquement

La sortie Xdebug que nous voyons indique que l'ancien et le nouvel élément du tableau pointent maintenant tous deux vers un conteneur zval dont le "refcount" vaut 2. Même si la sortie XDebug montre deux conteneurs zval avec comme valeur 'life', ils sont les mêmes. La fonction xdebug_debug_zval() ne montre pas cela, mais cela pourrait être constaté en affichant aussi le pointeur de mémoire.

Supprimer un élément du tableau est assimilable à la suppression d'un symbole depuis un espace. Ce faisant, le "refcount" du conteneur vers lequel l'élément du tableau pointe est décrémenté. Une fois encore, s'il atteint zéro, le conteneur zval est supprimé de la mémoire. Voici un exemple qui le démontre :

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

Maintenant, les choses deviennent intéressantes si nous ajoutons le tableau comme élément de lui-même. Nous faisons cela dans l'exemple qui suit, en utilisant un opérateur de référence pour éviter que PHP ne crée une copie :

Exemple #8 Ajout du tableau comme référence à lui-même en tant qu'élément

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

Résultat de l'exemple ci-dessus est similaire à :

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

Ou graphiquement

On peut voir que la variable tableau (a) tout comme le second élément (1) pointent désormais vers un conteneur dont le "refcount" vaut 2. Les "..." sur l'affichage indiquent une récursion, qui, dans ce cas, signifie que le "..." pointe sur le tableau lui-même.

Comme précédemment, supprimer une variable supprime son symbole, et le refcount du conteneur sur lequel il pointait est décrémenté. Donc, si nous supprimons la variable $a après avoir exécuté le code ci-dessus, le compteur de références du conteneur sur lequel pointent $a et l'élément "1" sera décrémenté de un, passant de "2" à "1". Ceci peut être représenté par :

Exemple #9 Suppression de $a

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

Ou graphiquement

Problèmes de nettoyage

Bien qu'il n'y ait plus aucun symbole dans l'espace de variables courant qui pointe vers cette structure, elle ne peut être nettoyée, car l'élément "1" du tableau pointe toujours vers ce même tableau. Comme il n'y a plus aucun symbole externe pointant vers cette structure, l'utilisateur ne peut pas la nettoyer manuellement ; il y a donc une fuite de mémoire. Heureusement, PHP va détruire cette structure à la fin de la requête, mais avant cette étape, la mémoire n'est pas libérée. Cette situation se produit souvent lors de l'implémentation d'un algorithme d'analyse ou d'autres idées où l'on a un enfant qui pointe vers son parent. La même chose peut bien entendu se produire avec les objets, et c'est même plus probable, puisqu'ils sont toujours implicitement utilisés par "référence".

Ceci peut ne pas être gênant si cela n'arrive qu'une ou deux fois, mais s'il y a des milliers, ou même des millions, de ces fuites mémoires, alors cela risque évidemment de devenir un problème important. C'est particulièrement problématique pour les scripts qui durent longtemps, comme les démons pour lesquels la requête ne termine pour ainsi dire jamais, ou encore dans de grosses suites de tests unitaires. Ce dernier cas a été rencontré en lançant les tests unitaires du composant Template de la bibliothèque eZ Components. Dans certains cas, la suite de tests nécessitait plus de 2Go de mémoire, que le serveur de test n'avait pas vraiment à disposition.