js内存深刻学习（二）

时间 2019-12-01

标签内存深刻学习栏目 JavaScript 繁體版

原文原文链接

继上一篇文章 js内存深刻学习（一）

3. 内存泄漏

对于持续运行的服务进程（daemon），必须及时释放再也不用到的内存。不然，内存占用愈来愈高，轻则影响系统性能，重则致使进程崩溃。对于再也不用到的内存，没有及时释放，就叫作内存泄漏（memory leak）html

3.1 node.js内存补充

node.js中V8中的内存分代：node

新生代：存活时间较短的对象，会被GC自动回收的对象及做用域，好比不被引用的对象及调用完毕的函数等。
老生代：存活时间较长或常驻内存的对象，好比闭包由于外部仍在引用内部做用域的变量而不会被自动回收，故会被放在常驻内存中，这种就属于在新生代中持续存活，因此被移到了老生代中，还有一些核心模块也会被存在老生代中，例如文件系统(fs)、加密模块（crypto）等
如何调整内存分配大小：
- 启动node进程时添加参数便可 node --max-old-space-size=1700 <project-name>.js 调整老生代内存限制，单位为MB（貌似最高也只能1.8G的样子）（老生代默认限制为 64/32 位 => 1400/700 MB）git
- node --max-new-space-size=1024 <project-name>.js 调整新生代内存限制，单位为KB(老生代默认限制为 64/32 位 => 32/16 MB) 接！github

内存回收时使用的算法：算法

Scavenge 算法（用于新生代，具体实现中采用 Cheney 算法）chrome
- 算法的结果通常只有两种，空间换时间或时间换空间，Cheney属于前者
- 它将现有的空间分半，一个做为 To 空间，一个做为 From 空间，当开始垃圾回收时会检查 from 空间中存活的对象并赋复制入 To 空间中，而非存活就会被直接释放，完成复制后，二者职责互换，下一轮回收时重复操做，也就是说咱们本质上只使用了一半的空间，明显放在老生代这么大的内存浪费一半就很不合适，并且老生代通常生命周期较长，须要复制的对象过多，正所以因此它就被用于新生代中，新生代的生命周期短，通常不会有这么大的空间须要留存，相对来讲这是效率最高的选择，刚和适合这个算法
- 前面咱们提到过，若是对象存活时间较长或较大就会重新生代移到老生代中，那么何种条件下会过渡呢，知足如下2个条件中的一个就会被过渡
  - 在一次 from => to 的过程当中已经经历过一次 Scavenge 回收，即通过一次新生代回收后，再下次回收时仍然存在，此时这个对象将会从本次的 from 中直接复制到老生代中，不然则正常复制到 To
  - from => to 时，占用 to 的空间达到 25% 时，将会因为空间使用过大自动晋升到老生代中
Mark-Sweep & Mark-Compact（用于老生代的回收算法）数组
- 新生代的最后咱们提到过，Cheney 会浪费一半的空间，这个缺点在老生代是不可原谅的，毕竟老生代有 1.4G 不是，浪费一半就是 700M 啊，并且每次都去复制这么多常驻对象，简直浪费，因此咱们是不可能继续采纳 Scavenge 的；
- mark-sweep 顾名思义，标记清除，上一条咱们提到过，咱们要杜绝大量复制的状况，由于大部分都是常驻对象，因此 mark-sweep 只会标记死去的老对象，并将其清除，不会去作复制的行为，由于死对象在老生代中占比是很低的，但此时咱们很明显看到它的缺点就是清除死去的部分后，可能会形成内存的不连续而在下次分配大对象前马上先触发回收，可是其实须要回收的那些在上轮已经被清除了，只是没有将活着的对象连续起来。缺点举例：这就像 buffer 同样，在一段 buffer 中，咱们清除了其中断断续续的部分，这些部分就为空了，可是剩下的部分会变得不连续，下次咱们分配大对象进来时，大对象是一个总体，咱们不可能将其打散分别插入本来断断续续的空间中，不然将变的不连续，下次咱们去调用这个大对象时也将变得不连续，这就没有意义了，这就像你将一我的要塞进一个已经装满了家具的房间里同样，各个家具间可能会存在空隙，可是你一个总体的人怎么可能打散分散到这些空间？并在下次调用时在拼到一块儿呢（什么纳米单位的别来杠，你能够本身想其余例子）
- 在这个缺点的基础上，咱们使用了 mark-compact 来解决，它会在 mark-sweep 标记死亡对象后，将活着的对象所有向一侧移动，移动完成后，一侧全为生，一侧全为死，此时咱们即可以直接将死的一侧直接清理，下次分配大对象时，直接从那侧拼接上便可，仿佛就像把家具变成工整了，将一些没用的小家具整理到一侧，将有用的其余家具所有工整摆放，在下次有新家具时，将一侧的小家具所有丢掉，在将新的放到有用的旁边紧密结合。

buffer 声明的都为堆外内存，它们是由系统限定而非 V8 限定，直接由 C++ 进行垃圾回收处理，而不是 V8，在进行网络流与文件 I/O 的处理时，buffer 明显知足它们的业务需求，而直接处理字符串的方式，显然在处理大文件时有心无力。因此由 V8 处理的都为堆内内存。浏览器

3.2 识别方法

一、浏览器方法缓存

打开开发者工具，选择 Memory
在右侧的Select profiling type字段里面勾选 timeline
点击左上角的录制按钮。
在页面上进行各类操做，模拟用户的使用状况。
一段时间后，点击左上角的 stop 按钮，面板上就会显示这段时间的内存占用状况。

二、命令行方法使用 Node 提供的 process.memoryUsage 方法。网络

console.log(process.memoryUsage());
// 输出
{ 
  rss: 27709440,		// resident set size，全部内存占用，包括指令区和堆栈
  heapTotal: 5685248,   // "堆"占用的内存，包括用到的和没用到的
  heapUsed: 3449392,	// 用到的堆的部分
  external: 8772 		// V8 引擎内部的 C++ 对象占用的内存
}

判断内存泄漏，以heapUsed字段为准。

3.3 常见内存泄露场景

意外的全局变量
```
function foo(arg) {
    bar = "this is a hidden global variable"; // winodw.bar = ...
}
或者

function foo() {
        this.variable = "potential accidental global";
    }
    
    // Foo 调用本身，this 指向了全局对象（window）
    // 而不是 undefined
    foo();
```
解决方法：在 JavaScript 文件头部加上 'use strict'，使用严格模式避免意外的全局变量，此时上例中的this指向undefined。

尽管咱们讨论了一些意外的全局变量，可是仍有一些明确的全局变量产生的垃圾。它们被定义为不可回收（除非定义为空或从新分配）。尤为当全局变量用于临时存储和处理大量信息时，须要多加当心。若是必须使用全局变量存储大量数据时，确保用完之后把它设置为 null 或者从新定义。与全局变量相关的增长内存消耗的一个主因是缓存。缓存数据是为了重用，缓存必须有一个大小上限才有用。高内存消耗致使缓存突破上限，由于缓存内容没法被回收。

被遗忘的计时器或回调函数

如计时器的使用：
```
var someResource = getData();
    setInterval(function() {
        var node = document.getElementById('Node');
        if(node) {
            // 处理 node 和 someResource
            node.innerHTML = JSON.stringify(someResource));
        }
    }, 1000);
```
定义了一个someResource变量，变量在计时器setInterval内部一直被引用着，成为一个闭包使用，即便移除了Node节点，因为计时器setInterval没有中止。其内部仍是有对someResource的引用，因此v8不会释放someResource变量的。
```
var element = document.getElementById('button');
    function onClick(event) {
        element.innerHTML = 'text';
    }
    
    element.addEventListener('click', onClick);
```
对于上面观察者的例子，一旦它们再也不须要（或者关联的对象变成不可达），明确地移除它们很是重要。老的 IE 6 是没法处理循环引用的。由于老版本的 IE 是没法检测 DOM 节点与 JavaScript 代码之间的循环引用，会致使内存泄漏。

可是，现代的浏览器（包括 IE 和 Microsoft Edge）使用了更先进的垃圾回收算法（标记清除），已经能够正确检测和处理循环引用了。即回收节点内存时，没必要非要调用 removeEventListener 了。（不是很理解）
对DOM 的额外引用

若是把DOM 存成字典（JSON 键值对）或者数组，此时，同一个 DOM 元素存在两个引用：一个在 DOM 树中，另外一个在字典中。若是要回收该DOM元素内存，须要同时清除掉这两个引用。
```
var elements = {
        button: document.getElementById('button'),
        image: document.getElementById('image'),
        text: document.getElementById('text')
    };
    
    document.body.removeChild(document.getElementById('button'));
    // 此时，仍旧存在一个全局的 #button 的引用(在elements里面)。button 元素仍旧在内存中，不能被回收。
```
若是代码中保存了表格某一个 <td> 的引用。未来决定删除整个表格的时候，咱们觉得 GC 会回收除了已保存的 <td> 之外的其它节点。实际状况并不是如此：此 <td> 是表格的子节点，子元素与父元素是引用关系。因为代码保留了 <td> 的引用，致使整个表格仍待在内存中。

因此保存 DOM 元素引用的时候，要当心谨慎。
闭包
```
var theThing = null;
    var replaceThing = function () {
      var originalThing = theThing;
      var unused = function () {
        if (originalThing)
          console.log("hi");
      };
      theThing = {
        longStr: new Array(1000000).join('*'),
        someMethod: function () {
          console.log(someMessage);
        }
      };
    };
    setInterval(replaceThing, 1000);
```
代码片断作了一件事情：每次调用 replaceThing ，theThing 获得一个包含一个大数组和一个新闭包（someMethod）的新对象。同时，变量 unused 是一个引用 originalThing 的闭包（先前的 replaceThing 又调用了 theThing ）。思绪混乱了吗？最重要的事情是，闭包的做用域一旦建立，它们有一样的父级做用域，做用域是共享的。someMethod 能够经过 theThing 使用，someMethod 与 unused 分享闭包做用域，尽管 unused 从未使用，它引用的 originalThing 迫使它保留在内存中（防止被回收）。当这段代码反复运行，就会看到内存占用不断上升（新建的多个originalThing一直被保存在内存中），垃圾回收器（GC）并没有法下降内存占用。本质上，闭包的链表已经建立，每个闭包做用域携带一个指向大数组的间接的引用，形成严重的内存泄漏。

这时候应该在 replaceThing 的最后添加 originalThing = null，主动解除对象引用。

3.4 具体例子

timeline 标签擅长作这些。在 Chrome 中打开例子，打开 Dev Tools ，切换到 timeline，勾选 memory 并点击记录按钮，而后点击页面上的 The Button 按钮。过一阵中止记录看结果：

两种迹象显示出现了内存泄漏，图中的 Nodes（绿线）和 JS heap（蓝线）。Nodes 稳定增加，并未降低，这是个显著的信号。

JS heap 的内存占用也是稳定增加。因为垃圾收集器的影响，并不那么容易发现。图中显示内存占用忽涨忽跌，实际上每一次下跌以后，JS heap 的大小都比原先大了。换言之，尽管垃圾收集器不断的收集内存，内存仍是周期性的泄漏了。

参考文章

https://github.com/yygmind/blog

http://www.cnblogs.com/vajoy/p/3703859.html

https://jinlong.github.io/2016/05/01/4-Types-of-Memory-Leaks-in-JavaScript-and-How-to-Get-Rid-Of-Them/

https://blog.csdn.net/yolo0927/article/details/80471220