关于Node.js中内存管理的思考与实践

心已赠人 2023-07-13 12:21 10阅读 0赞

> 本人最近非常痴迷于Node的探索，也对Node用于后端开发感兴趣。所以本着探索的精神，认真重读了一下《深入浅出Node.js》关于内存的部分，觉得自己其实开始不会去关心了解这些内容，现在真的开阔我的眼界，受益匪浅。

> 欢迎大家关注我的公众号《前端小时》，文章同步发送！

![在这里插入图片描述][20200312083124159.gif]

## 01 前言 ##

随着Node的发展，JavaScript的运行已经不再局限于运行在浏览器中了，Node在服务端的应用使得越来越多的问题也显现出来。对于刚接触JavaScript的开发者来说，基本上很少会想到内存分配或者内存泄露的问题，为了跟上潮流，就讲解一下Node是如何合理高效地使用内存，防止内存泄漏。

## 02 V8垃圾回收与内存限制 ##

JavaScript编程不用关心内存的分配和释放的问题，因为它有垃圾回收机制来管理。但是我们对于内存管理更深一步的了解可谓是很少，到底内存是怎么分配的、垃圾回收是怎么运行的？

##### **01 Node与V8** #####

我们先来了解一下这两者是什么关系。首先V8是谷歌开发出来的浏览器引擎，性能可谓是十分优异，使得JavaScript编写服务器程序成为可能。V8的由来是虚拟机专家Lars Bak开发出来的，开发者之前的工作一直都是专注于高性能的虚拟机开发。

Node是一个构建在Chrome的JavaScript运行时平台，由此一来，Node的高性能就如同抱住了V8的大腿，可以随着V8的升级而享受更好的性能。

##### **02 V8的内存限制** #####

Node通过JavaScript使用内存的话会有限制，而且Node无法直接操作大内存对象。64位系统下约为1.4GB，而32位系统下约为0.7GB。原因是Node基于V8构建，它的内存分配和管理都是由V8来控制，虽然在浏览器下这种分配机制没有问题，但是在Node中却是有问题的。

##### **03 V8的对象分配** #####

在V8中，所有的JavaScript对象都是通过堆来分配的，对象占用的内存空间大小是不确定的。  
![在这里插入图片描述][20200312083144520.png_x-oss-process_image]

当我们在代码里写上一些变量的时候，我们就会向堆中的内存空间进行申请。我们上面说过V8是有内存分配限制的，这是因为V8的垃圾回收机制影响。我们试想一下假如有1.5GB的垃圾需要等待回收，而V8的垃圾回收机制运行一次需要每50毫秒以上，在这段时间内，程序会无法运行。

假如说我非要打开这个限制也不是不行，我们可以在Node的启动时候更改一下参数即可：

node --max-old-space-size=1700   xxx.js    //单位是MB
    node --max-new-space-size=1024  xxx.js    //单位是KB

上面代码的意思就是新生代和老生代空间的更改，稍后解析什么是新生代和老生代空间。

##### **04 V8垃圾回收机制** #####

在V8中，我们知道内存空间可以分为新生代和老生代。新生代空间主要是保存一些存活时间较短的对象，而老生代空间主要存储一些存活时间较长的对象。

之前说过64位系统只能使用约1.4GB，32位只能使用0.7GB的空间。这空间是包含新生代和老生代空间，且老生代的空间比新生代要多。  
![在这里插入图片描述][20200312083201144.png_x-oss-process_image]

V8主要采用两种不同的算法，分别作用于新生代和老生代，因为两者的关系不一样。主要有类算法，第一是Scavenge算法，第二是Mark-Sweep & Mark-Compact。新老生代的特点如下：

**新生代：存活对象较少**

**老生代：存活对象较多**

①Scavenge算法

*  把新生代空间一分为二，为From空间和To空间
 *  内存先分配到From空间，垃圾回收会检查From空间存活情况
 *  把From空间的存活对象移到To空间，释放From空间
 *  把From和To空间对换

这就完成了垃圾回收的一次清理过程。  
![在这里插入图片描述][20200312083218210.png_x-oss-process_image]

②Mark-Sweep算法

*  遍历堆中的所有对象，标记存活的对象
 *  清除没有被标记的对象  
    ![在这里插入图片描述][20200312083233344.png_x-oss-process_image]

由于老生代空间中，存活的对象较多，使用 Scavenge 算法的话遍历的时间会相对来说比较长，而且还会浪费一半的空间来存放对象，效率比较低。总的来说，Scavenge 算法复制存活的对象，而 Mark-Sweep 算法清除死亡的对象。

③Mark-Compact算法

我们看到上面这种算法回收一次过后\*\*产生了零碎的内存空间**，假如这时候进来一个比较大的内存对象就无法完成分配，提前触发新一轮的垃圾回收机制。所以基于这个问题，在原来算法的基础上，采用**压缩\*\*的办法，在标记活对象的过程中，对象会往一边移动。然后标记完成之后直接清除边界的内存。  
![在这里插入图片描述][20200312083249682.png_x-oss-process_image]

④Incremental Marking算法

与前面三种不一样的是，这种算法\*\*采用了“步进”的方式\*\*进行，因为垃圾回收机制运行一次的时间也是有的，对于垃圾回收机制运行时间过长，那么页面的应用逻辑都要停下来等待，这种影响也是比较大的。

对于新生代来说不用担心这个问题，因为新生代存活对象比较少，内存占用也比较小。但是对于老生代来说，**对象比较多也比较大**，停顿造成的影响大，所以必须要让应用逻辑受垃圾回收的影响小一点。

因此采用“步进”的方式，垃圾回收机制和逻辑代码\*\*分段执行\*\*，缓解停顿时间过长而导致应用逻辑执行不了的问题。  
![在这里插入图片描述][20200312083304915.png_x-oss-process_image]

## 03 内存的使用 ##

关于内存的话我们就不得不聊一下作用域的问题了。我们所写的代码中，可以形成作用域的无非就是几个方面，有函数、with以及全局作用域。

var A = function(){ 
      var user = { }
    };
    A();

我们在执行这个函数的时候就会创建一个函数作用域，也会创建一个局部的变量user。这个user只能在函数作用域里面使用，函数执行完毕之后作用域销毁，同时对象也失去引用，其引用的对象下次的垃圾回收时就会释放。这里的user是一个小对象，就会分配在新生代的from空间中。

我们知道作用域会有一个作用域链的概念，就是在当前的作用域找不到变量之后就会向父级的作用域寻找，一直向外扩散，找不到就会抛出未定义的错误。

小结：

*  闭包没有及时释放会造成内存泄漏，常见的有`定时器`
 *  `全局变量`，此种变量需要进程退出才会被释放，引用的对象就会在`常驻内存`中（`老生代`）

#### V8堆内存相关的指标 ####

我们可以调用process.memoryUsage()查看Node进程的内存使用情况。  
![format_png][]

`heapTotal`（堆中总共申请的内存） 和 `heapUsed`（堆中使用的内存） 代表 V8 的内存使用情况。  
`external` 代表 V8 管理的，绑定到 Javascript 的 C++ 对象的内存使用情况。  
`rss` 是常驻空间大小, 是给这个进程分配了多少物理内存（占总分配内存的一部分），包含所有的 C++ 和 JavaScript 对象与代码。

上面我们说过`老生代的内存空间`大概在`1400MB`左右，为了验证一下，不惜代价搞了一波内存泄漏的操作，看一下到底内存是怎么被消耗掉的。我们手动构造了一个全局的对象，让它放在常驻内存中，也就是老生代中。

结果也是非常的amazing啊，运行不到10次内存就消耗完了。大家可以想象一下假如你的内存有泄露的显现是多么可怕，最终就会导致整个进程的退出了。这里我们可以清楚地看到，老生代的空间大概是1400MB左右，因为假如再执行一次就会超出范围了。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjcyNDE3Ng_size_16_color_FFFFFF_t_70_pic_center]

#### 堆外内存 ####

上面我们测试的是堆中的内存，但是我们发现最后一次总共申请的内存只有1290.33MB，但是堆中却占据了1300.81MB，那么多出来的那部分是哪里的呢？没错，其实就是堆外内存。这部分的内存是不受V8控制的。

我们改变一下上面的“吃人”函数：

function useMem() { 
      var size = 200 * 1024 * 1024;
      var buffer = new Buffer(size);
      for (var i = 0; i < size; i++) { 
        buffer[i] = 0;
      }
      return buffer;
    }

![format_png 1][]

我们发现循环的21次都成功运行，而且我们看到常驻内存那里已经超过了V8的限制。这里的buffer对象是不受V8控制和分配的，属于堆外内存。

Node的内存主要是通过V8进行分配和Node自行分配的部分。但是受V8垃圾回收限制的主要是V8的堆内存。

## 04 小结 ##

Node将JavaScript的主要应用扩展到了服务器端，所以我们考虑的细节也要和浏览器的不同，更多的是对内存资源的分配问题，稍有不慎可能会写出一些内存泄漏的问题，使得垃圾回收机制不能清理释放内存，严重可能会导致服务器崩溃。

所以平时我们写代码也要谨慎一点，不要写全局变量或者频繁使用闭包，这些如果没有正确释放内存的话也会导致内存泄漏。内存泄漏的本质其实就是应当回收的对象但是却没有被回收（转移到老生代空间）。

参考文章：

*  深入浅出Node.js  
    ![在这里插入图片描述][20200312083322224.gif]

[20200312083124159.gif]: https://img-blog.csdnimg.cn/20200312083124159.gif
[20200312083144520.png_x-oss-process_image]: https://img-blog.csdnimg.cn/20200312083144520.png?x-oss-process=image
[20200312083201144.png_x-oss-process_image]: https://img-blog.csdnimg.cn/20200312083201144.png?x-oss-process=image
[20200312083218210.png_x-oss-process_image]: https://img-blog.csdnimg.cn/20200312083218210.png?x-oss-process=image
[20200312083233344.png_x-oss-process_image]: https://img-blog.csdnimg.cn/20200312083233344.png?x-oss-process=image
[20200312083249682.png_x-oss-process_image]: https://img-blog.csdnimg.cn/20200312083249682.png?x-oss-process=image
[20200312083304915.png_x-oss-process_image]: https://img-blog.csdnimg.cn/20200312083304915.png?x-oss-process=image
[format_png]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9pbWdrci5jbi1iai51ZmlsZW9zLmNvbS9kMjZlZmUyMC02YTgyLTQ5ZmItOGMxYi1iM2Q4OWVkYWNhYTYucG5n?x-oss-process=image/format,png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjcyNDE3Ng_size_16_color_FFFFFF_t_70_pic_center]: https://img-blog.csdnimg.cn/20200506185256709.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjcyNDE3Ng==,size_16,color_FFFFFF,t_70#pic_center
[format_png 1]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9pbWdrci5jbi1iai51ZmlsZW9zLmNvbS85YzZkNzkyMC1jMTBkLTQ0YTYtYTA1MC0zNTc0ZTg1MzFmYjEucG5n?x-oss-process=image/format,png
[20200312083322224.gif]: https://img-blog.csdnimg.cn/20200312083322224.gif