Principes de base de la gestion de la mémoire JavaScript: comment cela fonctionne et quels problèmes peuvent survenir

La plupart des développeurs pensent rarement à la manière dont la gestion de la mémoire JavaScript est implémentée. Le moteur fait généralement tout pour le programmeur, donc cela n'a aucun sens pour ce dernier de réfléchir aux principes du mécanisme de gestion de la mémoire.



Mais tôt ou tard, les développeurs doivent encore faire face à des problèmes de mémoire, tels que des fuites. Eh bien, il ne sera possible de les traiter que lorsqu'il y aura une compréhension du mécanisme d'allocation de mémoire. Cet article est consacré aux explications. Il fournit également des conseils sur les types les plus courants de fuites de mémoire dans JavaScript.

Cycle de vie de la mémoire

Lors de la création de fonctions, de variables, etc. en JavaScript, le moteur alloue une certaine quantité de mémoire. Ensuite, il le libère - après que la mémoire n'est plus nécessaire.



En fait, l'allocation de mémoire peut être appelée le processus de réservation d'une certaine quantité de mémoire. Eh bien, sa libération est le retour de la réserve dans le système. Vous pouvez le réutiliser autant de fois que vous le souhaitez.



Lorsqu'une variable est déclarée ou qu'une fonction est créée, la mémoire passe par la boucle suivante.







Ici en blocs:

• Allocate est l'allocation de mémoire effectuée par le moteur. Il alloue la mémoire requise pour l'objet créé.
• Utilisation - utilisation de la mémoire. Le développeur est responsable de ce moment, écrivant dans le code pour lire et écrire en mémoire.
• Libérer - libérer de la mémoire. C'est là que JavaScript prend de nouveau son envol. Une fois la réserve libérée, la mémoire peut également être utilisée à d'autres fins.

«Objets» dans le contexte de la gestion de la mémoire signifie non seulement des objets JS, mais également des fonctions et des portées.

Pile de mémoire et tas

En général, tout semble clair - JavaScript alloue de la mémoire pour tout ce que le développeur spécifie dans le code, puis, lorsque toutes les opérations sont terminées, la mémoire est libérée. Mais où sont stockées les données?



Il existe deux options - sur la pile de mémoire et sur le tas. Quelle est la première chose, quelle est la seconde - le nom des structures de données utilisées par le moteur à des fins différentes.



La pile est l'allocation de mémoire statique







La définition de la pile est connue de beaucoup. C'est une structure de données qui est utilisée pour stocker des données statiques, sa taille est toujours connue au moment de la compilation. JS a inclus des valeurs primitives telles que string, number, boolean, undefined et null, ainsi que des références de fonction et d'objet.



Le moteur "comprend" que la taille des données ne change pas, il alloue donc une quantité fixe de mémoire pour chacune des valeurs. Le processus d'allocation de mémoire avant l'exécution est appelé allocation de mémoire statique.



Étant donné que le navigateur alloue de la mémoire à l'avance pour chaque type de données, il y a une limite à la taille des données qui peuvent y être placées. Étant donné que le navigateur alloue de la mémoire à l'avance pour chaque type de données, il y a une limite à la taille des données qui peuvent y être placées.



Le tas - allocation de mémoire dynamique



Quant au tas, il est aussi familier à beaucoup que la pile. Il est utilisé pour stocker des objets et des fonctions.



Mais contrairement à la pile, le moteur ne peut pas "savoir" combien de mémoire est nécessaire pour un objet particulier, donc la mémoire est allouée selon les besoins. Et cette façon d'allouer de la mémoire est appelée «dynamique» (allocation de mémoire dynamique).



Quelques exemples



Les commentaires sur le code indiquent les nuances d'allocation mémoire.

const person = {
  name: 'John',
  age: 24,
};
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

// JavaScript alloue de la mémoire pour cet objet sur le tas.

// Les valeurs elles-mêmes sont primitives, elles sont donc stockées sur la pile.

const hobbies = ['hiking', 'reading'];
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

// Les tableaux sont également des objets, ils vont donc dans le tas.



let name = 'John'; // alloue de la mémoire pour la chaîne

const age = 24; // alloue de la mémoire pour le numéro

name = 'John Doe'; // alloue de la mémoire pour une nouvelle ligne

const firstName = name.slice (0,4); // alloue de la mémoire pour une nouvelle ligne



// Les valeurs primitives sont intrinsèquement immuables: au lieu de changer la valeur initiale,

// JavaScript en crée une autre.

Liens JavaScript

Quant à la pile, toutes les variables pointent vers elle. Si la valeur n'est pas primitive, la pile contient une référence à l'objet de tas.



Il n'y a pas d'ordre particulier, ce qui signifie qu'une référence à la zone mémoire souhaitée est stockée sur la pile. Dans une telle situation, l'objet dans le tas ressemble à un bâtiment, mais le lien est son adresse.



JS stocke des objets et des fonctions sur le tas. Mais les valeurs primitives et les références sont sur la pile.







Cette image montre l'organisation du stockage des différentes valeurs. Notez que personne et newPerson pointent vers le même objet ici.



Exemple

const person = {
  name: 'John',
  age: 24,
};
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

// Un nouvel objet est créé sur le tas et une référence à celui-ci sur la pile.



En général, les liens sont extrêmement importants en JavaScript.

Collecte des ordures

Il est maintenant temps de revenir au cycle de vie de la mémoire, à savoir sa libération.



Le moteur JavaScript est responsable non seulement de l'allocation de mémoire, mais également de la désallocation. Dans ce cas, le garbage collector renvoie la mémoire au système.



Et dès que le moteur "voit" que la variable ou la fonction n'est plus nécessaire, la mémoire est libérée.



Mais il y a un problème clé ici. Le fait est qu'il est impossible de décider si une certaine zone de mémoire est nécessaire ou non. Il n'y a pas d'algorithme aussi précis que de libérer de la mémoire en temps réel.



Certes, il n'y a que des algorithmes qui fonctionnent bien qui vous permettent de le faire. Ils ne sont pas parfaits, mais toujours bien meilleurs que beaucoup d'autres. Ci-dessous - une histoire sur le garbage collection, qui est basé sur le comptage de références, ainsi que sur l '"algorithme de marquage".

Et les liens?

C'est un algorithme très simple. Il supprime les objets auxquels aucun autre point de référence. Voici un exemple qui l'explique assez bien.



Si vous avez regardé la vidéo, vous avez probablement remarqué que les loisirs sont le seul objet du tas qui a été référencé sur la pile.

Cycles

L'inconvénient de l'algorithme est qu'il ne peut pas prendre en compte les références circulaires. Ils surviennent lorsqu'un ou plusieurs objets se réfèrent les uns aux autres, hors de portée du point de vue du code.

let son = {
  name: 'John',
};
let dad = {
  name: 'Johnson',
}
 
son.dad = dad;
dad.son = son;
son = null;
dad = null;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Ici, le fils et le père se réfèrent. Il n'y a pas d'accès aux objets pendant une longue période, mais l'algorithme ne libère pas la mémoire qui leur est allouée.



Précisément parce que l'algorithme compte les références, l'affectation de null aux objets ne fait rien, car chaque objet a toujours une référence.

Algorithme pour les annotations

C'est là qu'un autre algorithme vient à la rescousse, appelé la méthode de marquage et de balayage. Cet algorithme ne compte pas les références, mais détermine si différents objets sont accessibles via l'objet racine. Dans le navigateur, c'est window, et dans Node.js, c'est global.







Si l'objet n'est pas disponible, l'algorithme le marque puis le supprime. Dans ce cas, les objets racine ne sont jamais détruits. Le problème des références cycliques n'est pas pertinent ici - l'algorithme nous permet de comprendre que ni papa ni fils ne sont déjà inaccessibles, donc ils peuvent être «balayés» et la mémoire renvoyée au système.



Depuis 2012, absolument tous les navigateurs sont équipés de poubelles qui fonctionnent exactement selon la méthode de marquage et de balayage.

Non sans ses inconvénients ici.

On pourrait penser que tout va bien, et maintenant vous pouvez oublier la gestion de la mémoire, laissant tout à l'algorithme. Mais ce n’est pas le cas.



Utilisation importante de la mémoire



Étant donné que les algorithmes ne savent pas quand la mémoire n'est plus nécessaire, les applications JavaScript peuvent utiliser plus de mémoire que nécessaire. Et seul le collecteur peut décider de libérer ou non la mémoire allouée.



JavaScript est meilleur pour gérer la mémoire dans les langages de bas niveau. Mais il y a aussi des inconvénients ici, qu'il faut garder à l'esprit. En particulier, JS ne fournit pas d'outils de gestion de la mémoire, contrairement aux langages de bas niveau, dans lesquels le programmeur s'occupe "manuellement" de l'allocation et de la libération de la mémoire.



Performance



La mémoire n'est pas effacée à chaque nouveau moment dans le temps. La libération est effectuée à intervalles réguliers. Mais les développeurs ne peuvent pas savoir exactement quand ces processus sont lancés.



Par conséquent, dans certains cas, le garbage collection peut avoir un impact négatif sur les performances, car l'algorithme a besoin de certaines ressources pour fonctionner. Certes, la situation devient rarement complètement ingérable. Le plus souvent, les conséquences sont microscopiques.

Fuites de mémoire

Les fuites de mémoire sont l'une des choses les plus frustrantes du développement. Mais si vous connaissez tous les types de fuites les plus courants, vous pouvez contourner le problème sans trop de difficulté.



Variables globales Les



fuites de mémoire se produisent le plus souvent en raison du stockage de données dans des variables globales.



Dans le navigateur, si vous faites une erreur et utilisez var au lieu de const ou let, le moteur attachera la variable à l'objet window. De même, il effectuera l'opération sur les fonctions définies par le mot fonction.

user = getUser();
var secondUser = getUser();
function getUser() {
  return 'user';
}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

// Les trois variables - user, secondUser et

// getUser - seront attachées à l'objet window.



Cela ne peut être fait qu'avec des fonctions et des variables déclarées dans la portée globale. Vous pouvez contourner ce problème en exécutant votre code en mode strict.



Les variables globales sont souvent déclarées intentionnellement, ce n'est pas toujours une erreur. MAIS, dans tous les cas, il ne faut pas oublier de libérer de la mémoire une fois que les données ne sont plus nécessaires. Pour ce faire, vous devez affecter null à la variable globale.



window.users = null;



Rappels et minuteries



L'application utilise plus de mémoire qu'elle ne le devrait, même si nous oublions les minuteries et les rappels. Le principal problème concerne les applications à page unique (SPA), ainsi que l'ajout dynamique de rappels et de gestionnaires d'événements.



Minuteries oubliées

const object = {};
const intervalId = setInterval(function() {
  //     ,   ,
  //     
  doSomething(object);
}, 2000);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Cette fonction s'exécute toutes les deux secondes. Sa mise en œuvre ne doit pas être sans fin. Le problème est que les objets qui ont une référence dans l'intervalle ne sont pas détruits tant que l'intervalle n'est pas effacé. Par conséquent, vous devez prescrire en temps opportun:

clearInterval (intervalId); Rappel



oublié Un



problème peut survenir si un gestionnaire onClick est attaché à un bouton et que le bouton lui-même est supprimé après - par exemple, il n'est plus nécessaire.



Auparavant, la plupart des navigateurs ne pouvaient tout simplement pas libérer la mémoire allouée à un tel gestionnaire d'événements. Maintenant, ce problème appartient au passé, mais quand même, laisser les gestionnaires dont vous n'avez plus besoin n'en vaut pas la peine.

const element = document.getElementById('button');
const onClick = () => alert('hi');
element.addEventListener('click', onClick);
element.removeEventListener('click', onClick);
element.parentNode.removeChild(element);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Éléments DOM oubliés dans les variables



Ceci est similaire au cas précédent. L'erreur se produit lorsque les éléments DOM sont stockés dans une variable.

const elements = [];
const element = document.getElementById('button');
elements.push(element);
function removeAllElements() {
  elements.forEach((item) => {
document.body.removeChild(document.getElementById(item.id))
  });
}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Lorsque vous supprimez l'un des éléments ci-dessus, vous devez également prendre soin de le supprimer du tableau. Sinon, le garbage collector ne le supprimera pas automatiquement.

const elements = [];
const element = document.getElementById('button');
elements.push(element);
function removeAllElements() {
  elements.forEach((item, index) => {
document.body.removeChild(document.getElementById(item.id));
   elements.splice(index, 1);
 });
}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

En supprimant un élément du tableau, vous mettez à jour son contenu avec la liste des éléments de la page.



Étant donné que chaque élément de la maison a une référence à son parent, cela empêche de manière référentielle le ramasse-miettes de libérer la mémoire occupée par le parent, ce qui entraîne des fuites.

Dans le résidu sec

L'article décrit la mécanique générale de l'allocation de mémoire, ainsi que l'auteur a montré quels problèmes peuvent survenir et comment les résoudre. Tout cela est important pour tout développeur Java Script.

, Frontend- Skillbox:



, - ( SPA — Single Page Applications).



, “ ” — ( , ), , , .



— . .



, ( , , ). , , “” — garbage collector.



- (js , garbage collector’a). , .