V8 虚拟机的GC机制

V8简介

V8是Chrome浏览器的javascript解释器，在第三次浏览器大战中，Chrome凭借优秀的V8引擎胜出。目前该JavaScript引擎已用于其它项目的开发。第一个版本随着第一个版本的Chrome于2008年9月2日发布。

如此强大的js解释器，却存在着隐患的内存溢出问题，这是因为v8 引擎初始状态下，64位机器只被分配了1.4G的内存，32位机器只被分配了0.7G的内存，就算你有再大的内存，也会被浪费掉得不到合理的使用，那么为什么V8会只被分配了这极少的内存呢。

这是因为开发这个js虚拟机的初衷在于客户端，也就是浏览器方向，这1.4G在客户端那是绰绰有余。但在后端Node 上，可就不显得很多了，在高并发的情形下，很有可能导致内存溢出，使Node的异步高并发性能不能足以得到发挥。

因此我们很有必要去了解V8内在的GC机制。以便发挥它最大的性能。

浅谈GC

每当我们声明一个对象，V8就会在堆内开辟一块内存用来存储这个对象，各种GC算法向来不是写一次就能适用于各种情形，各个对象的生存周期长短不一，于是把在堆上的各个对象划分为新生代和老生代。因此，V8上的堆看上去大概是这样的。

认识GC算法

scavenge算法

有一种算法称之为cheney算法，这种算法的核心是将堆划分为两部分，称之为semispace。

两个semispace用于进行复制清除两项操作，把其中一个活动的semispace称之为from semispace,另一个称之为to semispace,在进行GC时，会遍历from semispace中的对象，然后把存活的对象复制到to semispace中，然后清空from semispace， 最后把from 和 to调换。

这种算法在V8中又被称之为scavenge算法，这种算法很明显的特点是，牺牲空间来提高运行效率，因此它的优点是执行时间短，而空间利用效率不高，比较适用于体积普遍较小，生存周期不长的新生代。

而我们执行scavenge算法的时候，需要复制对象时，如果对象经历了多次复制，即生存周期长，V8会把它移动到老生代来，或者如果To semispace 的空间占用比超过了25% ,则也会把它移动到老生代，这是因为，之后的操作会清空from semispace 并把to semispace当作from semispace来对待，因此，占用比过高不利于后续的对象内存分配。而我们把对象从新生代移动到老生代的这个过程叫做晋升。

mark-sweep 算法

这是一种很普遍的算法，JVM也采用了这种算法。所谓mark-sweep 即标记-清除算法，从字面意思不难看出，该算法是遍历当前堆内的所有对象，然后把死亡的对象进行标记，然后进行一次清理。这样做的坏处在于，遍历整个堆是很耗费时间的，相对于scavenge算法而言，scavenge算法只遍历了半个堆，相对而言时间消耗较短，而mark-sweep算法则是遍历整个堆，相对而言时间消耗较长。除此之外，还有个缺点是那些被清除的对象使得原本完整的堆变成了破碎的堆碎片。如图所示经过一次mark-sweep清理的堆。

在图中，深色部分为清理后留下的空洞，这样的可怕之处在于，下一次为一个大对象分配空间时，由于堆碎片的不连续，无法分配给这个大对象空间，因此会提前触发GC，而这次GC是不必要的。
而为了弥补这种算法所再来的问题，mark-compact 算法被提出，它的作用主要在于将存活的对象向一个方向移动，把不连续的堆碎片变完整。

深色部分为GC留下的内存空洞，下一步我们只需把右边的给清除掉即可。

总体看来mark-sweep算法需要配合mark-compact算法才能很好的进行GC，整个过程花费的时间较scavenge算法来说较长，但空间利用率却比scavenge大，因此这种算法更适用于不需要频繁GC的老年代。

为了确保js的正常执行，gc和js执行不能并行执行，因此选择了类似于共享CPU时间片的执行方式，将gc 和js交替执行。