如何分析 Node.js 中的内存泄漏

内存泄漏的几种情况

一、全局变量

a = 10;//未声明对象。global.b = 11;//全局变量引用

这种比较简单的原因，全局变量直接挂在 root 对象上，不会被清除掉。

二、闭包

function out() {
const bigData = new Buffer(100);
inner = function () {
void bigData;
}}

闭包会引用到父级函数中的变量，如果闭包未释放，就会导致内存泄漏。上面例子是 inner 直接挂在了 root 上，那么每次执行 out 函数所产生的 bigData 都不会释放，从而导致内存泄漏。

需要注意的是，这里举得例子只是简单的将引用挂在全局对象上，实际的业务情况可能是挂在某个可以从 root 追溯到的对象上导致的。

三、事件监听

Node.js 的事件监听也可能出现的内存泄漏。例如对同一个事件重复监听，忘记移除（removeListener），将造成内存泄漏。这种情况很容易在复用对象上添加事件时出现，所以事件重复监听可能收到如下警告：

(node:2752) Warning: Possible EventEmitter memory leak detected。11 haha listeners added。Use emitter。setMaxListeners() to increase limit

例如，Node.js 中 Agent 的 keepAlive 为 true 时，可能造成的内存泄漏。当 Agent keepAlive 为 true 的时候，将会复用之前使用过的 socket，如果在 socket 上添加事件监听，忘记清除的话，因为 socket 的复用，将导致事件重复监听从而产生内存泄漏。

原理上与前一个添加事件监听的时候忘了清除是一样的。在使用 Node.js 的 http 模块时，不通过 keepAlive 复用是没有问题的，复用了以后就会可能产生内存泄漏。所以，你需要了解添加事件监听的对象的生命周期，并注意自行移除。

关于这个问题的实例，可以看 Github 上的 issues（node Agent keepAlive 内存泄漏）

四、其他原因

还有一些其他的情况可能会导致内存泄漏，比如缓存。在使用缓存的时候，得清楚缓存的对象的多少，如果缓存对象非常多，得做限制最大缓存数量处理。还有就是非常占用 CPU 的代码也会导致内存泄漏，服务器在运行的时候，如果有高 CPU 的同步代码，因为Node.js 是单线程的，所以不能处理处理请求，请求堆积导致内存占用过高。

定位内存泄漏

一、重现内存泄漏情况

想要定位内存泄漏，通常会有两种情况：

• 对于只要正常使用就可以重现的内存泄漏，这是很简单的情况只要在测试环境模拟就可以排查了。

• 对于偶然的内存泄漏，一般会与特殊的输入有关系。想稳定重现这种输入是很耗时的过程。如果不能通过代码的日志定位到这个特殊的输入，那么推荐去生产环境打印内存快照了。需要注意的是，打印内存快照是很耗 CPU 的操作，可能会对线上业务造成影响。

快照工具推荐使用 heapdump 用来保存内存快照，使用 devtool 来查看内存快照。使用 heapdump 保存内存快照时，只会有 Node.js 环境中的对象，不会受到干扰（如果使用 node-inspector 的话，快照中会有前端的变量干扰）。

PS：安装 heapdump 在某些 Node.js 版本上可能出错，建议使用 npm install heapdump -target=Node.js 版本来安装。

二、打印内存快照

将 heapdump 引入代码中，使用 heapdump.writeSnapshot 就可以打印内存快照了了。为了减少正常变量的干扰，可以在打印内存快照之前会调用主动释放内存的 gc() 函数（启动时加上 --expose-gc 参数即可开启）。

• const heapdump = require('heapdump');const save = function () {


•  gc();


•  heapdump.writeSnapshot('./' + Date.now() + '.heapsnapshot');}



在打印线上的代码的时候，建议按照内存增长情况来打印快照。heapdump 可以使用 kill 向程序发送信号来打印内存快照（只在 *nix 系统上提供）。

• kill -USR2



推荐打印 3 个内存快照，一个是内存泄漏之前的内存快照，一个是少量测试以后的内存快照，还有一个是多次测试以后的内存快照。

第一个内存快照作为对比，来查看在测试后有哪些对象增长。在内存泄漏不明显的情况下，可以与大量测试以后的内存快照对比，这样能更容易定位。

三、对比内存快照找出泄漏位置

通过内存快照找到数量不断增加的对象，找到增加对象是被谁给引用，找到问题代码，改正之后就行，具体问题具体分析，这里通过我们在工作中遇到的情况来讲解。

• const {EventEmitter} = require('events');const heapdump = require('heapdump');global.test = new EventEmitter();heapdump.writeSnapshot('./' + Date.now() + '.heapsnapshot');function run3() {


•  const innerData = new Buffer(100);


•  const outClosure3 = function () {


•    void innerData;


•  };


•  test.on('error', () => {


•    console.log('error');


•  });


•  outClosure3();}for(let i = 0; i < 10; i++) {


•  run3();}gc();heapdump.writeSnapshot('./' + Date.now() + '.heapsnapshot');



这里是对错误代码的最小重现代码。

首先使用 node --expose-gc index.js 运行代码，将会得到两个内存快照，之后打开 devtool，点击 profile，载入内存快照。打开对比，Delta 会显示对象的变化情况，如果对象 Delta 一直增长，就很有可能是内存泄漏了。