Comment les fermetures peuvent provoquer des fuites de mémoire et que pouvez-vous faire pour y remédier

Introduction

Les fuites de mémoire sont le cauchemar des développeurs, surtout lorsqu'elles surviennent en production. Malgré tous nos efforts pour écrire du code propre et efficace, des problèmes subtils comme une mauvaise utilisation des fermetures peuvent entraîner des fuites de mémoire difficiles à détecter et à résoudre. Cet article se concentre sur la compréhension des fermetures et de leur interaction avec le garbage collector (GC), racontant mon expérience avec une fuite de mémoire accidentelle causée par les fermetures. Nous explorerons comment les fermetures contiennent des références à la mémoire, pourquoi cela peut empêcher le GC de la récupérer, et les leçons apprises en cours de route.

---

Le problème : une augmentation progressive de la mémoire en production

Tout semblait bien pendant le développement et les tests. Cependant, quelques jours après le déploiement de notre application en production, notre système de surveillance a signalé un modèle d'utilisation de la mémoire inhabituel. La consommation de mémoire de notre application Node.js augmentait régulièrement au fil du temps, provoquant finalement une dégradation des performances et même des plantages.

Au départ, je soupçonnais des facteurs externes, tels que des problèmes de connexion à une base de données ou des bibliothèques tierces non optimisées. Mais après avoir isolé l'application et reproduit le problème localement, j'ai réalisé que le problème provenait de notre base de code.

---

L'enquête : un chemin difficile

1. Comprendre les fermetures et le éboueur

Les fermetures sont des fonctions qui « ferment » leur portée lexicale, en conservant les références aux variables définies dans leur portée externe. Bien que ce comportement soit incroyablement puissant, il peut entraîner des fuites de mémoire si les développeurs ne savent pas quelles variables la fermeture conserve. Le garbage collector ne peut pas libérer de mémoire pour les variables référencées par les fermetures, même si ces variables ne sont plus nécessaires ailleurs dans l'application.

2. Analyser les symptômes

Les fuites de mémoire se manifestent souvent par de la mémoire qui n'est plus nécessaire mais qui n'est pas libérée. Dans ce cas, le garbage collector n'a pas pu récupérer de la mémoire, ce qui indique que quelque chose dans notre code conservait des références à des objets inutilisés. Le défi était d'identifier quoi.

3. Analyser le tas

Je me suis tourné vers les Node.js Heap Snapshots pour capturer et analyser l'utilisation de la mémoire. En prenant des instantanés du tas à différents intervalles, j'ai observé :

• Un nombre croissant d'objets retenus.
• Certaines fermetures contenant des références à des variables longtemps après la fin de leur utilité.

4. Le coupable : une fermeture contenant des données volumineuses

Après avoir minutieusement effectué l'analyse du tas, j'ai découvert qu'une fermeture conservait involontairement les références aux variables dans sa portée externe, les empêchant d'être récupérées. Cette fermeture a été maintenue active par inadvertance, empêchant le garbage collector de récupérer la mémoire associée au gros objet.

Voici un exemple concret :

function createLeak() {
    const largeObject = new Array(1000000).fill('leaky data'); // Simulating a large object.

    // The closure retains a reference to `largeObject`.
    return function leakyFunction() {
        console.log(largeObject[0]); // Accessing `largeObject` in the closure.
    };
}

const leakyClosure = createLeak();
// Even if `createLeak` is no longer called, `largeObject` remains in memory due to the closure.

Ce qui se passe dans le code :

1. Création de largeObject :
   Dans createLeak, un grand tableau largeObject est créé. Ce tableau utilise une quantité importante de mémoire.

2. La fermeture conserve la référence :
   La fonction interne leakyFunction forme une fermeture sur la portée de la fonction externe, qui inclut la variable largeObject.

3. Retour de la Fermeture :
   La fermeture leakyFunction est renvoyée et affectée à leakyClosure.

4. Fuite de mémoire :
   Même si createLeak termine l'exécution, le largeObject n'est pas récupéré car la fermeture leakyFunction y contient toujours une référence.

Cela empêche le largeObject d'être libéré de la mémoire.

---

La solution : réparer la fuite

Pour résoudre le problème, j'ai repensé le code pour garantir que les fermetures ne conservent pas de références inutiles à des objets volumineux. La solution garantit que les fermetures ne conservent que les références aux variables nécessaires. Voici l'exemple révisé :

function createFixed() {
    const largeObject = new Array(1000000).fill('leaky data');

    // Use the required value, not the entire object.
    const importantValue = largeObject[0];

    // Only keep the necessary data in the closure.
    return function fixedFunction() {
        console.log(importantValue);
    };
}

const fixedClosure = createFixed();
// Now, `largeObject` can be garbage collected since the closure does not retain it.

Ce qui a changé :

• Seule la partie nécessaire du largeObject (importantValue) est conservée dans la fermeture.
• Le grand tableau largeObject n'est plus référencé par la fermeture, permettant au garbage collector de libérer sa mémoire une fois l'exécution de createFixed terminée.

---

Leçons apprises

Cette expérience m'a appris plusieurs leçons précieuses sur les fermetures et la gestion de la mémoire :

1. Comprendre les fermetures et le garbage collector :

   • Les fermetures conservent les références aux variables dans leur portée externe. Si ces références ne sont plus nécessaires mais ne sont pas explicitement publiées, le garbage collector ne peut pas récupérer la mémoire associée, ce qui entraîne des fuites.

2. Surveiller les applications de production :

   • Mettez en place une surveillance robuste pour détecter précocement les anomalies de mémoire. Les fuites de mémoire se manifestent souvent progressivement. La surveillance des tendances peut donc aider à détecter les problèmes avant qu'ils ne deviennent critiques.

3. Réduire les variables capturées :

   • Concevez des fermetures pour capturer uniquement les variables dont elles ont réellement besoin, réduisant ainsi la probabilité de conserver des données inutiles.

---

Conclusion

Les fuites de mémoire peuvent être insaisissables, surtout lorsqu'elles sont causées par des problèmes subtils comme des fermetures. Comprendre comment les fermetures interagissent avec le garbage collector est crucial pour écrire du code efficace et sans fuite. Avec les bons outils et pratiques, ces fuites peuvent être identifiées et résolues efficacement. En étant vigilant quant au nettoyage des ressources et en étant attentif à ce que les fermetures capturent, vous pouvez éviter des pièges similaires et garantir le bon fonctionnement de vos applications en production.

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!