NodeJs内存管理

本文作者：ivweb 王少飞 原文出处：IVWEB社区

nodejs进程内存的使用和原理

V8简介

nodejs代码的运行基于V8，就像java运行需要hotspot，php运行需要zend。V8的由来是，当年web2.0，google的很多业务都在web端，为了提升浏览器中js的执行效率，研发了V8。

V8每发布一个新的版本，nodejs就会相应的发布新版本来使用新版本的V8。

nodejs9以后的版本都是使用的V8 6.2版本。这个版本都有哪些改进：

1 性能优化

• 1）优化了Object.prototype.toString 的性能，比之前提升了6.5倍
• 2）优化了 ES2015 proxies 的性能， 比之前提升了5倍
• 3）优化了 String#includes()的性能，比之前提升了3倍
• 4）哈希查找速度更快，从而提高了Map，Set，WeakMap和WeakSet的性能
• 5）新生代内存垃圾回收采用 Parallel Scavenger算法 2 低内存模式：semi-space为512k，低内存设备减少了发生内存不足的概率。 3 优化正则表达式规则
• 1）支持 dotAll 模式， s匹配模式下，.可以匹配任何字符，包括转义字符
• 2）支持 正向后瞻和负向后瞻 4 字符串的最大长度增加，从 2**28 - 16 增加到 2**30 - 25

内存限制

V8限制了nodejs每个进程的最大内存：64系统1.4G，32位系统0.7G, 这个大小的限制在chrome里面已经够用了，但在服务端nodejs感觉可能不够用。 为什么这样限制? 如果内存超过1.5G时 做一次全量垃圾回收，耗时在1秒左右，这1秒时间内，进程是暂停执行的，对于高平发，高流量的服务影响会很大。

nodejs进程内存的垃圾回收和内存泄漏

V8的GC原理

nodejs进程使用的内存主要在堆（heap）中， 垃圾回收采用分代式，分为新生代和老生代。 新生代中保存存活时间较短的对象，老生代中保存存活时间较长或常驻内存的对象。 新生代通过Parallel Scavenge算法进行垃圾回收，即并行的多线程，复制算法垃圾收集器。 原理是：将堆内存一分为二，每一部分空间称为semispace。在两个semispace空间中，只有一个处于使用状态，另一个处于闲置状态。处于使用状态的semispace空间称为from，处于限制状态的空间称为to空间。

当我们分配对象时，先是在from空间中进行分配。当from空间不够用时就处罚一次新生代的垃圾回收，此时会检查from中的存活对象，并复制到to空间中，非存活的对象会被释放。完成该复制操作后，from空间和to空间互换。此时完成新生代堆内存的一次垃圾回收。

当一个对象经过多次复制依然存活，那么它将被放到老生代内存中。

老生代内存垃圾回收采用 Mark-sweep(标记清除)和Mark-Compact(标记整理), 并进行增量式垃圾回收。 和分代时垃圾回收相比，前者的空间利用率高，但效率低，由于老生代堆内存较大，一次垃圾回收会导致进程暂停时间很长，所以不会经常进行老生代垃圾回收。

实际编码中由于对变量作用域或闭包等使用不当，很可能造成内存的泄漏。在浏览器中由于页面一般情况下只加载一次，或只停留较短的时间，就算有内存泄漏也不会造成很大影响。但在服务端，就算只有一个字节的泄漏，在大量请求和高并发的请求下，泄漏会被放大，随着服务的运行时间越来越长，进程的内存占满，导致内存不足进程退出，就会会对服务器造成很大的影响。

内存泄漏和检测

nodejs内存泄漏检测工具很多，例如：v8-profiler、node-heapdump、node-mtrace、dtrace、memwatch-nenxt。 拿 memwatch-next 举例，使用方法如下：

1 安装 npm i memwatch-next 2 项目代码中：

const memwatch = require('memwatch-next');
memwatch.on('leak', info => {
    reportLogFun(`[leak-${process.pid}]${JSON.stringify(info)}`)
})

memwatch.on('stats', stats => {
    reportLogFun(`[stats-${process.pid}]${JSON.stringify(stats)}`)
})

const md = new memwatch.HeapDiff();
    // .... 业务逻辑代码
const diff = md.end();
reportLogFun(JSON.stringify(diff));

3 收集上报结果 status事件的触发条件是：进行全堆垃圾回收

[stats-3974]{"num_full_gc":16,"num_inc_gc":67155,"heap_compactions":16,"usage_trend":0.1,"estimated_base":7547592,"current_base":7577952,"min":7032208,"max":7610240}

上面的日志表示：进行了16次全堆垃圾回收，进行了67155次增量垃圾回收，进行了16次老生代堆内存整理。

leak时间的触发条件是：进行5次全堆垃圾回收后，内存没有得到释放，产生内存泄漏。

[leak-3974]{"growth":268816,"reason":"heap growth over 5 consecutive GCs (8h 52m 2s) - 29.6 kb/hr"}

上面的日志表示：进行了5次全堆垃圾回收后内存增长了268816 bytes，每小时增加29.6 kb。

diff数据暂时没有收集到数据，根据官方的介绍

意思是，从md初始化开始，到md.end()这段时间内，内存增加了多少，change>details 就是需要关注的内容，增加的最多的就是内存泄漏所在。

参考文献

https://v8project.blogspot.com/2017/09/v8-release-62.html https://bugs.chromium.org/p/chromium/issues/detail?id=738865 http://www.jianshu.com/p/4129a3fce7bb http://book.51cto.com/art/201107/278917.htm https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy https://tc39.github.io/proposal-template-literal-revision/ https://ponyfoo.com/articles/investigating-performance-object-prototype-to-string-es2015 https://zhuanlan.zhihu.com/p/27509546