详解JavaScript 论代码执行上下文

导读

本片文章，在前人的基础上，加上自己的理解，解释一下JavaScript的代码执行过程，顺道介绍一下执行环境和闭包的相关概念。

分为两部分。第一部分是了解执行环境的相关概念，第二部分是通过实际代码了解具体执行过程中执行环境的切换。

执行环境

执行环境的分类

  • 1.全局执行环境
    是JS代码开始运行时的默认环境（浏览器中为window对象）。全局执行环境的变量对象始终都是作用域链中的最后一个对象。
  • 2.函数执行环境
    当某个函数被调用时，会先创建一个执行环境及相应的作用域链。然后使用arguments和其他命名参数的值来初始化执行环境的变量对象。
  • 3.使用eval()执行代码

没有块级作用域（本文不涉及ES6中let等概念）

执行上下文（执行环境）的组成

执行环境（execution context，EC）或称之为执行上下文，是JS中一个极为重要的概念。当JavaScript代码执行时，会进入不同的执行上下文，而每个执行上下文的组成，基本如下：

image
  • 变量对象（Variable object，VO）: 变量对象，即包含变量的对象，除了我们无法访问它外，和普通对象没什么区别
  • [[Scope]]属性:数组。作用域链是一个由变量对象组成的带头结点的单向链表，其主要作用就是用来进行变量查找。而[[Scope]]属性是一个指向这个链表头节点的指针。
  • this: 指向一个环境对象，注意是一个对象，而且是一个普通对象，而不是一个执行环境。

若干执行上下文会构成一个执行上下文栈（Execution context stack，ECS）。而所谓的执行上下文栈，举个例子，比如下面的代码

var a = "global var";

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

function outerFunc(){
    var b = "var in outerFunc";
    console.log(b);

    function innerFunc(){
        var c = "var in innerFunc";
        console.log(c);
        foo();
    }

    innerFunc();
}

outerFunc()

代码首先进入Global Execution Context，然后依次进入outerFunc，innerFunc和foo的执行上下文，执行上下文栈就可以表示为：

image

执行全局代码时，会产生一个执行上下文环境，每次调用函数都又会产生执行上下文环境。当函数调用完成时，这个上下文环境以及其中的数据都会被消除，再重新回到全局上下文环境。处于活动状态的执行上下文环境只有一个。

image

产生执行上下文的两个阶段

当一段JS代码执行的时候，JS解释器会通过两个阶段去产生一个EC

  • 创建阶段（当函数被调用，但是开始执行函数内部代码之前）
    • 创建变量对象VO
    • 设置[[Scope]]属性的值
    • 设置this的值
    • 激活/代码执行阶段
  • 初始化变量对象，即设置变量的值、函数的引用，然后解释/执行代码。

创建变量对象VO过程

  • 1.根据函数的参数，创建并初始化arguments object
  • 2.扫描函数内部代码，查找函数声明（function declaration）
    • 对于所有找到的函数声明，将函数名和函数引用存入VO中
    • 如果VO中已经有同名函数，那么就进行覆盖
  • 3.扫描函数内部代码，查找变量声明（Variable declaration）
    • 对于所有找到的变量声明(通过var声明)，将变量名存入VO中，并初始化为undefined
    • 如果变量名跟已经声明的形参或函数相同，则什么也不做

注：步骤2和3也称为声明提升（declaration hoisting）

通过一段代码来了解JavaScript代码的执行

我们举例说明，假如我们有一个js文件，内容如下：

var  global_var1 = 10;
function  global_function1(parameter_a){
    var  local_var1 = 10 ;
    return  local_var1 + parameter_a + global_var1;
}
var global_sum = global_function1(10);
alert(global_sum);

下面我们来一步一步说明解释器是如何执行这段代码的：

1.创建全局上下文

首先，在解释器眼中，global_var1、global_sum叫做全局变量，因为它们不属于任何函数。local_var1叫做局部变量，因为它定义在函数global_function1内部。global_function1叫做全局函数，因为它没有定义在任何函数内部。

然后，解释器开始扫描这段代码，为执行这段代码做了一些准备工作——创建了一个全局上下文。

全局上下文，可以把它看成一个JavaScript对象，姑且称之为global_context。这个对象是解释器创建的，当然也是由解释器使用。（我们的JavaScript代码是接触不到这个对象的）

global_context对象大概是这个样子的：

global_context = {
       Variable_Object :{......},
       Scope           :[......],
       this            :{......}
}

可以看到，global_context有三个属性

  • Variable_Object（以下简称VO）
    {
    global_var1：undefined
    global_function1：函数 global_function1的地址
    global_sum：undefined
    }

    解释器在VO中记录了变量全局变量global_var1、global_sum，但它们的值现在是undefined的，还记录了全局函数global_function1，但是没有记录局部变量local_var1。VO的原型是Object.prototype。

  • Scope数组中的内容如下：

      [     global_context.Variable_Object     ]

    我们看到，Scope数组中只有一个对象，就是前面刚创建的对象VO。

  • this

    this的值现在是undefined

global_context对象被解释器压入一个栈中，不妨叫这个栈为context_stack。现在的context_stack是这样的：

image

创建出global_context后，解释器又偷偷摸摸干了一件事，它给global_function1设置了一个内部属性，也叫scope，它的值就是global_context中的scope！也就是说，现在:

global_function1.scope === [  global_context.Variable_Object   ];

我们获取不到global_function1的scope属性的，只有解释器自己能获取到。

2.逐行执行代码

解释器在创建了全局上下文后，就开始执行这段代码了。

第一句：

var  global_var1 = 10;

解释器会把VO中的global_var1属性的值设为10。现在global_context对象变成了这样：

global_context = {
       Variable_Object :{ 
               global_var1：10,
               global_function1：函数 global_function1的地址,
               global_sum：undefined
        },
        Scope          :[ global_context.Variable_Object ],
        this           :undefined
}

第二句：

解释器继续执行我们的代码，它碰到了声明式函数global_function1，由于在创建global_context对象时，它就已经记录好了该函数，所以现在它什么也不用做。

第三句：

var global_sum = global_function1(10);

解释器看到，我们在这里调用了函数global_function1(解释器已经提前在global_context的VO中记录下了global_function1，所以它知道我们这里是一个函数调用)，并且传入了一个参数10，函数的返回结果赋值给了全局变量global_sum。

解释器并没有立即执行函数中的代码，因为它要为函数global_function1创建一个专门的context，我们叫它执行上下文（execute_context）吧，因为每当解释器要执行一个函数时，都会创建一个类似的context。

execute_context也是一个对象，并且与global_context还很像，下面是它里面的内容：

execute_context = {
       Variable_Object :{ 
               parameter_a：10,
               local_var1：undefined,
               arguments：[10]              
        },
        Scope          :[execute_context.Variable_Object, global_context.Variable_Object ],
        this           :undefined
}

我们看到，execute_context与global_context相比，有以下几点变化：

  • VO
    • 首先记录了函数的形式参数parameter_a，并且给它赋值10，这个10就是我们调用函数时传递进去的。
    • 然后记录了函数体内的局部变量local_var1，它的值还是undefined。
    • 然后是一个arguments属性，它的值是一个数组，里面只有一个10。

你可能疑惑，不是已经在parameter_a中记录了参数10了吗，为什么解释器还要搞一个arguments，再来记录一遍呢？原因是如果我们这样调用函数：

global_function1(10,20,30);

在JavaScript中是不违法的。此时VO中的arguments会变成这样：

arguments:[10,20,30]

parameter_a的值还是10。可见，arguments是专门记录我们传进去的所有参数的。

  • Scope

Scope属性仍然是一个数组，只不过里面的元素多了个execute_context.Variable_Object，并且排在了global_context.Variable_Object前面。

解释器是根据什么规则决定Scope中的内容的呢？答案非常简单：

execute_context.Scope = execute_context.Variable_Object + global_function1.scope。

也就是说，每当要执行一个函数时，解释器都会将执行上下文（execute_context）中Scope数组的第一个元素设为该执行上下文（execute_context）的VO对象，然后取出函数创建时保存在函数中的scope属性（本文中则是global_function1.scope），将其添加到执行上下文（execute_context）Scope数组的后面。

我们知道，global_function1是在global_context下创建的，创建的时候，它的scope属性被设置成了global_context的Scope，里面只有一个global_context.Variable_Object，于是这个对象被添加到execute_context.Scope数组中execute_context.Variable_Object对象后面。

任何一个函数在创建时，解释器都会把它所在的执行上下文或者全局上下文的Scope属性对应的数组设置给函数的scope属性，这个属性是函数“与生俱来”的。

  • this
    this的值此时仍然是undefined的(但不同的解释器可能有不同的赋值)

解释器为函数global_function1创建好了execute_context（执行上下文）后，会把这个上下文对象压入context_stack中，所以，现在的context_stack是这样的：

image

准备执行函数内的代码

做好了准备工作，解释器开始执行函数里面的代码了，此时我们称函数是在执行上下文中运行的。

第一句

var  local_var1 = 10 ;

它的处理办法很简单，将execute_context的VO中的local_var1赋值为10。这一点与在global_context下执行的变量赋值语句的处理一样。此时的execute_context变成这样：

execute_context = {
       Variable_Object :{ 
               parameter_a：10,
               local_var1：10,                      //为local_var1赋值10
               arguments：[10]              
        },
        Scope          :[execute_context.Variable_Object, global_context.Variable_Object ],
        this           :undefined
}

第二句

return local_var1 + parameter_a + global_var1;
  • 解释器进一步考察语句，发现这是一个返回语句，于是它开始计算return 后面的表达式的值。
  • 在表达式中它首先碰到了变量local_var1，它首先在execute_context的Scope中依次查找，在第一个元素execute_context的VO发现了local_var1，并且知道它的值是10
  • 然后解释器继续前进，碰到了变量parameter_a，它如法炮制，在execute_context的VO中发现了parameter_a，并且确定它的值是10。
  • 接着发现 global_var1，解释器从execute_context的Scope第一个元素execute_context.VO中查找，没有发现global_var1。继续查看Scope数组的第二个元素，即global_context.VO，发现并且确定了它的值为10。
  • 于是，解释器将三个变量值相加得到了30，然后就返回了。
  • 此时，解释器知道函数已经执行完了，那么它为这个函数创建的执行上下文也没有用了，于是，它将execute_context从context_stack中弹出，由于没有其他对象引用着execute_context，解释器就把它销毁了。现在context_stack中又只剩下了global_context。

第三句

var global_sum = 30;

现在解释器又回到全局上下文中执行代码了，这时它要把30赋值给sum，方法就是更改global_context中的VO对象的global_sum属性的值。

第四句

alert(global_sum);

解释器继续前进，碰到了语句alert(global_sum);很简单，就是发出一个弹窗，弹窗的内容就是global_sum的值30，当我们点击弹窗上的确定按钮后，解释器知道，这段代码终于执行完了，它会打扫战场，把global_context，context_stack等资源全部销毁。

再遇闭包

现在，知道了上下文，函数的scope属性的知识后，我们就可以开始学习闭包了。让我们将上面的js代码改成这样：

var  global_var1 = 10;
function  global_function1(parameter_a){
    var  local_var1 = 10 ;
   function local_function1(parameter_b){
        return parameter_b  + local_var1 + parameter_a + global_var1;
   }
   return   local_function1 ;
}
var global_sum = global_function1(10);
alert(global_sum(10));

这段代码与原先的代码最大的不同是，在global_function1内部，我们创建了一个函数local_function1，并且将它作为返回值。

当解释器执行函数global_function1时，仍然会为它创建执行上下文，只不过此时execute_context.VO中多了一个函数属性local_function1。然后，解释器就会开始执行global_function1中的代码。

我们直接从创建local_function1语句开始分析，看解释器是怎么执行的，闭包的所有秘密就隐藏在其中。

当解释器在execute_context中执行创建local_function1时，它仍然会将execute_context的Scope设置给函数local_function1的scope属性，也就是这样：

local_function1.scope = [ execute_context.Variable_Object,   global_context.Variable_Object ]

然后，解释器碰到了返回语句，把local_function1返回并赋值给了全局变量global_sum。此时global_context的VO中global_sum的值就是函数local_function1。

此时，函数global_function1已经执行完了，解释器会怎么处理它的execute_context呢？

首先，解释器会把execute_context从context_stack中弹出，但并不把它完全销毁，而是保留了execute_context.Variable_Object对象，把它转移到了另一块堆内存中。为什么不销毁呢？因为还有对象引用着它呢。引用链如下：

image

这意味着什么呢？这说明，当global_function1结束返回后，它的形式参数parameter_a，局部变量local_var1以及局部函数local_function1都没有销毁，还仍然存在。这一点，与面向对象的语言Java中的经验完全不同，这也是闭包难以理解的根本所在。

下面我们的解释器继续执行语句alert(global_sum(10));alert参数是对函数global_sum的调用，global_sum的参数为10，我们知道函数global_sum的代码是这样的：

function local_function1(parameter_b){
    return parameter_b  + local_var1 + parameter_a + global_var1;
}

要执行这个函数，解释器仍然会为它创建一个执行上下文，我们姑且称之为local_context2，这个对象的内容是这样的：

execute_context2 = {
   Variable_Object :{ 
           parameter_b：10,
           arguments：[10]              
    },
    Scope          :[execute_context2.Variable_Object, execute_context.Variable_Object, global_context.Variable_Object ],
    this           :undefined
}

这里我们重点看看Scope属性，它的第一个元素毫无疑问是execute_context2.Variable_Object，后面的元素是从local_function1.scope属性中获得的，它是在local_function1创建时所在的执行上下文的Scope属性决定的。

创建的execute_context2压入context_stack后，解释器开始执行语句

return parameter_b  + local_var1 + parameter_a + global_var1;

对于该句中四个变量，解释器确定它们的值的办法一如既往的简单，首先在当前执行上下文（也就是execute_context2）的Scope的第一个元素中查找，第一个找不到就在第二个元素中查找，然后就是第三个，直至global_context.Variable_Object。

然后，解释器就会将四个变量值相加后返回。弹出execute_context2，此时execute_context2已经没有对象引用着它，解释器就把它销毁了。

最后，alert函数会收到值40，然后发出一个弹窗，弹窗的内容就是40。程序结束

说到现在，啥是闭包啊？

简单讲，当我们从函数global_function1中返回另一个函数local_function1时，由于local_function1的scope属性中引用着为执行global_function1创建的execute_context.Variable_Object对象，导致global_function1在执行完毕后，它的execute_context.Variable_Object对象并不会被回收，此时我们称函数local_function1是一个闭包，因为它除了是一个函数外，还保存着创建它的执行上下文的变量信息，使得我们在调用它时，仍然能够访问这些变量。

函数将创建它的上下文中的VO对象封闭包含在自己的scope属性中，函数就变成了一个闭包。从这个广泛的意义上来说，global_function1也可以叫做闭包，因为它的scope内部属性也包含了创建它的全局上下文的变量信息，也就是global_context.VO

最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 203,098评论 5赞 476
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 85,213评论 2赞 380
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 149,960评论 0赞 336
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 54,519评论 1赞 273
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 63,512评论 5赞 364
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 48,533评论 1赞 281
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 37,914评论 3赞 395
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 36,574评论 0赞 256
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 40,804评论 1赞 296
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,563评论 2赞 319
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,644评论 1赞 329
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 33,350评论 4赞 318
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 38,933评论 3赞 307
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,908评论 0赞 19
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,146评论 1赞 259
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 42,847评论 2赞 349
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 42,361评论 2赞 342