Le Garbage Collector (GC) est le système de gestion de la mémoire interne en PHP, mais il y a quelques subtilités à comprendre.
Le GC automatise la gestion de la mémoire, ce qui supprime les tracas liés à la gestion de la mémoire avec des tâches manuelles (ce qui serait fastidieux).
Cela permet aux développeurs de se concentrer sur leur logique métier sans se soucier excessivement des erreurs « Mémoire insuffisante ».
Bien sûr, ce n'est pas magique.
Libérer les objets qui ne sont plus nécessaires évite les fuites de mémoire.
Le GC utilise un mécanisme de comptage pour déterminer les éléments à supprimer. Si aucune référence ne pointe vers un objet particulier (c'est-à-dire $counter = 0), alors cet objet est éligible pour le nettoyage.
Cela fonctionne plutôt bien, mais certaines références peuvent poser problème :
class A { public $b; } class B { public $a; } $a = new A(); $b = new B(); $a->b = $b; $b->a = $a; unset($a); unset($b);
Dans ce cas de mauvaise conception, PHP ne libérera pas la mémoire même si nous supprimons $a et $b, car ils se référencent mutuellement, ce qui laisse croire à PHP qu'ils sont toujours utilisés.
Heureusement, il existe un autre mécanisme appelé Cycle Collector pour cela :
gc_collect_cycles();
En gros, le collectionneur parcourt toutes les références et applique un algorithme pour marquer les objets en cours d'utilisation, qui révèle les objets à collecter (ceux non marqués).
Cependant, PHP ne déclenche pas la collecte automatique des cycles tant que le seuil de 10 000 objets avec des références cycliques potentielles n'est pas atteint.
Encore une fois, ce n'est pas magique, vous ne devez donc invoquer gc_collect_cycles() que dans quelques cas.
Une mauvaise conception peut conduire à des relations trop complexes entre les objets, conduisant à plus de références et à un ramassage des ordures plus fréquent.
Chaque objet compté par référence nécessite un stockage supplémentaire pour son décompte de références.
Source : Wikipédia – Comptage de références
La surcharge associée aux opérations de nettoyage de la mémoire peut avoir un impact significatif sur les performances globales et, à terme, augmenter le temps d'exécution dans des scénarios spécifiques.
Il y a 10 ans, Composer obtenait une énorme amélioration de ses performances simplement en utilisant la fonction gc_disable().
Source : Composer - désactivation de GC
En effet, PHP 7 a drastiquement amélioré le GC, ce n'est donc plus ce qu'il était en 2014.
De plus, les versions PHP 8 ont amélioré les stratégies d'allocation de mémoire et ajouté des statistiques plus utiles sur les opérations GC pour une meilleure surveillance (gc_status() dans 8.3).
La plupart des applications PHP sont basées sur des requêtes et la mémoire est automatiquement vidée à la fin de la requête.
Encore une fois, c'est plutôt cool mais pas magique. Que se passe-t-il avec les requêtes asynchrones et les objets/démons de longue durée ?
Vous pourriez rencontrer des fuites de mémoire à un moment donné.
À ce stade, vous ne voyez peut-être pas en quoi le GC de PHP diffère des autres langages.
La plupart du temps, d'autres langages ne s'appuient pas sur le comptage de références pour collecter les déchets ou peuvent utiliser des implémentations différentes.
Par exemple, beaucoup utilisent l'algorithme de traçage qui marque également les objets inutilisés mais ne fonctionne pas de manière incrémentielle. C'est un parcours graphique.
De plus, certains langages ne permettent pas un tel contrôle direct (par exemple, marche/arrêt au moment de l'exécution).
Comme d'habitude, il y a certains avantages et inconvénients, vous pouvez donc voir des approches hybrides.
Vous pouvez tirer parti des assistants gc_* intégrés.
Par exemple :
Ces fonctions sont utiles pour déboguer ou affiner le garbage collection si nécessaire.
Vous pouvez lire cet article pour plus d'informations :
PHP 7.4 a introduit les références faibles et PHP 8 a introduit les cartes faibles.
Une carte faible pourrait être décrite comme une collection de références faibles.
Cette structure de données est un magasin clé-valeur polyvalent qui aide PHP à suivre les éléments sans créer d'encombrement ni consommer d'espace excessif.
Vous pouvez le voir comme un stockage temporaire qui sera vidé immédiatement lorsqu'il n'est plus nécessaire, car il n'y a aucune référence [forte] qui pourrait empêcher le ramassage des ordures :
class A { public $b; } class B { public $a; } $a = new A(); $b = new B(); $a->b = $b; $b->a = $a; unset($a); unset($b);
Pour la plupart des utilisations, vous n'aurez pas à vous soucier de la gestion de la mémoire, puisque PHP s'en charge déjà.
Cependant, étant donné que les piles modernes utilisent des objets à longue durée de vie, vous devez surveiller votre application pour détecter d'éventuelles fuites de mémoire.
Si vous rencontrez des problèmes, vous devrez peut-être optimiser le code et/ou interagir directement avec le GC.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!