JavaScript 引擎如何执行 JavaScript 代码

# JavaScript 引擎如何执行 JavaScript 代码

引擎

从头到尾负责整个 JavaScript 程序的编译及执行过程。

编译器

引擎的好朋友之一，负责语法分析及代码生成等脏活累活。

作用域

引擎的另一位好朋友，负责收集并维护由所有声明的标识符（变量）组成的一系列查询，并实施一套非常严格的规则，确定当前执行的代码对这些标识符的访问权限。

JS 引擎在执行代码时，会从上到下进行词法分析、语法分析、语义分析等处理，并在代码解析完成后生成 AST（抽象语法树），最终根据 AST 生成 CPU 可以执行的机器码并执行，可以称为 语法分析阶段

# 对代码处理

当看见 var a = 2; 这段程序时，很可能认为这是一句声明。但引擎却不这么看。事实上，引擎认为这里有两个完全不同的声明，一个由编译器在编译时处理，另一个则由引擎在运行时处理。

下面将 var a = 2; 分解，看看引擎和它的朋友们是如何协同工作的。编译器首先会将这段程序分解成词法单元，然后将词法单元解析成一个树结构。但是当编译器开始进行代码生成时，它对这段程序的处理方式会和预期的有所不同。

可以合理地假设编译器所产生的代码能够用下面的伪代码进行概括：“为一个变量分配内存，将其命名为 a，然后将值 2 保存进这个变量。”然而，这并不完全正确。事实上编译器会进行如下处理。

遇到 var a，编译器会询问作用域是否已经有一个该名称的变量存在于同一个作用域的集合中。如果是，编译器会忽略该声明，继续进行编译；否则它会要求作用域在当前作用域的集合中声明一个新的变量，并命名为 a。
接下来编译器会为引擎生成运行时所需的代码，这些代码被用来处理 a = 2 这个赋值操作。引擎运行时会首先询问作用域，在当前的作用域集合中是否存在一个叫作 a 的变量。如果是，引擎就会使用这个变量；如果否，引擎会继续查找该变量。

如果引擎最终找到了 a 变量，就会将 2 赋值给它。否则引擎就会举手示意并抛出一个异常！

总结：变量的赋值操作会执行两个动作，首先编译器会在当前作用域中声明一个变量（如果之前没有声明过），然后在运行时引擎会在作用域中查找该变量，如果能够找到就会对它赋值。

编译器在编译过程的第二步中生成了代码，引擎执行它时，会通过查找变量 a 来判断它是否已声明过。查找的过程由作用域进行协助，但是引擎执行怎样的查找，会影响最终的查找结果。

例子中，引擎会为变量 a 进行 LHS 查询。另外一个查找的类型叫作 RHS。

当变量出现在赋值操作的左侧时进行 LHS 查询，出现在右侧时进行 RHS 查询。

讲得更准确一点，RHS 查询与简单地查找某个变量的值别无二致，而 LHS 查询则是试图找到变量的容器本身，从而可以对其赋值。从这个角度说，RHS 并不是真正意义上的“赋值操作的右侧”，更准确地说是“非左侧”。

可以将 RHS 理解成 retrieve his source value（取到它的源值），这意味着“得到某某的值”

console.log( a );

其中对 a 的引用是一个 RHS 引用，因为这里 a 并没有赋予任何值。相应地，需要查找并取得 a 的值，这样才能将值传递给 console.log(..)。相比之下，例如：

a = 2;

这里对 a 的引用则是 LHS 引用，因为实际上我们并不关心当前的值是什么，只是想要为 =2 这个赋值操作找到一个目标。

“赋值操作的目标是谁（LHS）”以及“谁是赋值操作的源头（RHS）”。

function foo(a) {
  console.log( a ); // 2
}
foo( 2 );

最后一行 foo(..) 函数的调用需要对 foo 进行 RHS 引用，意味着“去找到 foo 的值，并把它给我”。并且 (..) 意味着 foo 的值需要被执行，因此它最好真的是一个函数类型的值！

这里还有一个容易被忽略却非常重要的细节。

代码中隐式的 a＝2 操作可能很容易被你忽略掉。这个操作发生在 2 被当作参数传递给foo(..) 函数时，2 会被分配给参数 a。为了给参数 a（隐式地）分配值，需要进行一次LHS 查询。

这里还有对a进行的RHS引用，并且将得到的值传给了console.log(..)。console.log(..) 本身也需要一个引用才能执行，因此会对 console对象进行 RHS 查询，并且检查得到的值中是否有一个叫作 log 的方法。

最后，在概念上可以理解为在 LHS 和 RHS 之间通过对值 2 进行交互来将其传递进 log(..)（通过变量 a 的 RHS 查询）。假设在 log(..) 函数的原生实现中它可以接受参数，在将 2 赋值给其中第一个（也许叫作 arg1）参数之前，这个参数需要进行 LHS 引用查询。

ES5 中引入了“严格模式”。同正常模式，或者说宽松 / 懒惰模式相比，严格模式在行为上有很多不同。其中一个不同的行为是严格模式禁止自动或隐式地创建全局变量。因此，在严格模式中 LHS 查询失败时，并不会创建并返回一个全局变量，引擎会抛出同 RHS 查询失败时类似的 ReferenceError 异常。

接下来，如果 RHS 查询找到了一个变量，但是你尝试对这个变量的值进行不合理的操作，比如试图对一个非函数类型的值进行函数调用，或着引用 null 或 undefined 类型的值中的属性，那么引擎会抛出另外一种类型的异常，叫作 TypeError。

ReferenceError 同作用域判别失败相关，而 TypeError 则代表作用域判别成功了，但是对结果的操作是非法或不合理的。

LHS 和 RHS 查询都会在当前执行作用域中开始，如果有需要（也就是说它们没有找到所需的标识符），就会向上级作用域继续查找目标标识符，这样每次上升一级作用域（一层楼），最后抵达全局作用域（顶层），无论找到或没找到都将停止。

不成功的 RHS 引用会导致抛出 ReferenceError 异常。不成功的 LHS 引用会导致自动隐式地创建一个全局变量（非严格模式下），该变量使用 LHS 引用的目标作为标识符，或者抛出 ReferenceError 异常（严格模式下）。

# 引擎和作用域的对话

function foo(a) {
  console.log( a ); // 2
}
foo( 2 );

'use scrict';
var a =1 
a.b.c

引擎：我说作用域，我需要为 foo 进行 RHS 引用。你见过它吗？
作用域：别说，我还真见过，编译器那小子刚刚声明了它。它是一个函数，给你。
引擎：哥们太够意思了！好吧，我来执行一下 foo。
引擎：作用域，还有个事儿。我需要为 a 进行 LHS 引用，这个你见过吗？
作用域：这个也见过，编译器最近把它声名为 foo 的一个形式参数了，拿去吧。
引擎：大恩不言谢，你总是这么棒。现在我要把 2 赋值给 a。
引擎：哥们，不好意思又来打扰你。我要为 console 进行 RHS 引用，你见过它吗？
作用域：咱俩谁跟谁啊，再说我就是干这个。这个我也有，console 是个内置对象。
给你。
引擎：么么哒。我得看看这里面是不是有 log(..)。太好了，找到了，是一个函数。
引擎：哥们，能帮我再找一下对 a 的 RHS 引用吗？虽然我记得它，但想再确认一次。
作用域：放心吧，这个变量没有变动过，拿走，不谢。
引擎：真棒。我来把 a 的值，也就是 2，传递进 log(..)。

# 作用域嵌套

我们说过，作用域是根据名称查找变量的一套规则。实际情况中，通常需要同时顾及几个作用域。

当一个块或函数嵌套在另一个块或函数中时，就发生了作用域的嵌套。因此，在当前作用域中无法找到某个变量时，引擎就会在外层嵌套的作用域中继续查找，直到找到该变量，或抵达最外层的作用域（也就是全局作用域）为止。

function foo(a) {
  console.log( a + b );
}
var b = 2;
foo( 2 ); // 4

对 b 进行的 RHS 引用无法在函数 foo 内部完成，但可以在上一级作用域（在这个例子中就是全局作用域）中完成。

因此，回顾一下引擎和作用域之间的对话，会进一步听到：

引擎：foo 的作用域兄弟，你见过 b 吗？我需要对它进行 RHS 引用。
作用域：听都没听过，走开。
引擎：foo 的上级作用域兄弟，咦？有眼不识泰山，原来你是全局作用域大哥，
太好了。你见过 b 吗？我需要对它进行 RHS 引用。
作用域：当然了，给你吧。

遍历嵌套作用域链的规则很简单：引擎从当前的执行作用域开始查找变量，如果找不到，就向上一级继续查找。当抵达最外层的全局作用域时，无论找到还是没找到，查找过程都会停止。

# v8引擎

在 V8 引擎中 JavaScript 代码的运行过程主要分成三个阶段

语法分析阶段。该阶段会对代码进行语法分析，检查是否有语法错误（SyntaxError），如果发现语法错误，会在控制台抛出异常并终止执行。
编译阶段。该阶段会进行执行上下文（Execution Context）的创建，包括创建变量对象、建立作用域链、确定 this 的指向等。每进入一个不同的运行环境时，V8 引擎都会创建一个新的执行上下文。
执行阶段。将编译阶段中创建的执行上下文压入调用栈，并成为正在运行的执行上下文，代码执行结束后，将其弹出调用栈。

# 执行上下文的创建

执行上下文的创建离不开 JavaScript 的运行环境，JavaScript 运行环境包括全局环境、函数环境和eval ，其中全局环境和函数环境的创建过程如下：

第一次载入 JavaScript 代码时，首先会创建一个全局环境。全局环境位于最外层，直到应用程序退出后（例如关闭浏览器和网页）才会被销毁。
每个函数都有自己的运行环境，当函数被调用时，则会进入该函数的运行环境。当该环境中的代码被全部执行完毕后，该环境会被销毁。不同的函数运行环境不一样，即使是同一个函数，在被多次调用时也会创建多个不同的函数环境。

在不同的运行环境中，变量和函数可访问的其他数据范围不同，环境的行为（比如创建和销毁）也有所区别。而 每进入一个不同的运行环境时，JavaScript 都会创建一个新的执行上下文，该过程包括：

建立作用域链（Scope Chain）；
创建变量对象（Variable Object，简称 VO）；
确定 this 的指向。

# 创建变量对象

什么是变量对象呢？每个执行上下文都会有一个关联的变量对象，该对象上会保存这个上下文中定义的所有变量和函数。

而在浏览器中，全局环境的变量对象是window对象，因此所有的全局变量和函数都是作为window对象的属性和方法创建的。相应的，在 Node 中全局环境的变量对象则是global对象。

了解了什么是变量对象之后，我们来看下创建变量对象的过程。创建变量对象将会创建arguments对象（仅函数环境下），同时会检查当前上下文的函数声明和变量声明。

对于变量声明：此时会给变量分配内存，并将其初始化为undefined（该过程只进行定义声明，执行阶段才执行赋值语句）。
对于函数声明：此时会在内存里创建函数对象，并且直接初始化为该函数对象。

上述变量声明和函数声明的处理过程，便是我们常说的变量提升和函数提升，其中函数声明提升会优先于变量声明提升。因为变量提升容易带来变量在预期外被覆盖掉的问题，同时还可能导致本应该被销毁的变量没有被销毁等情况。因此 ES6 中引入了let和const关键字，从而使 JavaScript 也拥有了块级作用域。

JavaScript 是怎么支持块级作用域的呢？这就涉及作用域的概念。

在各类编程语言中，作用域分为静态作用域和动态作用域。JavaScript 采用的是词法作用域（Lexical Scoping），也就是静态作用域。词法作用域中的变量，在编译过程中会产生一个确定的作用域。

刚刚说到，词法作用域中的变量，在编译过程中会产生一个确定的作用域，这个作用域即当前的执行上下文，在 ES5 后我们使用词法环境（Lexical Environment）替代作用域来描述该执行上下文。因此，词法环境可理解为我们常说的作用域，同样也指当前的执行上下文（注意，是当前的执行上下文）。

在 JavaScript 中，词法环境又分为词法环境（Lexical Environment）和变量环境（Variable Environment）两种，其中：

变量环境用来记录var/function等变量声明；
词法环境是用来记录let/const/class等变量声明。

也就是说，创建变量过程中会进行函数提升和变量提升，JavaScript 会通过词法环境来记录函数和变量声明。通过使用两个词法环境（而不是一个）分别记录不同的变量声明内容，JavaScript 实现了支持块级作用域的同时，不影响原有的变量声明和函数声明。

这就是创建变量的过程，它属于执行上下文创建中的一环。创建变量的过程会产生作用域，作用域也被称为词法环境。

# 建立作用域链

作用域链，顾名思义，就是将各个作用域通过某种方式连接在一起。

前面说过，作用域就是词法环境，等于当前的执行上下文，而词法环境由两个成员组成。

环境记录（Environment Record）：用于记录自身词法环境中的变量对象。
外部词法环境引用（Outer Lexical Environment）：记录外层词法环境的引用。

通过外部词法环境的引用，作用域可以层层拓展，建立起从里到外延伸的一条作用域链。当某个变量无法在自身词法环境记录中找到时，可以根据外部词法环境引用向外层进行寻找，直到最外层的词法环境中外部词法环境引用为null，这便是作用域链的变量查询。

那么，这个外部词法环境引用又是怎样指向外层呢？我们来看看 JavaScript 中是如何通过外部词法环境引用来创建作用域的。

为了方便描述，我们将 JavaScript 代码运行过程分为定义期和执行期，前面提到的编译阶段则属于定义期。

来看一个例子，我们定义了全局函数foo，并在该函数中定义了函数bar

function foo() {
  console.dir(bar);
  var a = 1;
  function bar() {
    a = 2;
  }
}
console.dir(foo);
foo();

JavaScript 使用的是静态作用域，因此函数的作用域在定义期已经决定了。在上面的例子中，全局函数foo创建了一个foo的[[scope]]属性，包含了全局[[scope]]：

foo[[scope]] = [globalContext];

而当执行foo()时，也会分别进入foo函数的定义期和执行期。

在foo函数的定义期时，函数bar的[[scope]]将会包含全局[[scope]]和foo的[[scope]]：

bar[[scope]] = [fooContext, globalContext];

JavaScript 会通过外部词法环境引用来创建变量对象的一个作用域链，从而保证对执行环境有权访问的变量和函数的有序访问。除了创建作用域链之外，在这个过程中还会对创建的变量对象做一些处理。

前面我们说过，编译阶段会进行变量对象（VO）的创建，该过程会进行函数声明和变量声明，这时候变量的值被初始化为 undefined。在代码进入执行阶段之后，JavaScript 会对变量进行赋值，此时变量对象会转为活动对象（Active Object，简称 AO），转换后的活动对象才可被访问，这就是 VO -> AO 的过程。

为了更好地理解这个过程，我们来看个例子，我们在foo函数中定义了变量b、函数c和函数表达式变量d：

function foo(a) {
  var b = 2;
  function c() {}
  var d = function() {};
}
foo(1);

在执行foo(1)时，首先进入定义期，此时：

参数变量a的值为1
变量b和d初始化为undefined
函数c创建函数并初始化

AO = {
  arguments: {
    0: 1,
    length: 1
  },
  a: 1,
  b: undefined,
  c: reference to function c(){},
  d: undefined
}

前面我们也有提到，进入执行期之后，会执行赋值语句进行赋值，此时变量b和d会被赋值为 2 和函数表达式：

AO = {
   arguments: {
    0: 1,
    length: 1
  },
  a: 1,
  b: 2,
  c: reference to function c(){},
  d: reference to FunctionExpression "d"
}

这就是 VO -> AO 过程。

在定义期（编译阶段）：该对象值仍为undefined，且处于不可访问的状态。
进入执行期（执行阶段）：VO 被激活，其中变量属性会进行赋值。

实际上在执行的时候，除了 VO 被激活，活动对象还会添加函数执行时传入的参数和arguments这个特殊对象，因此 AO 和 VO 的关系可以用以下关系来表达：

AO = VO + function parameters + arguments

虽然 JavaScript 代码的运行过程可以分为语法分析阶段、编译阶段和执行阶段，但由于在 JavaScript 引擎中是通过调用栈的方式来执行 JavaScript 代码的（下一讲会介绍），因此并不存在“整个 JavaScript 运行过程只会在某个阶段中”这一说法，比如上面例子中bar函数的编译阶段，其实是在foo函数的执行阶段中。

一般来说，当函数执行结束之后，执行期上下文将被销毁（作用域链和活动对象均被销毁）。但有时候我们想要保留其中一些变量对象，不想被销毁，此时就会使用到闭包。

我们已经知道，通过作用域链，我们可以在函数内部可以直接读取外部以及全局变量，但外部环境是无法访问内部函数里的变量。比如下面的例子中，foo函数中定义了变量a：

function foo() {
  var a = 1;
}
foo();
console.log(a); // undefined

我们在全局环境下无法访问函数foo中的变量a，这是因为全局函数的作用域链里，不含有函数foo内的作用域。

如果我们想要访问内部函数的变量，可以通过函数foo中的函数bar返回变量a，并将函数bar返回，这样我们在全局环境中也可以通过调用函数foo返回的函数bar，来访问变量a：

function foo() {
  var a = 1;
  function bar() {
    return a;
  }
  return bar;
}
var b = foo();
console.log(b()); // 1

前面我们说到，当函数执行结束之后，执行期上下文将被销毁，其中包括作用域链和激活对象。那么，在这个例子中，当b()执行时，foo函数上下文包括作用域都已经被销毁了，为什么foo作用域下的a依然可以被访问到呢？

这是因为bar函数引用了foo函数变量对象中的值，此时即使创建bar函数的foo函数执行上下文被销毁了，但它的变量对象依然会保留在 JavaScript 内存中，bar函数依然可以通过bar函数的作用域链找到它，并进行访问。这便是我们常说的闭包，即使创建它的上下文已经销毁，它仍然被保留在内存中。

闭包使得我们可以从外部读取局部变量，在大多数项目中都会被使用到，常见的用途包括：

用于从外部读取其他函数内部变量的函数；
可以使用闭包来模拟私有方法；
让这些变量的值始终保持在内存中。

需要注意的是，我们在使用闭包的时候，需要及时清理不再使用到的变量，否则可能导致内存泄漏问题。

相信大家现在已经掌握了作用域链的建立过程，那么作用域链的用途想必大家也已经了解，比如在函数执行过程中变量的解析：

从当前词法环境开始，沿着作用域链逐级向外层寻找环境记录，直到找到同名变量为止；
找到后不再继续遍历，找不到就报错。

下面我们继续来看，执行上下文的创建过程中还会做的一件事：确定this的指向。

# 确定 this 的指向

在 JavaScript 中，this指向执行当前代码对象的所有者，可简单理解为this指向最后调用当前代码的那个对象。相信大家都很熟悉this，因此这里我就进行结论性的简单总结。

根据 JavaScript 中函数的调用方式不同，this的指向分为以下情况。

可以看到，this在不同的情况下会有不同的指向，在 ES6 箭头函数还没出现之前，为了能正确获取某个运行环境下this对象，我们常常会使用var that = this;、var self = this;这样的代码将变量分配给this，便于使用。这种方式降低了代码可读性，因此如今这种做法不再被提倡，通过正确使用箭头函数，我们可以更好地管理作用域。

# 小结

今天我主要介绍了 JavaScript 代码的运行过程，该过程分为语法分析阶段、编译阶段、执行阶段三个阶段。

在编译阶段，JavaScript会进行执行上下文的创建，包括：

创建变量对象，进行变量声明和函数声明，此时会产生变量提升和函数提升；
通过添加对外部词法环境的引用，建立作用域链，通过作用域链可以访问外部的变量对象；
确定 this 的指向。

在执行阶段，变量对象（VO）会被激活为活动对象（AO），变量会进行赋值，此时活动对象才可被访问。在执行结束之后，作用域链和活动对象均被销毁，使用闭包可使活动对象依然被保留在内存中。这就是 JavaScript 代码的运行过程。

+ vo里面有a b变量，a可以通过闭包被外界访问，b没有，当前作用域执行完后，整个vo都被保留，还是只保留a这块内存？
+ 讲师回复： 当函数执行结束之后，执行期上下文将被销毁，其中包括作用域链和激活对象。对于闭包的场景来说，函数执行结束后，
执行上下文的作用域链会被销毁，但它的激活对象仍然会被保留在内测中，这里是整个激活对象都会被保存。 
因为闭包会保留锁包含函数的作用域，所以会比其他函数更占用内存。

链接 (opens new window)

← cookie和session iframe →