Q1:null和undefined的区别

简单区分

总的来说 null 和 undefined 都代表空，主要区别在于 undefined 表示尚未初始化的变量的值，而 null 表示该变量有意缺少对象指向。

undefined
- 这个变量从根本上就没有定义
- 隐藏式空值
null
- 这个值虽然定义了，但它并未指向任何内存中的对象
- 声明式空值

MDN 中给出的定义

null

值 null 是一个字面量，不像 undefined ，它不是全局对象的一个属性。null 是表示缺少的标识，指示变量未指向任何对象。把 null 作为尚未创建的对象，也许更好理解。在 API 中，null 常在返回类型应是一个对象，但没有关联的值的地方使用。

undefined

undefined 是 全局对象 的一个属性。也就是说，它是全局作用域的一个变量。 undefined 的最初值就是原始数据类型 undefined 。

表现形式

在更深入理解 null 和 undefined 的区别前，我们首先要知道 null 和 undefined 在 JS 中有什么不同的表现形式，用以方便我们更好的理解 null 和 undefined 的区别。

typeof

typeof null  // 'object'
typeof undefined  // 'undefined'

Object.prototype.toString.call

Object.prototype.toString.call(null)       // '[object Null]'
Object.prototype.toString.call(undefined)  // '[object Undefined]'

== 与 ===

null == undefined  // true
null === undefined  // false
!!null === !!undefined  // true

Object.getPrototypeOf(Object.prototype)

JavaScript 中第一个对象的原型指向 null 。

Object.getPrototypeOf(Object.prototype)  // null

+ 运算与 Number()

let a = undefined + 1  // NaN
let b = null + 1  // 1
Number(undefined)  // NaN
Number(null)  // 0

JSON

JSON.stringify({a: undefined})  // '{}'
JSON.stringify({b: null})  // '{b: null}'
JSON.stringify({a: undefined, b: null})  // '{b: null}'

let undefiend = 'test'

function test(n) {
    let undefined = 'test'
    return n === undefined
}

test()           // false
test(undefined)  // false
test('test')     // ture

let undefined = 'test'  // Uncaught SyntaxError: Identifier 'undefined' has already been declared

深入探索

为什么 typeof null 是 object？

typeof null 输出为 'object' 其实是一个底层的错误，但直到现阶段都无法被修复。

原因是，在 JavaScript 初始版本中，值以 32位 存储。前 3位 表示数据类型的标记，其余位则是值。
对于所有的对象，它的前 3位 都以 000 作为类型标记位。在 JavaScript 早期版本中， null 被认为是一个特殊的值，用来对应 C 中的 空指针 。但 JavaScript 中没有 C 中的指针，所以 null 意味着什么都没有或者 void 并以 全0(32个) 表示。

因此每当 JavaScript 读取 null 时，它前端的 3位 将它视为 对象类型 ，这也是为什么 typeof null 返回 'object' 的原因。

为什么 Object.prototype.toString.call(null) 输出 '[object Null]'

toString() 是 Object 的原型方法，调用该方法，默认返回当前对象的 [[Class]] 。这是一个内部属性，其格式为 [object Xxx] ，其中 Xxx 就是对象的类型。

JavaScript 万物皆对象，为什么 xxx.toString() 不能返回变量类型？

这是因为各个类中重写了 toString 的方法，因此需要调用 Object 中的 toString 方法，必须使用 toString.call() 的方式调用。
对于 Object 对象，直接调用 toString() 就能返回 '[object Object]' 。而对于其他对象，则需要通过 call / apply 来调用才能返回正确的类型信息。

为什么 == 和 === 对比会出现 true 和 false ？

很多文章说： undefined 的布尔值是 false ， null 的布尔值也是 false ，所以它们在比较时都转化为了 false ，所以 undefined == null 。
实际上并不是这样的。
ECMA 在 11.9.3 章节中明确告诉我们：

If x is null and y is undefined, return true.

If x is undefined and y is null, return true.

这是 JavaScript 底层的内容了，至于更深入的内容，如果有兴趣可以扒一扒 JavaScript 的源码。
至于 == 和 === 的区别，后续我会在其他文章中详细说明。 敬请期待！

为什么 `null + 1` 和 `undefined + 1` 表现不同？

这涉及到 JavaScript 中的隐式类型转换，在执行 加法运算 前，隐士类型转换会尝试将表达式中的变量转换为 number 类型。如： '1' + 1 会得到结果 11。

null 转化为 number 时，会转换成 0
undefined 转换为 number 时，会转换为 NaN

至于为什么执行如此的转换方式，我猜测是 JavaScript 早期的一个糟糕设计。

从语言学的角度来看：
null 意味着一个明确的没有指向的空值，而 undefined 则意味着一个未知的值。
在某种程度上， 0 意味着数字空值。
这虽然看起来有些牵强，但是我在这一阶段能所最能想到的可能了。

为什么 JSON.stringify 会将值为 undefined 的内容删除？

其实这条没有很好的解释方式， JSON 会将 undefined 对应的 key 删除，这是 JSON 自身的转换原则。

在 undefined 的情况下，有无该条数据是没有区别的，因为他们在表现形式上并无不同：

let obj1 = { a: undefined }
let obj2 = {}

console.log(obj1.a)  // undefined
console.log(obj2.a)  // undefined

但需要注意的是，你可能在调用接口时，需要对 JSON 格式的数据中的 undefied 进行特殊处理。

为什么 let undefiend = 'test' 可以覆盖掉 JavaScript 自身的 undefined？

JavaScript 对于 undefined 的限制方式为全局创建了一个只读的 undefined ，但是并没有彻底禁止局部 undefined 变量的定义。

据说在 JavaScript 高版本禁止了该操作，但我没有准确的依据。

请在任何时候，都不要进行 undefined 变量的覆盖，就算是你的 JSON 转换将 undefined 转换为 '' 。也不要通过该操作进行，这将是及其危险的行为。

总结

关于使用 undefined 还是 null

这是一条公说公有理婆说婆有理的争议内容。
本人更倾向于使用 null ，因为这是显示定义空值的方式。我并不能给出准确的理由。

但关于使用 undefined 我有一条建议：
如果你需要使用 undefined 定义空值，请不要采取以下两种方式：

let a;
let a = undefined;

进而采取下面这种方式显式声明 undefined ：

let a = void 0;

Q2、什么是变量提升，什么是函数提升，它们的顺序

执行上下文是什么？

在运行JavaScript代码时，执行环境非常重要，并可以认为是以下其中之一：

全局代码 - 默认环境，你的代码第一时间在这里执行。
函数代码 - 当执行流进入函数体的时候。
Eval代码 - eval函数内部的文本。【eval不建议使用】

你可以在网上查到大量的关于scope（作用域）的资料，本文的目的就是要让事情更加容易理解。我们把术语执行上下文视为当前代码的评估环境/范围。现在，条件充足，我们看个包含全局和函数/本地上下文评估代码的示例。

这里没什么特别的，我们有1个由紫色边框表示的全局上下文和由绿色、蓝色和橙色边框表示的3个不同的函数上下文。只有1个全局上下文，我们可以从程序的任何其它上下文访问。

你可以拥有任意数量的函数上下文，并且每个函数调用都会创建一个新的上下文，从而创建一个私有的作用域，无法从当前函数作用域外直接访问函数内部声明的任何内容。在上面的例子中，函数可以访问在其当前上下文之外声明的变量，但是外部上下文无法访问（函数）其中声明的变量/函数。为什么会这样？这段代码究竟是如何评估的？

环境栈

浏览器中的JavaScript解释器是单线程实现的。这意味着在浏览器中一次只能发生一件事情，其它动作或事件在所谓的执行栈中排队。下图是单线程栈的抽象视图：

我们知道，当浏览器首次加载脚本时，它默认进入全局执行上下文。如果在全局代码中调用一个函数，程序的顺序流就进入被调用的函数，创建一个新的执行上下文并将该上下文推送到执行栈的顶部。

如果你在当前函数中调用另外一个函数，则会发生同样的事情。代码的执行流程进入函数内部，该函数创建一个新的执行上下文，该上下文被推送到现有栈的顶部。浏览器将始终执行位于栈顶部的当前执行上下文，并且一旦函数完成当前执行上下文，它将从栈顶弹出，将控制权返回当前栈的栈顶上下文。下面的例子展示了递归函数和其程序的执行栈：

(function foo(i) {
    if (i === 3) {
        return;
    }
    else {
        foo(++i);
    }
}(0));

上面代码只调用自身3次，将i的值递增1。每次调用函数foo时，都会创建一个新的执行上下文。一旦上下文执行完毕，它就会弹出栈并且将控制权返回它下面的上下文，直到再次到达全局上下文。

关于执行栈有五个关键点：

单线程
同步执行
1个全局上下文
无限的函数上下文
每个函数调用都会创建一个新的执行上下文，甚至是调用自身

执行上下文的细节

所以，我们现在知道每次调用一个函数时，都会创建一个新的执行上下文。但是，在JavaScript的解释器中，执行上下文的调用都有两个阶段：

创建阶段【调用函数时，但是在执行里面的代码之前】:

创建作用域链
创建变量，函数和参数
确定this的值

激活/代码执行阶段:

分配值，引用函数和解析/执行代码

可以将每个执行上下文在概念上标示为具有3个属性的对象：

executionContextObj = {
    'scopeChain': { /* variableObject + all parent execution context's variableObject */ },
    'variableObject': { /* function arguments / parameters, inner variable and function declarations */ },
    'this': {}
}

活动/变量对象【AO/VO】

调用函数时，但在执行实际函数之前，会创建此executionContextObj。这被称为阶段1，即创建阶段。这里，解释器通过扫描传入的参数或参数的函数、本地函数声明和局部函数声明来创建executionContextObj。此扫描的结果将称为executionContextObj中的variableObject。

以下是解释器如何评估代码的伪概述：

找些代码来调用一个函数
在执行函数代码之前，创建执行上下文。
进入创建阶段

初始化作用域链
创建变量对象：
- 创建arguments对象，检查参数的上下文，初始化名称和值并创建引用的副本。
- 扫描上下文以获取函数声明：
  - 对于找到的每个函数，在变量对象（或活动对象）中创建一个属性，该属性是确切的函数名称，该函数具有指向内存中函数的引用指针。
  - 如果函数名已存在，则将覆盖引用指针值。
- 扫面上下文以获取变量声明：
  - 对于找到的每个变量声明，在变量对象（或活动对象）中创建一个属性，该属性是变量名称，并将值初始化为undefined。
  - 如果变量名称已存在于变量对象（或活动对象）中，则不执行任何操作并继续扫描（即跳过）。
- 确定上下文中的this。

激活/代码执行阶段:

在上下文中运行/解释功能代码，并在代码逐行执行时分配变量值。

看下下面的例子：

function foo(i) {
    var a = 'hello';
    var b = function privateB() {

    };
    function c() {

    }
}

foo(22);

调用foo(22)，创建阶段如下：

fooExecutionContext = {
    scopeChain: { ... },
    variableObject: {
        arguments: {
            0: 22,
            length: 1
        },
        i: 22,
        c: pointer to function c()
        a: undefined,
        b: undefined
    },
    this: { ... }
}

正如你所见，创建阶段处理定义属性的名称，而不是为它们赋值，但正式参数/参数除外。创建阶段完成后，执行流程进入函数，激活/代码执行阶段在函数执行完毕后如下所示：

fooExecutionContext = {
    scopeChain: { ... },
    variableObject: {
        arguments: {
            0: 22,
            length: 1
        },
        i: 22,
        c: pointer to function c()
        a: 'hello',
        b: pointer to function privateB()
    },
    this: { ... }
}

“提升”一词

你可以在网上找到很多定义JavaScript术语-提升的资源,解释变量和函数声明是否被提升到其功能范围的顶部。但是，没有人详细解释为什么会发生这种情况，在掌握了关于解释器如何创建活动对象的新知识点，就很容易理解为什么了。看下下面的代码例子：

(function() {

    console.log(typeof foo); // function pointer
    console.log(typeof bar); // undefined

    var foo = 'hello',
        bar = function() {
            return 'world';
        };

    function foo() {
        return 'hello';
    }

}());

我们现在可以回答下面这些问题了：

为什么我们可以在声明foo前访问它？
- 如果我们遵循创建阶段，我们就知道在激活/代码执行阶段之前就已经创建了变量。因此，当函数开始执行时，已经在活动对象中定义了foo。
Foo被声明了两次，为什么foo显示为函数而不是undefined或string呢？
- 即使foo被声明了两次，我们从创建阶段中就知道到达变量之前在活动对象上已经创建了函数，并且如果活动对象上已经存在属性名称，我们就会绕过了声明。
- 因此，首先在活动对象上创建函数foo()的引用，并且当解释器到达var foo时，我们已经看到名称foo存在，因此代码什么都不做并且继续。
为什么bar是undefined？
- bar实际上是一个具有函数赋值的变量，我们知道变量是在创建阶段创建的，但它们是使用undefined值初始化的。

Q3、js函数调用是参数传递是值传递还是引用传递

对于基本类型，是值传递
对于引用类型，是传递的地址

var a = {name: 'xuxi'}; 
function b(a){ 
    a.age = 12; 
    a = {num: 1};
    return a 
    } 
var a1 = b(a);
console.log(a, a1)
//{name: 'xuxi', age: 12} {num: 1}

这一题就很好解释了引用数据类型传递的是地址

Q4、typeof和instanceof的原理

typeof 实现原理

typeof 一般被用于判断一个变量的类型，我们可以利用 typeof 来判断number, string, object, boolean, function, undefined, symbol 这七种类型，这种判断能帮助我们搞定一些问题，比如在判断不是 object 类型的数据的时候，typeof能比较清楚的告诉我们具体是哪一类的类型。但是，很遗憾的一点是，typeof 在判断一个 object的数据的时候只能告诉我们这个数据是 object, 而不能细致的具体到是哪一种 object, 比如👉

let s = new String('abc');
typeof s === 'object'// true
s instanceof String // true

要想判断一个数据具体是哪一种 object 的时候，我们需要利用 instanceof 这个操作符来判断，这个我们后面会说到。

来谈谈关于 typeof 的原理吧，我们可以先想一个很有意思的问题，js 在底层是怎么存储数据的类型信息呢？或者说，一个 js 的变量，在它的底层实现中，它的类型信息是怎么实现的呢？

其实，js 在底层存储变量的时候，会在变量的机器码的低位1-3位存储其类型信息👉

000：对象
010：浮点数
100：字符串
110：布尔
1：整数

but, 对于 undefined 和 null 来说，这两个值的信息存储是有点特殊的。

null：所有机器码均为0

undefined：用 −2^30 整数来表示

所以，typeof 在判断 null 的时候就出现问题了，由于 null 的所有机器码均为0，因此直接被当做了对象来看待。

然而用 instanceof 来判断的话👉

null instanceof null // TypeError: Right-hand side of 'instanceof' is not an object

null 直接被判断为不是 object，这也是 JavaScript 的历史遗留bug，可以参考typeof。

因此在用 typeof 来判断变量类型的时候，我们需要注意，最好是用 typeof 来判断基本数据类型（包括symbol），避免对 null 的判断。

还有一个不错的判断类型的方法，就是Object.prototype.toString，我们可以利用这个方法来对一个变量的类型来进行比较准确的判断

Object.prototype.toString.call(1) // "[object Number]"

Object.prototype.toString.call('hi') // "[object String]"

Object.prototype.toString.call({a:'hi'}) // "[object Object]"

Object.prototype.toString.call([1,'a']) // "[object Array]"

Object.prototype.toString.call(true) // "[object Boolean]"

Object.prototype.toString.call(() => {}) // "[object Function]"

Object.prototype.toString.call(null) // "[object Null]"

Object.prototype.toString.call(undefined) // "[object Undefined]"

Object.prototype.toString.call(Symbol(1)) // "[object Symbol]"

instanceof 操作符的实现原理

之前我们提到了 instanceof 来判断对象的具体类型，其实 instanceof 主要的作用就是判断一个实例是否属于某种类型

let person = function () {
}
let nicole = new person()
nicole instanceof person // true

当然，instanceof 也可以判断一个实例是否是其父类型或者祖先类型的实例。

let person = function () {
}
let programmer = function () {
}
programmer.prototype = new person()
let nicole = new programmer()
nicole instanceof person // true
nicole instanceof programmer // true

这是 instanceof 的用法，但是 instanceof 的原理是什么呢？根据 ECMAScript 语言规范，我梳理了一下大概的思路，然后整理了一段代码如下

function new_instance_of(leftVaule, rightVaule) { 
    let rightProto = rightVaule.prototype; // 取右表达式的 prototype 值
    leftVaule = leftVaule.__proto__; // 取左表达式的__proto__值
    while (true) {
    	if (leftVaule === null) {
            return false;	
        }
        if (leftVaule === rightProto) {
            return true;	
        } 
        leftVaule = leftVaule.__proto__ 
    }
}

其实 instanceof 主要的实现原理就是只要右边变量的 prototype 在左边变量的原型链上即可。因此，instanceof 在查找的过程中会遍历左边变量的原型链，直到找到右边变量的 prototype，如果查找失败，则会返回 false，告诉我们左边变量并非是右边变量的实例。

看几个很有趣的例子

function Foo() {
}

Object instanceof Object // true
Function instanceof Function // true
Function instanceof Object // true
Foo instanceof Foo // false
Foo instanceof Object // true
Foo instanceof Function // true

要想全部理解 instanceof 的原理，除了我们刚刚提到的实现原理，我们还需要知道 JavaScript 的原型继承原理。

关于原型继承的原理，我简单用一张图来表示

我们知道每个 JavaScript 对象均有一个隐式的 __proto__ 原型属性，而显式的原型属性是 prototype，只有 Object.prototype.__proto__ 属性在未修改的情况下为 null 值。根据图上的原理，我们来梳理上面提到的几个有趣的 instanceof 使用的例子。

Object instanceof Object

由图可知，Object 的 prototype 属性是 Object.prototype, 而由于 Object 本身是一个函数，由 Function 所创建，所以 Object.__proto__ 的值是 Function.prototype，而 Function.prototype 的 __proto__ 属性是 Object.prototype，所以我们可以判断出，Object instanceof Object 的结果是 true 。用代码简单的表示一下
```
leftValue = Object.__proto__ = Function.prototype;
rightValue = Object.prototype;
// 第一次判断
leftValue != rightValue
leftValue = Function.prototype.__proto__ = Object.prototype
// 第二次判断
leftValue === rightValue
// 返回 true
```
Function instanceof Function 和 Function instanceof Object 的运行过程与 Object instanceof Object 类似，故不再详说。

Foo instanceof Foo

Foo 函数的 prototype 属性是 Foo.prototype，而 Foo 的 __proto__ 属性是 Function.prototype，由图可知，Foo 的原型链上并没有 Foo.prototype ，因此 Foo instanceof Foo 也就返回 false 。

我们用代码简单的表示一下

leftValue = Foo, rightValue = Foo
leftValue = Foo.__proto = Function.prototype
rightValue = Foo.prototype
// 第一次判断
leftValue != rightValue
leftValue = Function.prototype.__proto__ = Object.prototype
// 第二次判断
leftValue != rightValue
leftValue = Object.prototype = null
// 第三次判断
leftValue === null
// 返回 false

Foo instanceof Object

leftValue = Foo, rightValue = Object
leftValue = Foo.__proto__ = Function.prototype
rightValue = Object.prototype
// 第一次判断
leftValue != rightValue
leftValue = Function.prototype.__proto__ = Object.prototype
// 第二次判断
leftValue === rightValue
// 返回 true

Foo instanceof Function

leftValue = Foo, rightValue = Function
leftValue = Foo.__proto__ = Function.prototype
rightValue = Function.prototype
// 第一次判断
leftValue === rightValue
// 返回 true

总结

简单来说，我们使用 typeof 来判断基本数据类型是 ok 的，不过需要注意当用 typeof 来判断 null 类型时的问题，如果想要判断一个对象的具体类型可以考虑用 instanceof，但是 instanceof 也可能判断不准确，比如一个数组，他可以被 instanceof 判断为 Object。所以我们要想比较准确的判断对象实例的类型时，可以采取 Object.prototype.toString.call 方法。

Q5、原型链继承

举个例子

 function Parent() {
    this.name = 'parent1';
    this.play = [1, 2, 3]
  }
  function Child() {
    this.type = 'child2';
  }
  Child1.prototype = new Parent();
  console.log(new Child())

上面代码看似没问题，实际存在潜在问题

var s1 = new Child();
var s2 = new Child();
s1.play.push(4);
console.log(s1.play, s2.play); // [1,2,3,4]

改变s1的play属性，会发现s2也跟着发生变化了，这是因为两个实例使用的是同一个原型对象，内存空间是共享的

Q6、执行上下文、执行上下文栈

后续补上

Q7、作用域、作用域链

后续补上

Q8、闭包

闭包

了解闭包前先来了解一下上级作用域和堆栈内存释放问题。

上级作用域的概念

函数的上级作用域在哪里创建创建的，上级作用域就是谁

var a = 10
function foo(){
    console.log(a)
}

function sum() {
    var a = 20
    foo()
}

sum()
/* 输出
    10
/

函数 foo() 是在全局下创建的，所以 a 的上级作用域就是 window，输出就是 10

思考题

var n = 10
function fn(){
    var n =20
    function f() {
       n++;
       console.log(n)
     }
    f()
    return f
}

var x = fn()
x()
x()
console.log(n)
/* 输出
*  21
    22
    23
    10
/

稍微提个醒，单独的 n++ 和 ++n 表达式的结果是一样的

思路：fn 的返回值是什么变量 x 就是什么，这里 fn 的返回值是函数名 f 也就是 f 的堆内存地址，x() 也就是执行的是函数 f()，而不是 fn()，输出的结果显而易见

关于如何查找上级作用域

参考：彻底解决 JS 变量提升的面试题

JS 堆栈内存释放

堆内存：存储引用类型值，对象类型就是键值对，函数就是代码字符串。
堆内存释放：将引用类型的空间地址变量赋值成 null，或没有变量占用堆内存了浏览器就会释放掉这个地址
栈内存：提供代码执行的环境和存储基本类型值。
栈内存释放：一般当函数执行完后函数的私有作用域就会被释放掉。

但栈内存的释放也有特殊情况：① 函数执行完，但是函数的私有作用域内有内容被栈外的变量还在使用的，栈内存就不能释放里面的基本值也就不会被释放。② 全局下的栈内存只有页面被关闭的时候才会被释放

闭包是什么

在 JS 忍者秘籍(P90)中对闭包的定义：闭包允许函数访问并操作函数外部的变量。红宝书上对于闭包的定义：闭包是指有权访问另外一个函数作用域中的变量的函数。 MDN 对闭包的定义为：闭包是指那些能够访问自由变量的函数。这里的自由变量是外部函数作用域中的变量。

概述上面的话，闭包是指有权访问另一个函数作用域中变量的函数

形成闭包的原因

内部的函数存在外部作用域的引用就会导致闭包。从上面介绍的上级作用域的概念中其实就有闭包的例子 return f就是一个表现形式。

var a = 0
function foo(){
    var b =14
    function fo(){
        console.log(a, b)
    }
    fo()
}
foo()

这里的子函数 fo 内存就存在外部作用域的引用 a, b，所以这就会产生闭包

闭包变量存储的位置

直接说明：闭包中的变量存储的位置是堆内存。

假如闭包中的变量存储在栈内存中，那么栈的回收会把处于栈顶的变量自动回收。所以闭包中的变量如果处于栈中那么变量被销毁后，闭包中的变量就没有了。所以闭包引用的变量是出于堆内存中的。

闭包的作用

保护函数的私有变量不受外部的干扰。形成不销毁的栈内存。
保存，把一些函数内的值保存下来。闭包可以实现方法和属性的私有化

闭包经典使用场景

1. return 回一个函数

var n = 10
function fn(){
    var n =20
    function f() {
       n++;
       console.log(n)
     }
    return f
}

var x = fn()
x() // 21

这里的 return f, f()就是一个闭包，存在上级作用域的引用。

1. 函数作为参数

var a = '林一一'
function foo(){
    var a = 'foo'
    function fo(){
        console.log(a)
    }
    return fo
}

function f(p){
    var a = 'f'
    p()
}
f(foo())
/* 输出
*   foo
/

使用 return fo 返回回来，fo() 就是闭包，f(foo()) 执行的参数就是函数 fo，因为 fo() 中的 a 的上级作用域就是函数foo()，所以输出就是foo

1. IIFE（自执行函数）

var n = '林一一';
(function p(){
    console.log(n)
})()
/* 输出
*   林一一
/

同样也是产生了闭包p()，存在 window下的引用 n。

1. 循环赋值

for(var i = 0; i<10; i++){
  (function(j){
       setTimeout(function(){
        console.log(j)
    }, 1000) 
  })(i)
}

因为存在闭包的原因上面能依次输出1~10，闭包形成了10个互不干扰的私有作用域。将外层的自执行函数去掉后就不存在外部作用域的引用了，输出的结果就是连续的 10。为什么会连续输出10，因为 JS 是单线程的遇到异步的代码不会先执行(会入栈)，等到同步的代码执行完 i++ 到 10时，异步代码才开始执行此时的 i=10 输出的都是 10。

1. 使用回调函数就是在使用闭包

window.name = '林一一'
setTimeout(function timeHandler(){
  console.log(window.name);
}, 100)

1. 节流防抖

// 节流
function throttle(fn, timeout) {
    let timer = null
    return function (...arg) {
        if(timer) return
        timer = setTimeout(() => {
            fn.apply(this, arg)
            timer = null
        }, timeout)
    }
}

// 防抖
function debounce(fn, timeout){
    let timer = null
    return function(...arg){
        clearTimeout(timer)
        timer = setTimeout(() => {
            fn.apply(this, arg)
        }, timeout)
    }
}

1. 柯里化实现

function curry(fn, len = fn.length) {
    return _curry(fn, len)
}

function _curry(fn, len, ...arg) {
    return function (...params) {
        let _arg = [...arg, ...params]
        if (_arg.length >= len) {
            return fn.apply(this, _arg)
        } else {
            return _curry.call(this, fn, len, ..._arg)
        }
    }
}

let fn = curry(function (a, b, c, d, e) {
    console.log(a + b + c + d + e)
})

fn(1, 2, 3, 4, 5)  // 15
fn(1, 2)(3, 4, 5)
fn(1, 2)(3)(4)(5)
fn(1)(2)(3)(4)(5)

使用闭包需要注意什么

容易导致内存泄漏。闭包会携带包含其它的函数作用域，因此会比其他函数占用更多的内存。过度使用闭包会导致内存占用过多，所以要谨慎使用闭包。

怎么检查内存泄露

performance 面板和 memory 面板可以找到泄露的现象和位置

详细可以查看：js 内存泄漏场景、如何监控以及分析

经典面试题

for 循环和闭包(号称必刷题)

var data = [];

for (var i = 0; i < 3; i++) {
  data[i] = function () {
    console.log(i);
  };
}

data[0]();
data[1]();
data[2]()
/* 输出
    3
    3
    3
/

这里的 i 是全局下的 i，共用一个作用域，当函数被执行的时候这时的 i=3，导致输出的结构都是3。

使用闭包改善上面的写法达到预期效果，写法1：自执行函数和闭包

var data = [];

for (var i = 0; i < 3; i++) {
    (function(j){
      setTimeout( data[j] = function () {
        console.log(j);
      }, 0)
    })(i)
}

data[0]();
data[1]();
data[2]()

写法2：使用 let

var data = [];

for (let i = 0; i < 3; i++) {
  data[i] = function () {
    console.log(i);
  };
}

data[0]();
data[1]();
data[2]()

let 具有块级作用域，形成的3个私有作用域都是互不干扰的。

思考题和上面有何不同 (字节)

var result = [];
var a = 3;
var total = 0;

function foo(a) {
    for (var i = 0; i < 3; i++) {
        result[i] = function () {
            total += i * a;
            console.log(total);
        }
    }
}

foo(1);
result[0]();  // 3
result[1]();  // 6
result[2]();  // 9

tip：这里也形成了闭包。total 被外层引用没有被销毁。

Q9、延时器setTimeout(() =>{}, 1000)是在1000ms后立即执行吗

不一定，会受到事件循环机制的影响。

Q10、循环添加点击事件

上面闭包的后面有写

Q11、说一说什么是内存泄漏、内存溢出

简略来说，内存泄漏就是未清除的变量或者方法，内存溢出就是指无法申请获得足够内存而发生的错误

Q12、v8引擎的垃圾回收机制

GC是什么

GC 即 Garbage Collection ，程序工作过程中会产生很多 垃圾，这些垃圾是程序不用的内存或者是之前用过了，以后不会再用的内存空间，而 GC 就是负责回收垃圾的，因为他工作在引擎内部，所以对于我们前端来说，GC 过程是相对比较无感的，这一套引擎执行而对我们又相对无感的操作也就是常说的 垃圾回收机制 了

当然也不是所有语言都有 GC，一般的高级语言里面会自带 GC，比如 Java、Python、JavaScript 等，也有无 GC 的语言，比如 C、C++ 等，那这种就需要我们程序员手动管理内存了，相对比较麻烦

垃圾产生&为何回收

我们知道写代码时创建一个基本类型、对象、函数……都是需要占用内存的，但是我们并不关注这些，因为这是引擎为我们分配的，我们不需要显式手动的去分配内存

但是，你有没有想过，当我们不再需要某个东西时会发生什么？JavaScript 引擎又是如何发现并清理它的呢？

我们举个简单的例子

let test = {
  name: "isboyjc"
};
test = [1,2,3,4,5]

如上所示，我们假设它是一个完整的程序代码

我们知道 JavaScript 的引用数据类型是保存在堆内存中的，然后在栈内存中保存一个对堆内存中实际对象的引用，所以，JavaScript 中对引用数据类型的操作都是操作对象的引用而不是实际的对象。可以简单理解为，栈内存中保存了一个地址，这个地址和堆内存中的实际值是相关的

那上面代码首先我们声明了一个变量 test，它引用了对象 {name: 'isboyjc'}，接着我们把这个变量重新赋值了一个数组对象，也就变成了该变量引用了一个数组，那么之前的对象引用关系就没有了，如下图

没有了引用关系，也就是无用的对象，这个时候假如任由它搁置，一个两个还好，多了的话内存也会受不了，所以就需要被清理（回收）

用官方一点的话说，程序的运行需要内存，只要程序提出要求，操作系统或者运行时就必须提供内存，那么对于持续运行的服务进程，必须要及时释放内存，否则，内存占用越来越高，轻则影响系统性能，重则就会导致进程崩溃

垃圾回收策略

在 JavaScript 内存管理中有一个概念叫做 可达性，就是那些以某种方式可访问或者说可用的值，它们被保证存储在内存中，反之不可访问则需回收

至于如何回收，其实就是怎样发现这些不可达的对象（垃圾）它并给予清理的问题， JavaScript 垃圾回收机制的原理说白了也就是定期找出那些不再用到的内存（变量），然后释放其内存

你可能还会好奇为什么不是实时的找出无用内存并释放呢？其实很简单，实时开销太大了

我们都可以 Get 到这之中的重点，那就是怎样找出所谓的垃圾？

这个流程就涉及到了一些算法策略，有很多种方式，我们简单介绍两个最常见的

标记清除算法
引用计数算法

标记清除算法

策略

标记清除（Mark-Sweep），目前在 JavaScript引擎 里这种算法是最常用的，到目前为止的大多数浏览器的 JavaScript引擎 都在采用标记清除算法，只是各大浏览器厂商还对此算法进行了优化加工，且不同浏览器的 JavaScript引擎 在运行垃圾回收的频率上有所差异

就像它的名字一样，此算法分为 标记 和 清除 两个阶段，标记阶段即为所有活动对象做上标记，清除阶段则把没有标记（也就是非活动对象）销毁

你可能会疑惑怎么给变量加标记？其实有很多种办法，比如当变量进入执行环境时，反转某一位（通过一个二进制字符来表示标记），又或者可以维护进入环境变量和离开环境变量这样两个列表，可以自由的把变量从一个列表转移到另一个列表，当前还有很多其他办法。其实，怎样标记对我们来说并不重要，重要的是其策略

引擎在执行 GC（使用标记清除算法）时，需要从出发点去遍历内存中所有的对象去打标记，而这个出发点有很多，我们称之为一组 根 对象，而所谓的根对象，其实在浏览器环境中包括又不止于 全局Window对象、文档DOM树 等

整个标记清除算法大致过程就像下面这样

垃圾收集器在运行时会给内存中的所有变量都加上一个标记，假设内存中所有对象都是垃圾，全标记为0
然后从各个根对象开始遍历，把不是垃圾的节点改成1
清理所有标记为0的垃圾，销毁并回收它们所占用的内存空间
最后，把所有内存中对象标记修改为0，等待下一轮垃圾回收

优点

标记清除算法的优点只有一个，那就是实现比较简单，打标记也无非打与不打两种情况，这使得一位二进制位（0和1）就可以为其标记，非常简单

缺点

标记清除算法有一个很大的缺点，就是在清除之后，剩余的对象内存位置是不变的，也会导致空闲内存空间是不连续的，出现了 内存碎片（如下图），并且由于剩余空闲内存不是一整块，它是由不同大小内存组成的内存列表，这就牵扯出了内存分配的问题

假设我们新建对象分配内存时需要大小为 size，由于空闲内存是间断的、不连续的，则需要对空闲内存列表进行一次单向遍历找出大于等于 size 的块才能为其分配（如下图）

那如何找到合适的块呢？我们可以采取下面三种分配策略

First-fit，找到大于等于 size 的块立即返回
Best-fit，遍历整个空闲列表，返回大于等于 size 的最小分块
Worst-fit，遍历整个空闲列表，找到最大的分块，然后切成两部分，一部分 size 大小，并将该部分返回

这三种策略里面 Worst-fit 的空间利用率看起来是最合理，但实际上切分之后会造成更多的小块，形成内存碎片，所以不推荐使用，对于 First-fit 和 Best-fit 来说，考虑到分配的速度和效率 First-fit 是更为明智的选择

综上所述，标记清除算法或者说策略就有两个很明显的缺点

内存碎片化，空闲内存块是不连续的，容易出现很多空闲内存块，还可能会出现分配所需内存过大的对象时找不到合适的块
分配速度慢，因为即便是使用 First-fit 策略，其操作仍是一个 O(n) 的操作，最坏情况是每次都要遍历到最后，同时因为碎片化，大对象的分配效率会更慢

PS：标记清除算法的缺点补充

归根结底，标记清除算法的缺点在于清除之后剩余的对象位置不变而导致的空闲内存不连续，所以只要解决这一点，两个缺点都可以完美解决了

而 标记整理（Mark-Compact）算法 就可以有效地解决，它的标记阶段和标记清除算法没有什么不同，只是标记结束后，标记整理算法会将活着的对象（即不需要清理的对象）向内存的一端移动，最后清理掉边界的内存（如下图）

引用计数算法

策略

引用计数（Reference Counting），这其实是早先的一种垃圾回收算法，它把 对象是否不再需要 简化定义为 对象有没有其他对象引用到它，如果没有引用指向该对象（零引用），对象将被垃圾回收机制回收，目前很少使用这种算法了，因为它的问题很多，不过我们还是需要了解一下

它的策略是跟踪记录每个变量值被使用的次数

当声明了一个变量并且将一个引用类型赋值给该变量的时候这个值的引用次数就为 1
如果同一个值又被赋给另一个变量，那么引用数加 1
如果该变量的值被其他的值覆盖了，则引用次数减 1
当这个值的引用次数变为 0 的时候，说明没有变量在使用，这个值没法被访问了，回收空间，垃圾回收器会在运行的时候清理掉引用次数为 0 的值占用的内存

如下例

let a = new Object() 	// 此对象的引用计数为 1（a引用）
let b = a 		// 此对象的引用计数是 2（a,b引用）
a = null  		// 此对象的引用计数为 1（b引用）
b = null 	 	// 此对象的引用计数为 0（无引用）
...			// GC 回收此对象

这种方式是不是很简单？确实很简单，不过在引用计数这种算法出现没多久，就遇到了一个很严重的问题——循环引用，即对象 A 有一个指针指向对象 B，而对象 B 也引用了对象 A ，如下面这个例子

function test(){
  let A = new Object()
  let B = new Object()
  
  A.b = B
  B.a = A
}

如上所示，对象 A 和 B 通过各自的属性相互引用着，按照上文的引用计数策略，它们的引用数量都是 2，但是，在函数 test 执行完成之后，对象 A 和 B 是要被清理的，但使用引用计数则不会被清理，因为它们的引用数量不会变成 0，假如此函数在程序中被多次调用，那么就会造成大量的内存不会被释放

我们再用标记清除的角度看一下，当函数结束后，两个对象都不在作用域中，A 和 B 都会被当作非活动对象来清除掉，相比之下，引用计数则不会释放，也就会造成大量无用内存占用，这也是后来放弃引用计数，使用标记清除的原因之一

在 IE8 以及更早版本的 IE 中，BOM 和 DOM 对象并非是原生 JavaScript 对象，它是由 C++ 实现的 组件对象模型对象（COM，Component Object Model），而 COM 对象使用引用计数算法来实现垃圾回收，所以即使浏览器使用的是标记清除算法，只要涉及到 COM 对象的循环引用，就还是无法被回收掉，就比如两个互相引用的 DOM 对象等等，而想要解决循环引用，需要将引用地址置为 null 来切断变量与之前引用值的关系，如下
// COM对象
let ele = document.getElementById("xxx")
let obj = new Object()

// 造成循环引用
obj.ele = ele
ele.obj = obj

// 切断引用关系
obj.ele = null
ele.obj = null
不过在 IE9 及以后的 BOM 与 DOM 对象都改成了 JavaScript 对象，也就避免了上面的问题

此处参考 JavaScript高级程序设计第四版 4.3.2 小节

优点

引用计数算法的优点我们对比标记清除来看就会清晰很多，首先引用计数在引用值为 0 时，也就是在变成垃圾的那一刻就会被回收，所以它可以立即回收垃圾

而标记清除算法需要每隔一段时间进行一次，那在应用程序（JS脚本）运行过程中线程就必须要暂停去执行一段时间的 GC，另外，标记清除算法需要遍历堆里的活动以及非活动对象来清除，而引用计数则只需要在引用时计数就可以了

缺点

引用计数的缺点想必大家也都很明朗了，首先它需要一个计数器，而此计数器需要占很大的位置，因为我们也不知道被引用数量的上限，还有就是无法解决循环引用无法回收的问题，这也是最严重的

V8对GC的优化

我们在上面也说过，现在大多数浏览器都是基于标记清除算法，V8 亦是，当然 V8 肯定也对其进行了一些优化加工处理，那接下来我们主要就来看 V8 中对垃圾回收机制的优化

分代式垃圾回收

试想一下，我们上面所说的垃圾清理算法在每次垃圾回收时都要检查内存中所有的对象，这样的话对于一些大、老、存活时间长的对象来说同新、小、存活时间短的对象一个频率的检查很不好，因为前者需要时间长并且不需要频繁进行清理，后者恰好相反，怎么优化这点呢？？？分代式就来了

新老生代

V8 的垃圾回收策略主要基于分代式垃圾回收机制，V8 中将堆内存分为新生代和老生代两区域，采用不同的垃圾回收器也就是不同的策略管理垃圾回收

新生代的对象为存活时间较短的对象，简单来说就是新产生的对象，通常只支持 1～8M 的容量，而老生代的对象为存活事件较长或常驻内存的对象，简单来说就是经历过新生代垃圾回收后还存活下来的对象，容量通常比较大

V8 整个堆内存的大小就等于新生代加上老生代的内存（如下图）

对于新老两块内存区域的垃圾回收，V8 采用了两个垃圾回收器来管控，我们暂且将管理新生代的垃圾回收器叫做新生代垃圾回收器，同样的，我们称管理老生代的垃圾回收器叫做老生代垃圾回收器好了

新生代垃圾回收

新生代对象是通过一个名为 Scavenge 的算法进行垃圾回收，在 Scavenge算法 的具体实现中，主要采用了一种复制式的方法即 Cheney算法 ，我们细细道来

Cheney算法 中将堆内存一分为二，一个是处于使用状态的空间我们暂且称之为 使用区，一个是处于闲置状态的空间我们称之为 空闲区，如下图所示

新加入的对象都会存放到使用区，当使用区快被写满时，就需要执行一次垃圾清理操作

当开始进行垃圾回收时，新生代垃圾回收器会对使用区中的活动对象做标记，标记完成之后将使用区的活动对象复制进空闲区并进行排序，随后进入垃圾清理阶段，即将非活动对象占用的空间清理掉。最后进行角色互换，把原来的使用区变成空闲区，把原来的空闲区变成使用区

当一个对象经过多次复制后依然存活，它将会被认为是生命周期较长的对象，随后会被移动到老生代中，采用老生代的垃圾回收策略进行管理

另外还有一种情况，如果复制一个对象到空闲区时，空闲区空间占用超过了 25%，那么这个对象会被直接晋升到老生代空间中，设置为 25% 的比例的原因是，当完成 Scavenge 回收后，空闲区将翻转成使用区，继续进行对象内存的分配，若占比过大，将会影响后续内存分配

老生代垃圾回收

相比于新生代，老生代的垃圾回收就比较容易理解了，上面我们说过，对于大多数占用空间大、存活时间长的对象会被分配到老生代里，因为老生代中的对象通常比较大，如果再如新生代一般分区然后复制来复制去就会非常耗时，从而导致回收执行效率不高，所以老生代垃圾回收器来管理其垃圾回收执行，它的整个流程就采用的就是上文所说的标记清除算法了

首先是标记阶段，从一组根元素开始，递归遍历这组根元素，遍历过程中能到达的元素称为活动对象，没有到达的元素就可以判断为非活动对象

清除阶段老生代垃圾回收器会直接将非活动对象，也就是数据清理掉

前面我们也提过，标记清除算法在清除后会产生大量不连续的内存碎片，过多的碎片会导致大对象无法分配到足够的连续内存，而 V8 中就采用了我们上文中说的标记整理算法来解决这一问题来优化空间

为什么需要分代式？

正如小标题，为什么需要分代式？这个机制有什么优点又解决了什么问题呢？

其实，它并不能说是解决了什么问题，可以说是一个优化点吧

分代式机制把一些新、小、存活时间短的对象作为新生代，采用一小块内存频率较高的快速清理，而一些大、老、存活时间长的对象作为老生代，使其很少接受检查，新老生代的回收机制及频率是不同的，可以说此机制的出现很大程度提高了垃圾回收机制的效率

并行回收(Parallel)

在介绍并行之前，我们先要了解一个概念 全停顿（Stop-The-World），我们都知道 JavaScript 是一门单线程的语言，它是运行在主线程上的，那在进行垃圾回收时就会阻塞 JavaScript 脚本的执行，需等待垃圾回收完毕后再恢复脚本执行，我们把这种行为叫做 全停顿

比如一次 GC 需要 60ms ，那我们的应用逻辑就得暂停 60ms ，假如一次 GC 的时间过长，对用户来说就可能造成页面卡顿等问题

既然存在执行一次 GC 比较耗时的情况，考虑到一个人盖房子难，那两个人、十个人...呢？切换到程序这边，那我们可不可以引入多个辅助线程来同时处理，这样是不是就会加速垃圾回收的执行速度呢？因此 V8 团队引入了并行回收机制

所谓并行，也就是同时的意思，它指的是垃圾回收器在主线程上执行的过程中，开启多个辅助线程，同时执行同样的回收工作

简单来说，使用并行回收，假如本来是主线程一个人干活，它一个人需要 3 秒，现在叫上了 2 个辅助线程和主线程一块干活，那三个人一块干一个人干 1 秒就完事了，但是由于多人协同办公，所以需要加上一部分多人协同（同步开销）的时间我们算 0.5 秒好了，也就是说，采用并行策略后，本来要 3 秒的活现在 1.5 秒就可以干完了

不过虽然 1.5 秒就可以干完了，时间也大大缩小了，但是这 1.5 秒内，主线程还是需要让出来的，也正是因为主线程还是需要让出来，这个过程内存是静态的，不需要考虑内存中对象的引用关系改变，只需要考虑协同，实现起来也很简单

新生代对象空间就采用并行策略，在执行垃圾回收的过程中，会启动了多个线程来负责新生代中的垃圾清理操作，这些线程同时将对象空间中的数据移动到空闲区域，这个过程中由于数据地址会发生改变，所以还需要同步更新引用这些对象的指针，此即并行回收

增量标记与懒性清理

我们上面所说的并行策略虽然可以增加垃圾回收的效率，对于新生代垃圾回收器能够有很好的优化，但是其实它还是一种全停顿式的垃圾回收方式，对于老生代来说，它的内部存放的都是一些比较大的对象，对于这些大的对象 GC 时哪怕我们使用并行策略依然可能会消耗大量时间

所以为了减少全停顿的时间，在 2011 年，V8 对老生代的标记进行了优化，从全停顿标记切换到增量标记

什么是增量

增量就是将一次 GC 标记的过程，分成了很多小步，每执行完一小步就让应用逻辑执行一会儿，这样交替多次后完成一轮 GC 标记（如下图）

试想一下，将一次完整的 GC 标记分次执行，那在每一小次 GC 标记执行完之后如何暂停下来去执行任务程序，而后又怎么恢复呢？那假如我们在一次完整的 GC 标记分块暂停后，执行任务程序时内存中标记好的对象引用关系被修改了又怎么办呢？

可以看出增量的实现要比并行复杂一点，V8 对这两个问题对应的解决方案分别是三色标记法与写屏障

三色标记法(暂停与恢复)

我们知道老生代是采用标记清理算法，而上文的标记清理中我们说过，也就是在没有采用增量算法之前，单纯使用黑色和白色来标记数据就可以了，其标记流程即在执行一次完整的 GC 标记前，垃圾回收器会将所有的数据置为白色，然后垃圾回收器在会从一组跟对象出发，将所有能访问到的数据标记为黑色，遍历结束之后，标记为黑色的数据对象就是活动对象，剩余的白色数据对象也就是待清理的垃圾对象

如果采用非黑即白的标记策略，那在垃圾回收器执行了一段增量回收后，暂停后启用主线程去执行了应用程序中的一段 JavaScript 代码，随后当垃圾回收器再次被启动，这时候内存中黑白色都有，我们无法得知下一步走到哪里了

为了解决这个问题，V8 团队采用了一种特殊方式： 三色标记法

三色标记法即使用每个对象的两个标记位和一个标记工作表来实现标记，两个标记位编码三种颜色：白、灰、黑

白色指的是未被标记的对象
灰色指自身被标记，成员变量（该对象的引用对象）未被标记
黑色指自身和成员变量皆被标记

如上图所示，我们用最简单的表达方式来解释这一过程，最初所有的对象都是白色，意味着回收器没有标记它们，从一组根对象开始，先将这组根对象标记为灰色并推入到标记工作表中，当回收器从标记工作表中弹出对象并访问它的引用对象时，将其自身由灰色转变成黑色，并将自身的下一个引用对象转为灰色

就这样一直往下走，直到没有可标记灰色的对象时，也就是无可达（无引用到）的对象了，那么剩下的所有白色对象都是无法到达的，即等待回收（如上图中的 C、E 将要等待回收）

采用三色标记法后我们在恢复执行时就好办多了，可以直接通过当前内存中有没有灰色节点来判断整个标记是否完成，如没有灰色节点，直接进入清理阶段，如还有灰色标记，恢复时直接从灰色的节点开始继续执行就可以

三色标记法的 mark 操作可以渐进执行的而不需每次都扫描整个内存空间，可以很好的配合增量回收进行暂停恢复的一些操作，从而减少 全停顿 的时间

写屏障(增量中修改引用)

一次完整的 GC 标记分块暂停后，执行任务程序时内存中标记好的对象引用关系被修改了，增量中修改引用，可能不太好理解，我们举个例子（如图）

假如我们有 A、B、C 三个对象依次引用，在第一次增量分段中全部标记为黑色（活动对象），而后暂停开始执行应用程序也就是 JavaScript 脚本，在脚本中我们将对象 B 的指向由对象 C 改为了对象 D ，接着恢复执行下一次增量分段

这时其实对象 C 已经无引用关系了，但是目前它是黑色（代表活动对象）此一整轮 GC 是不会清理 C 的，不过我们可以不考虑这个，因为就算此轮不清理等下一轮 GC 也会清理，这对我们程序运行并没有太大影响

我们再看新的对象 D 是初始的白色，按照我们上面所说，已经没有灰色对象了，也就是全部标记完毕接下来要进行清理了，新修改的白色对象 D 将在次轮 GC 的清理阶段被回收，还有引用关系就被回收，后面我们程序里可能还会用到对象 D 呢，这肯定是不对的

为了解决这个问题，V8 增量回收使用 写屏障 (Write-barrier) 机制，即一旦有黑色对象引用白色对象，该机制会强制将引用的白色对象改为灰色，从而保证下一次增量 GC 标记阶段可以正确标记，这个机制也被称作 强三色不变性

那在我们上图的例子中，将对象 B 的指向由对象 C 改为对象 D 后，白色对象 D 会被强制改为灰色

懒性清理

增量标记其实只是对活动对象和非活动对象进行标记，对于真正的清理释放内存 V8 采用的是惰性清理(Lazy Sweeping)

增量标记完成后，惰性清理就开始了。当增量标记完成后，假如当前的可用内存足以让我们快速的执行代码，其实我们是没必要立即清理内存的，可以将清理过程稍微延迟一下，让 JavaScript 脚本代码先执行，也无需一次性清理完所有非活动对象内存，可以按需逐一进行清理直到所有的非活动对象内存都清理完毕，后面再接着执行增量标记

增量标记与惰性清理的优缺？

增量标记与惰性清理的出现，使得主线程的停顿时间大大减少了，让用户与浏览器交互的过程变得更加流畅。但是由于每个小的增量标记之间执行了 JavaScript 代码，堆中的对象指针可能发生了变化，需要使用写屏障技术来记录这些引用关系的变化，所以增量标记缺点也很明显：

首先是并没有减少主线程的总暂停的时间，甚至会略微增加，其次由于写屏障机制的成本，增量标记可能会降低应用程序的吞吐量（吞吐量是啥总不用说了吧）

并发回收(Concurrent)

前面我们说并行回收依然会阻塞主线程，增量标记同样有增加了总暂停时间、降低应用程序吞吐量两个缺点，那么怎么才能在不阻塞主线程的情况下执行垃圾回收并且与增量相比更高效呢？

这就要说到并发回收了，它指的是主线程在执行 JavaScript 的过程中，辅助线程能够在后台完成执行垃圾回收的操作，辅助线程在执行垃圾回收的时候，主线程也可以自由执行而不会被挂起（如下图）

辅助线程在执行垃圾回收的时候，主线程也可以自由执行而不会被挂起，这是并发的优点，但同样也是并发回收实现的难点，因为它需要考虑主线程在执行 JavaScript 时，堆中的对象引用关系随时都有可能发生变化，这时辅助线程之前做的一些标记或者正在进行的标记就会要有所改变，所以它需要额外实现一些读写锁机制来控制这一点，这里我们不再细说

再说V8中GC优化

V8 的垃圾回收策略主要基于分代式垃圾回收机制，这我们说过，关于新生代垃圾回收器，我们说使用并行回收可以很好的增加垃圾回收的效率，那老生代垃圾回收器用的哪个策略呢？我上面说了并行回收、增量标记与惰性清理、并发回收这几种回收方式来提高效率、优化体验，看着一个比一个好，那老生代垃圾回收器到底用的哪个策略？难道是并发？？内心独白：” 好像。。貌似。。并发回收效率最高 “

其实，这三种方式各有优缺点，所以在老生代垃圾回收器中这几种策略都是融合使用的

老生代主要使用并发标记，主线程在开始执行 JavaScript 时，辅助线程也同时执行标记操作（标记操作全都由辅助线程完成）

标记完成之后，再执行并行清理操作（主线程在执行清理操作时，多个辅助线程也同时执行清理操作）

同时，清理的任务会采用增量的方式分批在各个 JavaScript 任务之间执行

最后

那上面就是 V8 引擎为我们的垃圾回收所做的一些主要优化了，虽然引擎有优化，但并不是说我们就可以完全不用关心垃圾回收这块了，我们的代码中依然要主动避免一些不利于引擎做垃圾回收操作，因为不是所有无用对象内存都可以被回收的，那当不再用到的内存，没有及时回收时，我们叫它 内存泄漏

Q13、H5 Web Workers

juejin.cn/post/684490…

学习总结3