前言

东哥是一个平凡的前端攻城狮，北邮网研院研二在读，刚接触Node不久，心里充满了对Node的好奇和崇拜，只听噗通一声，掉入了Node的坑。。。

于是东哥开始疯狂地看Node相关的书籍，这不，就学到了Node.js内存管理这一章。

他读到：“对于那些短时间执行的场景，比如网页应用、命令行工具，内存的管理似乎没有太大的必要。因为运行时间短，随着进程的退出，内存得到释放，几乎没有内存泄露，即使存在内存使用过多的情况，也只会影响到终端用户。所以，我们在使用JavaScript进行前端开发的过程中，很少会考虑内存管理的问题”。

东哥觉得很有道理，产生了共鸣：“是啊，干了这么久前端，写了这么多网页，还真没考虑过内存问题！”

顺便提一句，东哥还是一个算法狂人，曾经使用Java这门走遍天下的语言刷遍了各大平台（Leetcode、剑指offer、牛客网。。。）的算法题，可谓十分强势！

东哥很聪明，心想：既然Node.js是一个针对服务器端开发的平台，也应该和Java一样存在一些诸如内存泄露、内存分配优化等问题吧。

他读到：“随着Node.js在服务器端的广泛应用，其他语言在内存管理上存在的问题在JavaScript中也暴露了出来。”

心想：“有道理，让俺一睹其究竟！”

V8垃圾回收机制与内存限制

Node与V8

2009年，Node的创始人Ryan Dahl选择了V8来作为Node的JavaScript脚本引擎，在第三次浏览器大战中，Google的Chrome浏览器凭借V8的优异性能成为焦点。

V8内存限制

在一般的后端开发语言中，在基本的内存使用上没有什么限制，然而在Node中通过JavaScript使用内存是就会发现只能使用部分内存（64位系统下约为1.4GB，32位系统下约为0.7GB）。

最近，东哥刚入手了一台32GB内存的服务器用于大数据分析处理，有一天，他试图将一个2GB的文件读入内存中进行字符串分析处理，这岂不是小菜一碟？可是。。。东哥失败了。。。

造成这个问题的主要原因在于Node是基于V8构建的，所以在Node中使用的JavaScript对象基本上都是通过V8自己的方式进行管理分配的。V8的这套内存管理机制对于浏览器端使用起来可谓绰绰有余，但在服务器端却大大限制了开发者随心所欲地使用大内存的想法。

V8对象分配

在V8中，所有的JavaScript对象都是通过堆来进行分配的。V8堆示意图如下：

 可以使用process.memoryUsage()来查看内存使用量：

其中，rss是resident set size的缩写，即进程的常驻内存部分。进程的内存总共有几部分，一部分是rss，其余部分在交换区（swap）或者文件系统（filesystem）中；除了rss外，heapTotal和heapUsed对应V8堆内存的信息，heapTotal是堆中总共申请的内存空间，heapUsed是目前堆中使用的内存空间。

除此以外，还可以使用os模块的totalmem()和freemem()两个方法查看操作系统的内存使用情况，它们分别返回的是系统的总内存和闲置内存，以字节为单位：

可见，我这台屌丝机系统总内存为4GB，当前闲置内存大致为2.8GB。

东哥在熟悉了查看内存信息的方法后一直很纳闷，V8为什么要限制堆的大小呢，这样做是不是会让Node内存使用性能变得很低下？

表层原因是因为V8最初是为浏览器而设计的，不太可能有用到大量内存的情况。而深层原因是V8的垃圾回收机制的限制。

当然，我们也可以自行配置内存使用空间，因为V8也给开发者提供了选项让我们使用更多的内存。示例如下：

node --max-old-space-size=1700 test.js //单位为MBnode --max-new-space-size=1700 test.js //单位为KB　　

V8垃圾回收机制

V8的垃圾回收策略主要是基于分代式垃圾回收机制。在V8中，主要将内存分为新生代和老生代。新生代中的对象为存活时间较短的对象，老生代中的对象为存活时间较长的或常驻内存的对象。

涉及到的垃圾回收算法算法主要有三种：

关于算法的细节，由于时间有限，就不在这里详细描述了，大家可以对比着看看各种算法的特点。

如何查看垃圾回收日志？

查看垃圾回收日志的方式主要是在启动时添加--trace_gc参数。将会在gc.log文件中得到所有的垃圾回收信息：

gc.log文件大概长这个样：

通过查看gc.log文件，我们可以找出回收哪些阶段比较耗时，触发的原因是什么。

另外，通过在Node启动时使用--prof参数，可以得到V8执行时的性能分析数据，其中包含了垃圾回收执行时占用的时间。我在本地写了一个test.js文件：

for(var i=0;i<1000000;i++){    var a = {};}

执行如下命令：

会在目录下得到一个v8.log日志文件，长这样：

显然，该文件不具备可读性。。。所幸，V8提供了linux-tick-processor工具用于统计日志信息。我们执行：

就能得到统计结果，大致如下：

统计内容较多。其中，垃圾回收部分如下：

由于不断分配对象，垃圾回收所占的时间为5.4%.按此比例，时间循环执行1000毫秒的过程中要给出54毫秒用于垃圾回收。

高效使用内存

作用域（链）

在JavaScript中能形成作用域的有函数调用、with语句以及全局作用域。以如下代码为例：

var foo = function(){   var local = {}; };

foo()函数在每次被调用时会创建对应的作用域，函数执行结束后，该作用域将会销毁。同时作用域中申明的局部变量随着作用域的销毁而销毁，局部变量local失效，其引用的对象将会在下次垃圾回收时被释放。

而作用域链是指JavaScript执行过程中变量的查找会沿着一层一层的作用域形成的链进行，一直到全局作用域。

所以，主动释放变量可以合理地利用作用域（链）原理，让我们高效地使用内存。

闭包

闭包大家再熟悉不过了，在JavaScript中，实现外部作用域访问内部作用域中的变量的方法叫做闭包。而闭包的存在，会使得局部变量常驻内存，不能被及时释放回收。

所以，闭包要慎用。即使使用，也要在适当的时候主动释放局部变量。

内存泄露

内存泄露的原因主要有如下几个：

1、缓存

2、队列消费不及时

3、作用域未及时释放

所以，预防措施主要有如下几个：

1、慎将内存当做缓存使用

2、关注队列状态

3、及时释放作用域中的对象和变量

内存泄露排查

 推荐几个排查工具，可通过npm安装使用：

1、v8-profiler

2、node-heapdump

3、node-mtrace

4、dtrace

5、node-memwatch

东哥学Node的故事——内存管理