本文共 5688 字,大约阅读时间需要 18 分钟。
转载:http://www.jianshu.com/p/4129a3fce7bb
使用JavaScript进行前端开发时几乎完全不需要关心内存管理问题,对于前端编程来说,V8限制的内存几乎不会出现用完的情况,但是由于后端程序往往进行的操作更加复杂,并且长期运行在服务器不重启,如果不关注内存管理,导致内存泄漏,就算1TB,也会很快用尽。
Node.js构建于V8引擎之上,因此本文首先讲解V8引擎的内存管理机制,了解底层原理后,再讲解Node开发中的内存管理与优化。Node程序运行中,此进程占用的所有内存称为常驻内存(Resident Set)。
除堆外内存,其余部分均由V8管理。
通过process.memoryUsage()
可以查看此Node进程的内存使用状况:
rss
是Resident Set Size的缩写,为常驻内存的总大小,heapTotal
是V8为堆分配的总大小,heapUsed
是已使用的堆大小。可以看到,rss是大于heapTotal的,因为rss包括且不限于堆。 默认情况下,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.1 V8的内存分代
1.3.2 新生代的垃圾回收
新生代中的对象主要通过Scavenge算法进行垃圾回收,这是一种采用复制的方式实现内存回收的算法。 Scavenge算法将新生代的总空间一分为二,只使用其中一个,另一个处于闲置,等待垃圾回收时使用。使用中的那块空间称为From,闲置的空间称为To。1.3.3 老年代的垃圾回收
在老年代中的对象,至少都已经历过一次甚至更多次垃圾回收,相对于新生代中的对象,它们有更大的概率继续存活,只有相对少数的对象面临死亡,且由于老年代的堆内存是新生代的几十倍,其中生活着大量对象,因此如果使用Scavenge算法回收老年代,将会面临大量的存活对象需要复制的情况,将老年代空间对半划分,也会浪费相当大的空间,效率低下。因此老年代垃圾回收主要采用标记清除(Mark-Sweep)和标记整理(Mark-Compact)。 这两种方式并非互相替代关系,而是配合关系,在不同情况下,选择不同方式,交替配合以提高回收效率。 新生代中死亡对象占多数,因此采用Scavenge算法只处理存活对象,提高效率。老年代中存活对象占多数,于是采用标记清除算法只处理死亡对象,提高效率。 当老年代的垃圾回收被触发时,V8会将需要存活对象打上标记,然后将没有标记的对象,也就是需要死亡的对象,全部擦除,一次标记清除式回收就完成了:1.3.4 增量标记(Incremental Marking)
早期V8在垃圾回收阶段,采用全停顿(stop the world),也就是垃圾回收时程序运行会被暂停。这在JavaScript还仅被用于浏览器端开发时,并没有什么明显的缺点,前端开发使用的内存少,大多数时候仅触发新生代垃圾回收,速度快,卡顿几乎感觉不到。但是对于Node程序,使用内存更多,在老年代垃圾回收时,全停顿很容易带来明显的程序迟滞,标记阶段很容易就会超过100ms,因此V8引入了增量标记,将标记阶段分为若干小步骤,每个步骤控制在5ms内,每运行一段时间标记动作,就让JavaScript程序执行一会儿,如此交替,明显地提高了程序流畅性,一定程度上避免了长时间卡顿。当任一作用域存活于作用域栈(作用域链)时,其中的变量都不会被销毁,其引用的数据也会一直被变量关联,得不到GC。有的作用域存活时间非常长(越是栈底,存活时间越长,最长的是全局作用域),但是其中的某些变量也许在某一时刻后就没有用处了,因此建议手动设置为null,断开引用链接,使得V8可以及时GC释放内存。
注意,不使用var声明的变量,都会成为全局对象的属性。前端开发中全局对象为window,Node中全局对象为global,如果global中有属性已经没有用处了,一定要设置为null,因为全局作用域只有等到程序停止运行,才会销毁。 Node中,当一个模块被引入,这个模块就会被缓存在内存中,提高下次被引用的速度。也就是说,一般情况下,整个Node程序中对同一个模块的引用,都是同一个实例(instance),这个实例一直存活在内存中。所以,如果任意模块中有变量已经不再需要,最好手动设置为null,不然会白白占用内存,成为“活着的死对象”。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。function outer () { var x; // 真正的局部变量 var y; // context variable, 被inner1使用 var z; // context variable, 被inner2使用 function inner1 () { use(y); } function inner2 () { use(z); } function inner3 () { /* 虽然函数体为空,但是作为闭包,依旧引用outer的Context */ } return [inner1, inner2, inner3];}
x、y、z 三个变量何时死亡?
x 在outer执行完后立即死亡, y、z 需要等到inner1、inner2、inner3三个闭包都死亡后,才会死亡。 x 未被任何闭包使用,因此是一个真正的局部变量,保存在栈,函数执行完即被出栈死亡。由于 y、z 两个变量分别被inner1、inner2使用,则它们会被加入outer的Context。所有闭包都会引用外部函数的Context,即使inner3为空,不使用任何外部函数的变量,也会引用Context,所以需要等到三个闭包都死亡后,y、z 才会死亡。2.2.2 避免深层闭包嵌套
function outer() { var x = HUGE; // 超大对象 function inner() { var y = GIANT; // 大对象 use(x); // x 需要使用,需要成为Context变量 function innerF() { use(y); // y 需要使用,需要成为Context变量 } function innerG() { /* 空函数体 */ } return innerG; } return inner();}var o = outer(); // HUGE and GIANT 均得不到释放
变量 o 持有的是innerG闭包,innerG持有着inner的Context,且内部闭包的Context会持有外部闭包的Context,产生Context链。
2.3.1 使用stream
当我们需要操作大文件,应该利用Node提供的stream以及其管道方法,防止一次性读入过多数据,占用堆空间,增大堆内存压力。2.3.2 使用Buffer
Buffer是操作二进制数据的对象,不论是字符串还是图片,底层都是二进制数据,因此Buffer可以适用于任何类型的文件操作。 Buffer对象本身属于普通对象,保存在堆,由V8管理,但是其储存的数据,则是保存在堆外内存,是有C++申请分配的,因此不受V8管理,也不需要被V8垃圾回收,一定程度上节省了V8资源,也不必在意堆内存限制。