4 types de fuites de mémoire JavaScript et comment les éviter-js tutoriel-php.cn

Texte original : 4 types de fuites de mémoire dans JavaScript et comment s'en débarrasser

Traduction de : le blog d'Alon

Cet article explorera la mémoire JavaScript courante côté client fuites, et comment utiliser Chrome Dev Tools pour détecter les problèmes.

Introduction
Les fuites de mémoire sont un problème auquel tout développeur finira par être confronté, et elles sont à l'origine de nombreux problèmes : réponse lente, plantages, latence élevée et autres problèmes d'application.

Qu'est-ce qu'une fuite de mémoire ?
Essentiellement, une fuite de mémoire peut être définie comme : lorsque l'application n'a plus besoin d'occuper la mémoire, pour une raison quelconque, la mémoire n'est pas récupérée par le système d'exploitation ou le pool de mémoire disponible. Les langages de programmation varient dans la manière dont ils gèrent la mémoire. Seuls les développeurs savent le mieux quelle mémoire n'est plus nécessaire et peut être récupérée par le système d'exploitation. Certains langages de programmation fournissent des fonctionnalités linguistiques qui aident les développeurs à faire ce genre de choses. D'autres comptent sur les développeurs pour savoir clairement si de la mémoire est nécessaire.

Gestion de la mémoire JavaScript
JavaScript est un langage de récupération de place. Les langages de récupération de place aident les développeurs à gérer la mémoire en vérifiant périodiquement si la mémoire précédemment allouée est accessible. En d'autres termes, les langages récupérés atténuent les problèmes de « la mémoire est toujours disponible » et de « la mémoire est toujours accessible ». La différence entre les deux est subtile mais importante : seul le développeur sait quelle mémoire sera encore utilisée à l'avenir, tandis que la mémoire inaccessible est déterminée et marquée par un algorithme, et est rapidement récupérée par le système d'exploitation.

Fuites de mémoire JavaScript
La principale cause des fuites de mémoire dans les langages ramassés est les références indésirables. Avant de le comprendre, vous devez comprendre comment le langage de récupération de place fait la distinction entre la mémoire accessible et inaccessible.

Marquer et balayer
L'algorithme utilisé par la plupart des langages de récupération de place est appelé Mark-and-sweep. L'algorithme comprend les étapes suivantes :

1. Le garbage collector crée une liste "racines". Les racines sont généralement des références à des variables globales dans votre code. En JavaScript, l'objet "window" est une variable globale et est traité comme racine. L'objet window existe toujours, donc le garbage collector peut vérifier que lui et tous ses sous-objets existent (c'est-à-dire qu'ils ne sont pas des ordures
2. Toutes les racines sont vérifiées et marquées comme actives (c'est-à-dire qu'elles ne sont pas des ordures). Tous les sous-objets sont également vérifiés de manière récursive. Si tous les objets à partir de root sont accessibles, ils ne sont pas considérés comme des déchets.
3. Toute la mémoire non marquée sera traitée comme une poubelle. Le collecteur peut désormais libérer la mémoire et la restituer au système d'exploitation.
Les garbage collector modernes ont amélioré leurs algorithmes, mais l'essence est la même : la mémoire accessible est marquée et le reste est récupéré.

Une référence inutile signifie que le développeur sait que la référence mémoire n'est plus nécessaire, mais que pour une raison quelconque, elle est toujours laissée dans l'arborescence racine active. En JavaScript, une référence indésirable est une variable qui reste dans le code et n'est plus nécessaire mais pointe vers un morceau de mémoire qui doit être libéré. Certaines personnes pensent qu'il s'agit d'une erreur du développeur.

Afin de comprendre les fuites de mémoire les plus courantes en JavaScript, nous devons comprendre comment les références sont facilement oubliées.

Trois types de fuites de mémoire JavaScript courantes
1 : Variables globales inattendues
JavaScript gère les variables non définies de manière lâche : undéfini La variable créera une nouvelle variable dans l'objet global. Dans les navigateurs, l'objet global est window .

function foo(arg) {
    bar = "this is a hidden global variable";
}

Copier après la connexion

La vérité est :

function foo(arg) {
    window.bar = "this is an explicit global variable";
}

Copier après la connexion

J'ai oublié d'utiliser var en interne dans la fonction foo et j'ai accidentellement créé une variable globale. Cet exemple divulgue une simple chaîne, ce qui est inoffensif, mais il y a des choses pires.

Une autre variable globale inattendue peut être créée par ceci :

function foo() {
    this.variable = "potential accidental global";
}

// Foo 调用自己，this 指向了全局对象（window）
// 而不是 undefined
foo();

Copier après la connexion

Référencé par

dans Ajout « use strict » dans l'en-tête des fichiers JavaScript peut éviter de telles erreurs. Activez l'analyse en mode strict de JavaScript pour éviter les variables globales inattendues.

Considérations sur les variables globales

Bien que nous ayons discuté de certaines variables globales inattendues, il y a encore des déchets générés par des variables globales explicites. Ils sont définis comme non recyclables (sauf s’ils sont vides ou réaffectés). Des précautions doivent être prises en particulier lorsque des variables globales sont utilisées pour stocker et traiter temporairement de grandes quantités d'informations. Si vous devez utiliser une variable globale pour stocker une grande quantité de données, veillez à la définir sur null ou à la redéfinir après utilisation. La mise en cache est l’une des principales causes de l’augmentation de la consommation de mémoire liée aux variables globales. La mise en cache des données est destinée à être réutilisée et la taille du cache doit être limitée pour être utile. Une consommation élevée de mémoire entraîne le dépassement de la limite supérieure du cache, car le contenu mis en cache ne peut pas être récupéré.

2 : La fonction de minuterie ou de rappel oubliée
L'utilisation de setInterval en JavaScript est très courante. Un morceau de code commun :

var someResource = getData();
setInterval(function() {
    var node = document.getElementById(&#39;Node&#39;);
    if(node) {
        // 处理 node 和 someResource
        node.innerHTML = JSON.stringify(someResource));
    }
}, 1000);

Copier après la connexion

此例说明了什么：与节点或数据关联的计时器不再需要，node 对象可以删除，整个回调函数也不需要了。可是，计时器回调函数仍然没被回收（计时器停止才会被回收）。同时，someResource 如果存储了大量的数据，也是无法被回收的。

对于观察者的例子，一旦它们不再需要（或者关联的对象变成不可达），明确地移除它们非常重要。老的 IE 6 是无法处理循环引用的。如今，即使没有明确移除它们，一旦观察者对象变成不可达，大部分浏览器是可以回收观察者处理函数的。

观察者代码示例：

var element = document.getElementById(&#39;button&#39;);
function onClick(event) {
    element.innerHTML = &#39;text&#39;;
}

element.addEventListener(&#39;click&#39;, onClick);

Copier après la connexion

对象观察者和循环引用注意事项

老版本的 IE 是无法检测 DOM 节点与 JavaScript 代码之间的循环引用，会导致内存泄露。如今，现代的浏览器（包括 IE 和 Microsoft Edge）使用了更先进的垃圾回收算法，已经可以正确检测和处理循环引用了。换言之，回收节点内存时，不必非要调用 removeEventListener 了。

3：脱离 DOM 的引用
有时，保存 DOM 节点内部数据结构很有用。假如你想快速更新表格的几行内容，把每一行 DOM 存成字典（JSON 键值对）或者数组很有意义。此时，同样的 DOM 元素存在两个引用：一个在 DOM 树中，另一个在字典中。将来你决定删除这些行时，需要把两个引用都清除。

var elements = {
    button: document.getElementById(&#39;button&#39;),
    image: document.getElementById(&#39;image&#39;),
    text: document.getElementById(&#39;text&#39;)
};

function doStuff() {
    image.src = &#39;http://some.url/image&#39;;
    button.click();
    console.log(text.innerHTML);
    // 更多逻辑
}

function removeButton() {
    // 按钮是 body 的后代元素
    document.body.removeChild(document.getElementById(&#39;button&#39;));

    // 此时，仍旧存在一个全局的 #button 的引用
    // elements 字典。button 元素仍旧在内存中，不能被 GC 回收。
}

Copier après la connexion

此外还要考虑 DOM 树内部或子节点的引用问题。假如你的 JavaScript 代码中保存了表格某一个的引用。将来决定删除整个表格的时候，直觉认为 GC 会回收除了已保存的以外的其它节点。实际情况并非如此：此是表格的子节点，子元素与父元素是引用关系。由于代码保留了的引用，导致整个表格仍待在内存中。保存 DOM 元素引用的时候，要小心谨慎。

4：闭包
闭包是JavaScript开发的一个关键方面：匿名函数可以访问父级作用域的变量。

代码示例：

var theThing = null;
var replaceThing = function () {
  var originalThing = theThing;
  var unused = function () {
    if (originalThing)
      console.log("hi");
  };

  theThing = {
    longStr: new Array(1000000).join(&#39;*&#39;),
    someMethod: function () {
      console.log(someMessage);
    }
  };
};

setInterval(replaceThing, 1000);

Copier après la connexion

代码片段做了一件事情：每次调用 replaceThing ，theThing 得到一个包含一个大数组和一个新闭包（someMethod）的新对象。同时，变量 unused 是一个引用 originalThing 的闭包（先前的 replaceThing 又调用了 theThing ）。思绪混乱了吗？最重要的事情是，闭包的作用域一旦创建，它们有同样的父级作用域，作用域是共享的。someMethod 可以通过 theThing 使用，someMethod 与 unused 分享闭包作用域，尽管 unused 从未使用，它引用的 originalThing 迫使它保留在内存中（防止被回收）。当这段代码反复运行，就会看到内存占用不断上升，垃圾回收器（GC）并无法降低内存占用。本质上，闭包的链表已经创建，每一个闭包作用域携带一个指向大数组的间接的引用，造成严重的内存泄露。

引用

Meteor的博文解释了如何修复此种问题。在 replaceThing 的最后添加 originalThing = null 。

Chrome 内存剖析工具概览
Chrome 提供了一套很棒的检测 JavaScript 内存占用的工具。与内存相关的两个重要的工具：timeline 和 profiles。