JavaScript中的执行上下文和堆栈

淩亂°似流年 2021-09-20 05:50 378阅读 0赞

在这篇文章中，我将深入探讨JavaScript的最基本部分之一，即`Execution Context`(执行上下文)。 在本文结束时，你应该对解释器了解得更清楚：为什么在声明它们之前可以使用某些函数或变量？以及它们的值是如何确定的？

## **什么是执行上下文？** ##

JavaScript的执行环境非常重要，当JavaScript代码在行时，会被预处理为以下情况之一：

*  **Global code**\- 首次执行代码的默认环境。
 *  **Function code**\- 每当执行流程进入函数体时。
 *  **Eval code**\- 要在eval函数内执行的文本。

你可以阅读大量涉及`作用域`的在线资料，不过为了使事情更容易理解，让我们将术语`“执行上下文”`视为当前代码的运行环境或作用域。接下来让我们看一个包含global和function / local上下文的代码示例。

![v2-c15b6d55e5d9f398e14f3a38267b19f8_hd.jpg][]

img

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

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

## **Execution Context Stack（执行上下文堆栈）** ##

浏览器中的JavaScript解释器被实现为单个线程。 实际上这意味着在浏览器中一次只能做一件事，其他动作或事件在所谓的执行堆栈中排队。 下图是单线程堆栈的抽象视图：

![v2-5b712c0d03841248193cd9fa44b23592_hd.jpg][]

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

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

![v2-81d5ee76c0af6612f4c03bdedde2e64c_hd.jpg][]

![v2-73a188376ff90f7de432bb86e815f2e6_b.jpg][]

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

**关于执行堆栈`execution stack`有5个关键要点：**

*  单线程。
 *  同步执行。
 *  一个全局上下文。
 *  任意多个函数上下文。
 *  每个函数调用都会创建一个新的执行上下文`execution context`，甚至是对自身的调用。

## **执行上下文的细节** ##

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

1.  创建阶段 \[调用函数时，但在执行任何代码之前\]：

*  创建`作用域链`。
 *  创建变量，函数和参数。
 *  确定`“this”`的值。

1.  激活/代码执行阶段：

*  分配值，引用函数和解释/执行代码。

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

![v2-b61f5c764524029fe7f8fc255fed911e_hd.jpg][]

## **激活对象/变量对象 \[AO/VO\]** ##

在调用该函数，并且在实际执行函数之前，会创建这个`executionContextObj`。 这被称为第1阶段，即`创造阶段`。 这时解释器通过扫描函数传递的实参或形参、本地函数声明和局部变量声明来创建`executionContextObj`。 此扫描的结果将成为`executionContextObj`中的`variableObject`。

**以下是解释器如何预处理代码的伪代码概述：**

1.  找一些代码来调用一个函数。
2.  在执行功能代码之前，创建`执行上下文`。
3.  进入创建阶段：

*  初始化作用域链。
 *  创建`variable object`：
    
     *  对于找到的每个变量声明，在\`variable object\`中创建一个属性作为变量名称，并将该值初始化为\`undefined\`。
     *  如果变量名称已存在于\`variable object\`中，则不执行任何操作并继续扫描。
     *  对于找到的每个函数，在\`variable object\`中创建一个属性，该属性是函数的确切名称，该属性存在指向内存中函数的引用指针。
     *  如果函数名已存在，则将覆盖引用指针值。
     *  创建\`arguments object\`，检查参数的上下文，初始化名称和值并创建引用副本。
     *  扫描上下文以获取函数声明：
     *  扫描上下文以获取变量声明：
 *  确定上下文中`“this”`的值。

1.  激活/执行阶段：

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

我们来看一个例子：

![v2-65d3d220e8ed83ce988711ac7a8ef979_hd.jpg][]

在调用`foo(22)`时，`创建阶段`如下所示：

![v2-7b4ca0f3c71ebcbabd9c45ec893f970e_hd.jpg][]

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

![v2-8bf4d6c170d208e7d6d3899b24b9bad0_hd.jpg][]

## **关于hoisting** ##

你可以找到许多使用JavaScript定义术语`hoisting`的在线资源，解释变量和函数声明被hoisting到其函数范围的顶部。 但是没有人能够详细解释为什么会发生这种情况，掌握了关于解释器如何创建`激活对象`的新知识，很容易理解为什么。 请看下面的代码示例：

![v2-2d2ed2129a2fe0daaf0edd1fc7d64dd6_hd.jpg][]

我们现在可以回答的问题是：

*  **为什么我们可以在声明foo之前就能访问？**
 *  如果我们理解了`创建阶段`，就知道在`激活/代码执行`阶段之前已经创建了变量。因此，当函数流开始执行时，已经在激活对象中定义了foo。
 *  **Foo被声明两次，为什么foo显示为\`function\`而不是\`undefined\`或\`string\`？**
 *  即使`foo`被声明两次，我们通过`创建阶段`知道函数在变量之前就被创建在`激活对象`上了，而且如果`激活对象`上已经存在了属性名称，我们只是绕过了声明这一步骤。
 *  因此，首先在`激活对象`上创建对函数`foo()`的引用，并且当解释器到达`var foo`时，我们已经看到属性名称`foo`存在，因此代码不执行任何操作并继续处理。
 *  为什么`bar`未定义？
 *  `bar`实际上是一个具有函数赋值的变量，我们知道变量是在`创建阶段`被创建的，但它们是使用`undefined`值初始化的。

## **总结** ##

希望到这里你已经能够很好地掌握了JavaScript解释器如何预处理你的代码。 理解执行上下文和堆栈可以让你了解背后的原因：为什么代码预处理后的值和你预期的不一样。

你认为学习解释器的内部工作原理是多此一举还是非常必要的呢？ 了解执行上下文阶段是否能够帮你你写出更好的JavaScript呢？

## **进一步阅读** ##

*  ECMA-262 5th Edition ([http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-262.pdf][http_www.ecma-international.org_publications_files_ECMA-ST_ECMA-262.pdf])
 *  ECMA-262-3 in detail. Chapter 2. Variable object ([http://dmitrysoshnikov.com/ecmascript/chapter-2-variable-object/][http_dmitrysoshnikov.com_ecmascript_chapter-2-variable-object])
 *  Identifier Resolution, Execution Contexts and scope chains ([http://jibbering.com/faq/notes/closures/\#clIRExSc][http_jibbering.com_faq_notes_closures_clIRExSc])

[v2-c15b6d55e5d9f398e14f3a38267b19f8_hd.jpg]: /images/20210812/b478a6e3fa744948bf679910bd9db88d.png
[v2-5b712c0d03841248193cd9fa44b23592_hd.jpg]: /images/20210812/0e263eac63694624883f7116d1a2ff3f.png
[v2-81d5ee76c0af6612f4c03bdedde2e64c_hd.jpg]: /images/20210812/0aa0f7deb57747d8b51b32ed1ec0b9fc.png
[v2-73a188376ff90f7de432bb86e815f2e6_b.jpg]: /images/20210812/f98e13108aa146498e0347f24292e9d8.png
[v2-b61f5c764524029fe7f8fc255fed911e_hd.jpg]: /images/20210812/fd591fab120a4659855d4cfdd50a73ee.png
[v2-65d3d220e8ed83ce988711ac7a8ef979_hd.jpg]: /images/20210812/fd1a0d78a2be4c558ebc5e4b75673321.png
[v2-7b4ca0f3c71ebcbabd9c45ec893f970e_hd.jpg]: /images/20210812/577af74bb1b74aacb0a5ec378a14b52f.png
[v2-8bf4d6c170d208e7d6d3899b24b9bad0_hd.jpg]: /images/20210812/d93af9f1aff0409ea2a5999c5cc402ce.png
[v2-2d2ed2129a2fe0daaf0edd1fc7d64dd6_hd.jpg]: /images/20210812/706e4326a4b54b4fae52ef01592a4d92.png
[http_www.ecma-international.org_publications_files_ECMA-ST_ECMA-262.pdf]: https://link.zhihu.com/?target=http%3A//www.ecma-international.org/publications/files/ECMA-ST/ECMA-262.pdf
[http_dmitrysoshnikov.com_ecmascript_chapter-2-variable-object]: https://link.zhihu.com/?target=http%3A//dmitrysoshnikov.com/ecmascript/chapter-2-variable-object/
[http_jibbering.com_faq_notes_closures_clIRExSc]: https://link.zhihu.com/?target=http%3A//jibbering.com/faq/notes/closures/%23clIRExSc