2019深入理解Node.js垃圾回收与内存管理

发布者: xiaozhimn

使用JavaScript进行前端开发时几乎完全不需要关心内存管理问题,对于前端编程来说,V8限制的内存几乎不会出现用完的情况,但是由于后端程序往往进行的操作更加复杂,并且长期运行在服务器不重启,如果不关注内存管理,导致内存泄漏,就算1TB,也会很快用尽。Node.js构建于V8引擎之上,因此本文首先讲解V8引擎的内存管理机制,了解底层原理后,再讲解Node开发中的内存管理与优化。

一、V8的内存管理机制

1.1 内存管理模型

Node程序运行中,此进程占用的所有内存称为常驻内存(Resident Set)。

常驻内存由以下部分组成:
代码区(Code Segment):存放即将执行的代码片段
栈(Stack):存放局部变量
堆(Heap):存放对象、闭包上下文
堆外内存:不通过V8分配,也不受V8管理。Buffer对象的数据就存放于此。

v8

V8内存模型
除堆外内存,其余部分均由V8管理。

栈(Stack)的分配与回收非常直接,当程序离开某作用域后,其栈指针下移(回退),整个作用域的局部变量都会出栈,内存收回。
最复杂的部分是堆(Heap)的管理,V8使用垃圾回收机制进行堆的内存管理,也是开发中可能造成内存泄漏的部分,是程序员的关注点,也是本文的探讨点。
通过process.memoryUsage()可以查看此Node进程的内存使用状况:
内存使用状况
rss是Resident Set Size的缩写,为常驻内存的总大小,heapTotal是V8为堆分配的总大小,heapUsed是已使用的堆大小。可以看到,rss是大于heapTotal的,因为rss包括且不限于堆。

1.2 堆内存限制

默认情况下,V8为堆分配的内存不超过1.4G:64位系统1.4G,32位则仅分配0.7G。也就是说,如果你想使用Node程序读一个2G的文件到内存,在默认的V8配置下,是无法实现的。不过我们可以通过Node的启动命令更改V8为堆设置的内存上限:

//更改老年代堆内存
--max-old-space-size=3000 // 单位为MB
// 更改新生代堆内存
--max-new-space-size=1024 // 单位为KB
堆的内存上限在启动时就已经决定,无法动态更改,想要更改,唯一的方法是关闭进程,使用新的配置重新启动。

1.3 V8的垃圾回收机制

V8将堆中的对象分为两类:
新生代:年轻的新对象,未经历垃圾回收或仅经历过一次
老年代:存活时间长的老对象,经历过一次或更多次垃圾回收的对象

v9

默认情况下,V8为老年代分配的空间,大概是新生代的40多倍。
新对象都会被分配到新生代中,当新生代空间不足以分配新对象时,将触发新生代的垃圾回收。

1.3.2 新生代的垃圾回收
v10

FromTo各占一半
当新生代触发垃圾回收时,V8将From空间中所有应该存活下来的对象依次复制到To空间。

有两种情况不会将对象复制到To空间,而是晋升至老年代:
对象此前已经经历过一次新生代垃圾回收,这次依旧应该存活,则晋升至老年代。
To空间已经使用了25%,则将此对象直接晋升至老年代。

v11

From空间所有应该存活的对象都复制完成后,原本的From空间将被释放,成为闲置空间,原本To空间则成为使用中空间,两个空间进行角色翻转。
为何To空间使用超过25%时,就需要直接将对象复制到老年代呢?因为To空间完成垃圾回收后将会翻转为From空间,新的对象分配都在此处进行,如果没有足够的空闲空间,将会影响程序的新对象分配。
因为Scavenge只复制活着的对象,而根据统计学指导,新生代中大多数对象寿命都不长,长期存活对象少,则需要复制的对象相对来说很少,因此总体来说,新生代使用Scavenge算法的效率非常高。且由于Scavenge是依次连续复制,所以To空间永远不会存在内存碎片。不过由于Scavenge会将空间对半划分,所以此算法的空间利用率较低。

1.3.3 老年代的垃圾回收

在老年代中的对象,至少都已经历过一次甚至更多次垃圾回收,相对于新生代中的对象,它们有更大的概率继续存活,只有相对少数的对象面临死亡,且由于老年代的堆内存是新生代的几十倍,其中生活着大量对象,因此如果使用Scavenge算法回收老年代,将会面临大量的存活对象需要复制的情况,将老年代空间对半划分,也会浪费相当大的空间,效率低下。因此老年代垃圾回收主要采用标记清除(Mark-Sweep)和标记整理(Mark-Compact)。
这两种方式并非互相替代关系,而是配合关系,在不同情况下,选择不同方式,交替配合以提高回收效率。
新生代中死亡对象占多数,因此采用Scavenge算法只处理存活对象,提高效率。老年代中存活对象占多数,于是采用标记清除算法只处理死亡对象,提高效率。
当老年代的垃圾回收被触发时,V8会将需要存活对象打上标记,然后将没有标记的对象,也就是需要死亡的对象,全部擦除,一次标记清除式回收就完成了:

v13

灰色为存活对象,白色为清除后的闲置空间
一切看起来都完美了,可是随着程序的继续运行,却会出现一个问题:被清除的对象遍布各个内存地址,空间有大有小,其闲置空间不连续,产生了很多内存碎片。当需要将一个足够大的对象晋升至老年代时,无法找到一个足够大的连续空间安置这个对象。
为了解决这种空间碎片的问题,就出现了标记整理算法。它是在标记清除的基础上演变而来,当清理了死亡对象后,它会将所有存活对象往一端移动,使其内存空间紧挨,另一端就成为了连续内存:

v14

虽然标记整理算法可以避免空间碎片,但是却需要依次移动对象,效率比标记清除算法更低,因此大多数情况下V8会使用标记清理算法,当空间碎片不足以安放新晋升对象时,才会触发标记整理算法。

1.3.4 增量标记(Incremental Marking)

早期V8在垃圾回收阶段,采用全停顿(stop the world),也就是垃圾回收时程序运行会被暂停。这在JavaScript还仅被用于浏览器端开发时,并没有什么明显的缺点,前端开发使用的内存少,大多数时候仅触发新生代垃圾回收,速度快,卡顿几乎感觉不到。但是对于Node程序,使用内存更多,在老年代垃圾回收时,全停顿很容易带来明显的程序迟滞,标记阶段很容易就会超过100ms,因此V8引入了增量标记,将标记阶段分为若干小步骤,每个步骤控制在5ms内,每运行一段时间标记动作,就让JavaScript程序执行一会儿,如此交替,明显地提高了程序流畅性,一定程度上避免了长时间卡顿。

二、Node开发中的内存管理与优化

2.1 手动变量销毁

当任一作用域存活于作用域栈(作用域链)时,其中的变量都不会被销毁,其引用的数据也会一直被变量关联,得不到GC。有的作用域存活时间非常长(越是栈底,存活时间越长,最长的是全局作用域),但是其中的某些变量也许在某一时刻后就没有用处了,因此建议手动设置为null,断开引用链接,使得V8可以及时GC释放内存。
注意,不使用var声明的变量,都会成为全局对象的属性。前端开发中全局对象为window,Node中全局对象为global,如果global中有属性已经没有用处了,一定要设置为null,因为全局作用域只有等到程序停止运行,才会销毁。
Node中,当一个模块被引入,这个模块就会被缓存在内存中,提高下次被引用的速度。也就是说,一般情况下,整个Node程序中对同一个模块的引用,都是同一个实例(instance),这个实例一直存活在内存中。所以,如果任意模块中有变量已经不再需要,最好手动设置为null,不然会白白占用内存,成为“活着的死对象”。

2.2 慎用闭包
2.2.1 V8的闭包实现

function outer(){
    var x = 1; // 真正的局部变量:outer执行完后立即死亡
    var y = 2; // 上下文变量:闭包死亡后才会死亡
    // 返回一个闭包
    return function(){
      console.log(y); // 使用了外层函数的变量 y
    }
}
var inner = outer(); // 通过inner变量持有闭包

有不少开发者认为,如果闭包被引用,那么闭包的外部函数也不会被释放,其中的所有变量都不会被销毁,比如我通过inner变量持有了闭包,此时outer中的 x、y 均活在内存中,不会被销毁。事实真是这样吗?
答案是:在V8的实现中,当outer执行完毕,x 立即死亡,仅有 y 存活。
V8是这么做的:
当程序进入一个函数时,将会为这个函数创建一个上下文(Context),初始状态这个Context是空的,当读到这个函数(outer)中的闭包声明时,将会把此闭包(inner)中使用的外部变量,加入Context。在上面的例子中,由于inner函数使用了变量 y ,因此会将 y 加入Context。outer内部所有的闭包,都会持有这个Context。

v15

每一个闭包都会引用其外部函数的Context,以此访问需要读取的外部变量。被闭包捕捉,加入Context中的变量,我们称为Context变量,分配在堆。而真正的 局部变量(local variable)是 x ,保存在栈,当outer执行完毕后,其信息出栈,变量 x 自然销毁,而Context被闭包引用,如果有任何一个闭包存活,Context都将存活,y 将不会被销毁。

2.3 大内存使用

2.3.1 使用stream
当我们需要操作大文件,应该利用Node提供的stream以及其管道方法,防止一次性读入过多数据,占用堆空间,增大堆内存压力。
2.3.2 使用Buffer
Buffer是操作二进制数据的对象,不论是字符串还是图片,底层都是二进制数据,因此Buffer可以适用于任何类型的文件操作。
Buffer对象本身属于普通对象,保存在堆,由V8管理,但是其储存的数据,则是保存在堆外内存,是有C++申请分配的,因此不受V8管理,也不需要被V8垃圾回收,一定程度上节省了V8资源,也不必在意堆内存限制。

v19

0赞