4 types of JavaScript memory leaks and how to avoid them-JS Tutorial-php.cn

Original text: 4 Types of Memory Leaks in JavaScript and How to Get Rid Of Them

Translation from: Alon's Blog

This article will explore common client-side JavaScript memory leaks, And how to use Chrome Dev Tools to find problems.

Introduction
Memory leaks are a problem that every developer will eventually face, and they are the source of many problems: sluggish response, crashes, high latency, and other application problems .

What is a memory leak?
Essentially, a memory leak can be defined as: when the application no longer needs to occupy the memory, for some reason, the memory is not reclaimed by the operating system or the available memory pool. Programming languages vary in how they manage memory. Only developers know best which memory is no longer needed and can be reclaimed by the operating system. Some programming languages provide language features that help developers do this kind of thing. Others rely on developers to be clear about whether memory is needed.

JavaScript Memory Management
JavaScript is a garbage collected language. Garbage collection languages help developers manage memory by periodically checking whether previously allocated memory is reachable. In other words, garbage-collected languages alleviate the "memory is still available" and "memory is still reachable" problems. The difference between the two is subtle but important: only the developer knows which memory will still be used in the future, while unreachable memory is algorithmically determined and marked, and is promptly reclaimed by the operating system.

JavaScript Memory Leak
The main cause of memory leaks in garbage collected languages is unwanted references. Before understanding it, you need to understand how the garbage collection language distinguishes between reachable and unreachable memory.

Mark-and-sweep
The algorithm used by most garbage collection languages is called Mark-and-sweep. The algorithm consists of the following steps:

1. The garbage collector creates a "roots" list. Roots are usually references to global variables in your code. In JavaScript, the "window" object is a global variable and is treated as root. The window object always exists, so the garbage collector can check whether it and all its child objects exist (i.e., are not garbage);
2. All roots are checked and marked as active (i.e., are not garbage). All sub-objects are also checked recursively. All objects starting from root are not considered garbage if they are reachable.
3. All unmarked memory will be treated as garbage. The collector can now release the memory and return it to the operating system.
Modern garbage collectors have improved algorithms, but the essence is the same: reachable memory is marked, and the rest is garbage collected.

Unnecessary reference means that the developer knows that the memory reference is no longer needed, but for some reason, it is still left in the active root tree. In JavaScript, an unwanted reference is a variable that remains in the code and is no longer needed but points to a piece of memory that should be freed. Some people think this is a developer error.

In order to understand the most common memory leaks in JavaScript, we need to understand how references are easily forgotten.

Three types of common JavaScript memory leaks
1: Unexpected global variables
JavaScript handles undefined variables in a loose way: undefined The variable will create a new variable in the global object. In browsers, the global object is window .

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

Copy after login

The truth is:

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

Copy after login

Forgot to use var internally in function foo and accidentally created a global variable. This example leaks a simple string, which is innocuous, but there are worse things.

Another unexpected global variable may be created by this:

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

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

Copy after login

Quote

In JavaScript file Adding 'use strict' to the header can avoid such errors. Enable strict mode parsing of JavaScript to avoid unexpected global variables.

Global Variable Notes

Although we discussed some unexpected global variables, there are still some explicit global variables that generate garbage. They are defined as non-recyclable (unless defined as empty or reallocated). Care needs to be taken especially when global variables are used to temporarily store and process large amounts of information. If you must use a global variable to store a large amount of data, be sure to set it to null or redefine it after use. One major cause of increased memory consumption related to global variables is caching. Caching data is for reuse, and the cache must have an upper limit on its size to be useful. High memory consumption causes the cache to breach its upper limit because the cached content cannot be reclaimed.

2: The forgotten timer or callback function
Using setInterval in JavaScript is very common. A common piece of code:

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

Copy after login

此例说明了什么：与节点或数据关联的计时器不再需要，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);

Copy after login

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

老版本的 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 回收。
}

Copy after login

此外还要考虑 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);

Copy after login

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

引用

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

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