浅谈V8垃圾回收机制

共 753字,需浏览 2分钟

 ·

2022-04-30 02:00

    


对于C/C++等底层语言,内存需要手动进行申请,使用完后手动进行释放。而对于javascript语言使用者来说,因为有垃圾回收器的工作,在使用中通常不需要关心内存的使用情况。但有时不当的代码会意外的导致变量未被垃圾回收器回收,积少成多后造成内存泄漏,潜在的提高应用卡顿的风险。本文从垃圾回收器的工作原理进行分析,总结可能造成内存泄漏的几个典型场景,避免工作中出现内存泄漏造成应用卡顿。

内存生命周期

无论哪种编程语言,内存的生命周期都是差不多的:申请内存、使用内存(读写)、释放或归还内存。

为什么需要垃圾回收

显而易见,用户设备内存是有限的,只申请不释放,内存被占满时,就无法给新创建的对象分配内存。这里类比我们去公司食堂吃饭的场景:打饭后找到空位(申请内存)、在空位吃饭(使用内存)、吃完饭收拾餐盘放回回收区(释放内存)。想象一下,我们吃完不收拾餐盘(释放内存),后来的人就没有餐桌可以吃饭了(程序崩溃)。

对于大多数学校和公司食堂,都是使用者吃完饭释放餐桌(收拾餐盘放回回收区),和C/C++等底层语言类似,使用者申请内存空间,使用完毕再释放内存。

如果我们去外边餐馆吃饭,也是同样的流程。只不过不需要自己找餐桌,由引导服务员给分配,使用后,不需要关心留在餐桌上的餐盘,由回收餐盘服务员去回收。对于JS 来说,垃圾回收器(Garbage Collector)就在做类似于餐盘服务员垃圾回收的工作:将不再使用的内存进行释放回收,从而能够循环利用有限的内存空间。

function grow() {

   var x = []

   let str = new Array(100000).join('x');
   // 1亿个
   for (let i=0; i<100000000; i++) {
      x.push(str)
   }
}

document.getElementById('grow').addEventListener('click', grow);

以上面这段代码为例,点击 grow按钮后,会向数组x中存入大量的(一亿个)字符串,然后这个tab就崩溃了。看到下图,大概率是内存超过了浏览器单 tab的内存上限。以chrome为例,其单tab内存上限在32位系统上为 512M,64位系统上为1.4GB左右。

变量存储方式

JS中变量分为原始类型和引用类型,不同的变量类型存储方式不同。我们先回顾一下 JS 是如何存储变量的。原始类型直接存储在栈(Stack)中,引用类型存储在堆(Heap)中。

var a = 1;

function doSomething() {
    let b = 2;
    let obj = { c: 3}
    console.log(a, b);
}

doSomething();

以上面的一段代码为例,全局执行上下文中存在一个值类型变量 a,doSomething 函数执行上下文中存在一个值类型变量b,一个引用类型变量obj。从下面的内存分配图可以看到,值类型直接存储在栈中,引用类型存储在堆中。

栈内存垃圾回收

栈内存回收相对来说很简单,函数执行完毕后,该函数执行上下文从栈中弹出,存储在执行上下文中的变量立即被回收掉。还是以上面的一段代码为例,当 doSomething 执行完毕后,内存结构如下图:

doSomething 执行上下文被弹出,该执行上下文中所有变量都被销毁回收。对于值类型b来说,就直接释放了其占用的内存,对于引用类型obj来说,销毁的只是变量obj对堆内存地址 1001 的引用,obj的值 { c: 3 } 依然存在于堆内存中。那么堆内存中的变量如何进行回收呢?

堆内存垃圾回收

代际假说(Generational Hypothesis)

代际假说认为,大部分新对象的生存时间比较短,在一次垃圾回收周期内被回收。

基于此,V8 将堆内存分为新生代和老生代。新生代又将内存分为 Nursery 和 Intermediate两个区域。新对象存放到Nursery区域中,经过一次垃圾回收,存活的对象被复制到 Intermediate 区域。经过两次垃圾回收仍然存活的对象将被移动到老生代中。有点像我们上学的过程,从幼儿园到小学到中学。

主垃圾回收器(Major GC)

垃圾回收器有一些基本的任务:识别活动对象(marking)、回收或重用垃圾对象内存(sweeping)、整理碎片内存(defragment)。

标记阶段(Marking)

标记阶段通过变量是否可达(reachability),判断是否为活动对象。通常为从一个根对象进行递归遍历,所有遍历到的对象都是可达的,为活动对象。没有遍历到的对象为非活动对象,需要进行回收。

var obj1 = { a: 1};
var obj2 = = { b: 2};

执行如下代码后obj2失去对 1002 的引用,在垃圾回收器遍历完之后发现没有对 1002 这块内存的引用变量,标记为其非活动变量。

obj2 = null;

清除阶段(Sweeping)

GC会维护一个 freeList 列表,将非活动对象占用的内存片段地址添加到 freeList。有新对象申请内存时,freeList里有合适大小的内存块,会优先分配给新对象。

整理阶段(Defragmenting)

这个阶段是可选的。内存在经过垃圾回收之后,活动对象将内存块分割的很零碎,这个时候会进行整理,将活动对象复制到相同连续的内存区域内。

副垃圾回收器(Minor GC)

副垃圾回收器负责新生代垃圾回收。主要有四个步骤:标记、复制、更新指针、切换角色。新生代将内存分为 from space(Nursery) 和 to space (Intermediate)。当有新对象申请内存,会分配from space 区域中的地址,to space 区域为备用区域。

标记阶段同主垃圾回收器,将可达对象标记为活动对象。

复制阶段将from space中标记的活动对象复制到 to space区域,并给活动对象做标记,此时其已经位于 intermediate中,下一次垃圾回收时如果仍为活动对象,就要被复制到老生代中。

将活动对象复制到 to space 中之后,需要更新指针引用地址,这样原引用才能保证正确的指向。

最后切换 from space 和 to space 的角色。在下一次垃圾回收周期后,存活两次的对象会被复制到老生代区域。

GC执行时机

在最初,GC运行在主线程,与 JS交替执行。在GC执行阶段,主线程停止JS代码执行,这称为全停顿(Stop-the-World)。如果垃圾回收器需要处理(标记-复制-整理)的对象比较多,就需要比较长的时间才能完成一次周期内的任务。在这期间如果有更高优的任务需要执行,是无法及时响应的,比如用户输入、动画的执行,给用户的感觉就是卡顿。

提高GC执行效率

Goal: Free Main Thread

Orinoco是 Google 垃圾回收器(Garbage Collector)的项目代号,致力于研究如何提高垃圾回收效率。经过多年的发展,产出了三种能有效提高垃圾回收效率的方案:并行(Parallel)、增量标记(Incremental)、并发(Concurrent)。

并行(Parallel)

在主线程执行垃圾回收任务的同时,开几个辅助线程同时进行,这样可以大大减少主线程全停顿(Stop the World)的时间。

增量(increment)

将主线程垃圾回收任务分成多个小任务,与JS交替执行。这种方式并没有缩短GC工作的时间,但是给了JS响应高优任务的时间,避免了出现卡顿。

并发(concurrent)

并发是主线程专注执行JS, 开启辅助线程进行垃圾回收。这种方式没有了全停顿,完全解放主线程,实现了 Free Main Thread 的目标。

几个典型场景

通过了解V8垃圾回收机制,我们知道垃圾回收器会和JS线程争夺资源和时间。V8也在不断通过更先进的技术来减少全停顿(Stop the World)的时间。对于我们开发者来说,能做的就是尽量减少GC的工作负担。总结来说就是,变量不用之后立即释放。下面我们总结了几种容易造成内存泄漏的bad case,大家在工作中可以规避。

减少全局变量

下面这段代码,函数作用域中变量未使用关键字声明,导致非严格模式下挂载到全局作用域。这样foo()函数执行完毕之后,由于 window.bar的引用一直存在,导致被GC识别为活动对象。这样只要程序在运行,该对象的内存就会一直存在无法被回收,增加垃圾回收器的工作负担。

// 非严格模式下,bar会被挂在全局上
function foo(arg) {
    bar = { a: 1 };
    this.obj = { b: 1};
    console.log(bar, obj);
}

foo();

对于这种情况建议开启严格模式,或者使用 lint工具检查这种错误。

及时清理对DOM的引用

有了React和Vue这种UI库,我们就很少直接操作DOM了。在我们业务中,需要对富文本内的一些内容进行操作中,有很多直接操作DOM的场景。在操作完DOM之后,需及时清掉对DOM节点的引用,不然也会造成对内存的泄露。


  type="text" id="input">
  "node">


  

事件监听&计时器

在我们业务中经常需要在组件挂载后给元素添加事件监听。这时需要在组件卸载时将监听事件移除,来避免无用的内存消耗。

componentDidMount() {
    this.myScaleBar?.addEventListener('mousedown', this.handleMouseDown);
    document.addEventListener('mousemove', this.handleMouseMove);
    document.addEventListener('mouseup', this.handleMouseUp);
}

componentDidMount() {
    this.myScaleBar?.addEventListener('mousedown', this.handleMouseDown);
    document.addEventListener('mousemove', this.handleMouseMove);
    document.addEventListener('mouseup', this.handleMouseUp);
}

如何查看是否存在内存泄漏

chrome devtools 中的 performance 面板可以记录内存使用的timeLine, 在录制之前选中内存,报告中会有内存的使用情况。我们主要关注JS堆中内存的使用情况。

我们以下面这段代码为例,通过点击grow按钮,会向grow 函数内的变量x 内添加大量的长度为100000的字符串。


"en">

   内存测试


   

      "grow">grow
   


   


记录开始后先点击【强制垃圾回收】,然后点击grow,记录一段时间后再点击【强制垃圾回收】后查看报告。可以看到第二次垃圾回收与操作之前的内存相等,说明没有垃圾泄漏。

我们再稍微改一下代码,看一下内存的使用情况。

function grow() {
  x = [];

  let str = new Array(100000).join('x');

  for (let i=0; i<100000000; i++) {
    x.push(str)
  }
}

记录发现强制垃圾回收之后,内存的占用要高于grow函数执行之前。与上面第一次记录的区别是,grow内变量 x 的声明没有使用关键字声明,非严格模式下直接挂载到window上。这样grow函数执行完毕,全局对 x依然 的引用,GC无法回收 x 占用的内存。

总结

V8垃圾回收器帮助JS使用者周期性的回收不再使用的内存。过多的对象会对垃圾回收器造成额外的负担,甚至影响到主线程JS的执行,造成页面的卡顿。作为开发者应该有意识的减少全局变量的数量、及时移除不再使用DOM引用、事件监听及计时器,来减少垃圾回收器的负担。

参考资料

[1]

Trash talk: the Orinoco garbage collector · V8: https://v8.dev/blog/trash-talk

[2]

代际假说: https://www.memorymanagement.org/glossary/g.html#term-generational-hypothesis

[3]

代际垃圾回收器: https://www.memorymanagement.org/glossary/g.html#term-generational-garbage-collection

❤️ 谢谢支持

以上便是本次分享的全部内容,希望对你有所帮助^_^

喜欢的话别忘了 分享、点赞、收藏 三连哦~。

欢迎关注公众号 趣谈前端 收货大厂一手好文章~

❤️ H5-Dooring,让H5制作更简单


目前H5-Dooring架构升级, 已支持多种搭建布局模式, 如网格布局, 自由布局, 可以一键切换布局模式:



欢迎体验: http://h5.dooring.cn/h5_plus

❤️ 

便^_^

  ~

号 趣谈前端 获前端~

浏览 30
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报