浏览器工作原理(13) -垃圾回收，垃圾数据是如何自动回收的？

最新推荐文章于 2023-04-19 13:20:19 发布

xxz15152

最新推荐文章于 2023-04-19 13:20:19 发布

阅读量376

点赞数 2

文章标签： javascript chrome

本文链接：https://blog.csdn.net/u013448372/article/details/108189659

版权

上一篇文章中我们了解了JavaScript中数据是如何存储的，并通过实际例子分析了原始数据类型是存储在栈空间中的，引用类型的数据是存储在堆空间中的，通过这种分配方式，我们解决了数据的内存分配的问题。

但是实际的执行过程中，有些数据被使用之后，可能就不需要了，我们称这些数据为垃圾数据，如果垃圾数据不进行及时清理，那么内存会越用越多，这时就需要一个垃圾回收机制，来回收垃圾释放内存

不同语言的垃圾回收机制

垃圾数据回收分为 手动回收 和 自动回收 两种策略

C/C++语言的垃圾回收是手动来执行的(使用free函数)

而JavaScript、java、python等语言是自动释放内存，属于自动垃圾回收，由 垃圾回收器来释放，不需要手动来释放

由于JavaScript中的数据是存放在堆或者栈中，那么接下来分别看一下它们产生的垃圾是如何被回收的

调用栈中的数据是如何回收的

看下面的代码：

function foo(){
    var a = 1
    var b = {name:"极客邦"}
    function showName(){
      var c = 2
      var d = {name:"极客时间"}
    }
    showName()
}
foo()

当代码执行到为d赋值时，此时的调用栈关系如下图
在这里插入图片描述从图中可以看出，原始类型的数据被分配到栈中，引用类型的数据会被分配到堆中。当 foo 函数执行结束之后，foo 函数的执行上下文会从堆中被销毁掉，那么它是怎么被销毁的呢？下面我们就来分析一下。

上面代码执行到showName的时候，调用栈关系如上图所示，如此同时还有一个记录当前执行状态的指针(ESP), 用来指向调用栈中showName函数的执行上下文，表明正在执行showName函数

当 showName 函数执行完成之后，函数执行流程就进入了 foo 函数，那这时就需要销毁 showName 函数的执行上下文了。ESP 这时候就帮上忙了，JavaScript 会将 ESP 下移到 foo 函数的执行上下文，这个下移操作就是销毁 showName 函数执行上下文的过程。

ESP下移是如何销毁showName的执行上下文呢？接着看下面一张图：

在这里插入图片描述当 showName 函数执行结束之后，ESP 向下移动到 foo 函数的执行上下文中，上面 showName 的执行上下文虽然保存在栈内存中，但是已经是无效内存了。比如当 foo 函数再次调用另外一个函数时，这块内容会被直接覆盖掉，用来存放另外一个函数的执行上下文。

结论： 当一个函数执行结束后，JavaScript引擎会通过向下移动ESP来销毁该函数保存在栈中的执行上下文

堆中的数据是如何回收的

通过上面的讲解，我们已经知道，当上面那段代码的 foo 函数执行结束之后，ESP 应该是指向全局执行上下文的，那这样的话，showName 函数和 foo 函数的执行上下文就处于无效状态了，不过保存在堆中的两个对象依然占用着空间，如下图所示
在这里插入图片描述
从图中可以看出，1003 和 1050 这两块内存依然被占用。要回收堆中的垃圾数据，就需要用到 JavaScript 中的垃圾回收器了。

接下来通过chrome的JavaScript引擎V8来分析一下堆空间的数据是如何回收的？

代际假说和分代收集

代际假说：The Generational Hypothesis , 垃圾回收领域一个重要的术语，v8引擎的回收机制是建立在这个假说的基础之上

两个特点：

大部分对象在内存中存在的时间很短，也就是说对象一经分配内存，很快就变得不可访问
不死的对象，活得很久

这两个特点实用于大多数动态语言，基于这两个特点，一起来分析一下堆空间的回收机制

垃圾回收由很多种算法，不同的算法特点不同，具体场景具体分析

V8会把堆分为 新生代 和 老生代 两个区域， 新生代存放生存时间短的对象，老生代存放生存时间久的对象

新生区大约1~8M的空间，而老生代比较大，这两块区域使用两个不同的垃圾回收器

副垃圾回收器，主要负责新生代的垃圾回收
主垃圾回收器，主要负责老生代的垃圾回收

垃圾回收器的工作流程

不论什么样的垃圾回收器，都有一套共同的执行流程，下面分几步来说明这个流程：

标记空间中活动对象和非活动对象，活动对象是指还在使用的对象，非活动对象是指可以进行回收的对象
回收非活动对象所占的内存，也就是在标记之后，统一清理内存中的所有被标记为非活动对象
内存整理，多次回收之后，内存会有很多不连续空间，也称为内存碎片，如果内存中存在多个碎片，而此时又需要一个大的连续内存时，就会出现内存不足的情况，所以有必要进行内存碎片整理

副垃圾回收器

副垃圾回收器主要负责新生代的区域，大多数小的对象都会被分到新生代内存，所以虽然这个区域较小，但是会比较频繁

新生代中用 Scavenge算法 来处理，也就是把新生代空间划分为两个区域，一半是对象区域，一半是空闲区域

在这里插入图片描述新加入的对象会先放在对象区域，当对象区域快写满时，就需要执行一次垃圾清理操作。

垃圾回收过程中，首先对对象区域的垃圾做标记，标记完成之后，进入垃圾清理阶段，副垃圾回收器把这些存活的对象复制到空闲区，并且会做排序，这个过程也相当于顺便做了内存整理

复制完成之后呢，对象区域就会跟空闲区域做一个角色互换，这样就完成了内存清理的过程，这个过程会一直持续下去，每次清理都需要时间来复制存活的对象，为了执行效率，所以这个 新生区不能太大

由于新生区不会太大，很容易出现写满的情况，那么怎么办呢？这个时候就会执行另一条原则: 两次回收之后依然存活的对象，会被移动到老生区

主垃圾回收器

主垃圾回收器负责老生区的回收工作，老生区的对象由两个特点：对象比较大，存活时间长

由于对象比较大，比较多，那么再使用 Scavenge 算法会很慢，所以主垃圾回收器采用 Mark-Sweep 算法

Mark-Sweep垃圾回收的过程：

首先标记，从一组根元素开始，递归遍历这组根元素，在这个遍历过程中，能达到的元素称为 活动对象，没有达到的元素称为 垃圾数据，参考之前的代码，当showName函数执行结束之后，这段代码的调用栈和堆空间如下：

在这里插入图片描述从上图你可以大致看到垃圾数据的标记过程，当 showName 函数执行结束之后，ESP 向下移动，指向了 foo 函数的执行上下文，这时候如果遍历调用栈，是不会找到引用 1003 地址的变量，也就意味着 1003 这块数据为垃圾数据，被标记为红色。由于 1050 这块数据被变量 b 引用了，所以这块数据会被标记为活动对象。这就是大致的标记过程。

接下来就是垃圾的清除过程。它和副垃圾回收器的垃圾清除过程完全不同，你可以理解这个过程是清除掉红色标记数据的过程，可参考下图大致理解下其清除过程

在这里插入图片描述上面的标记过程和清除过程就是标记 - 清除算法，不过对一块内存多次执行标记 - 清除算法后，会产生大量不连续的内存碎片。而碎片过多会导致大对象无法分配到足够的连续内存，于是又产生了另外一种算法——标记 - 整理（Mark-Compact），这个标记过程仍然与标记 - 清除算法里的是一样的，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。你可以参考下图

在这里插入图片描述

全停顿

现在我们知道了 V8 是使用副垃圾回收器和主垃圾回收器处理垃圾回收的，不过由于 JavaScript 是运行在主线程之上的，一旦执行垃圾回收算法，都需要将正在执行的 JavaScript 脚本暂停下来，待垃圾回收完毕后再恢复脚本执行。我们把这种行为叫做全停顿（Stop-The-World）。

由于垃圾回收而引起JavaScript线程暂停，那么性能会下降，主垃圾回收器执行一次垃圾回收的完整过程如下：

在这里插入图片描述
在 V8 新生代的垃圾回收中，因其空间较小，且存活对象较少，所以全停顿的影响不大，但老生代就不一样了。如果在执行垃圾回收的过程中，占用主线程时间过久，就像上面图片展示的那样，花费了 200 毫秒，在这 200 毫秒内，主线程是不能做其他事情的。比如页面正在执行一个 JavaScript 动画，因为垃圾回收器在工作，就会导致这个动画在这 200 毫秒内无法执行的，这将会造成页面的卡顿现象。