My-Note-Blog JS引擎的工作原理

JS引擎的工作原理

Open huangchucai opened this issue 6 years ago • 0 comments

JS引擎的工作原理

执行原理

从一个函数的定义到函数的执行，JS引擎会进行一些初始化的工作，下面我们通过一个例子来说明，JS引擎的一些工作

var x = 1 //定义一个全局变量
function A(y) {
    var x = 2; // 定义一个局部变量
    function B(z) { // 定义一个内部函数B
        console.log(x+y+z);
    }
    return B; // 返回函数B的引用
}
var C = A(1); // 执行A,返回B，并分发给C
C(1); // 执行函数B 输出4

下面主要通过执行前(全局初始化)， 执行函数A，执行函数B来分析JS引擎的工作

1、执行前（全局初始化）

JavaScript引擎执行一段可执行的代码时，JS引擎会做一些底层的初始化工作：

首先，创建一个全局的对象（Global Object）,这个对象全局只存在一份，它的属性全局都可以访问，伴随整个生命周期，全局对象在创建的时候，将一些常用的JS对象作为属性（Math，String，Date, document）,由于这个全局对象不能通过名字直接访问，因此还有另外一个属性window,并将window指向了自身，这样就可以通过window访问这个全局对象了。用伪代码模拟全局对象的大体结构如下：
```
// 创建一个全局对象
var globalObject = {
    Math: {},
    String: {},
    Date: {},
    document: {} // DOM操作
    ...
    window: this // 让window属性指向了自身
}
```
然后，JS引擎需要构建一个执行环境栈（Execution Context Stack）, 与此同时，也要创建一个全局执行环境（Execution Context）EC ，并将这个全局环境EC压入执行环境栈中，执行环境栈的作用是为了保证程序能够按照正确的顺序被执行。在javascript中，每个函数都有自己的执行环境，当执行一个函数时，该函数的执行环境就会被推入执行环境栈的顶部并获取执行权。当这个函数执行完毕，它的执行环境又从这个栈的顶部被删除，并把执行权并还给之前执行环境。我们用伪代码来模拟执行环境栈和EC的关系：
```
var ECStack = []; //定义一个执行环境栈，类似于数组
var EC = {}; // 创建一个执行空间

ECStack.push(EC); // 进入函数，压入执行环境
ECStack.shift(); // 函数返回后，删除执行环境
```
最后，JS引擎还要创建一个与EC关联的全局变量对象(Varibale Object) VO, 并把VO指向全局对象，VO中不仅包含了全局对象的原有属性，还包括在全局定义的变量x 和函数 A，与此同时，在定义函数A的时候，还为 A 添加了一个内部属性scope，并将scope指向了VO。每个函数在定义的时候，都会创建一个与之关联的scope属性，scope总是指向定义函数时所在的环境。此时的ECStack结构如下：
```
ECStack = [
    EC(G) = {  // 全局执行环境
        VO(G): { //定义全局变量对象
        	... //包含全局对象原有的属性globalObject
        	x = 1; //定义全局变量x
        	A = function() {...}; //定义函数A
			A[[scope]] = VO(G) // 定义A的scope，并赋值为VO(G)本身
    	}
    }
]
```

2. 执行函数A

当执行进入A(1) 时，JS引擎需要完成以下工作：

首先，JS引擎会创建函数A的执行环境EC，然后EC推入执行环境栈的顶部并获取执行权。此时执行环境栈中有两个执行环境，分别是全局执行环境和函数A执行环境，A的执行环境在栈顶，全局执行环境在栈的底部。然后，创建函数A的作用域链(Scope Chain) ，在javascript中，每个执行环境都有自己的作用域链，用于标识符解析，当执行环境被创建时，它的作用域链就初始化为当前运行函数的scope所包含的对象。

接着，JS引擎会创建一个当前函数的活动对象(Activation Object) AO，这里的活动对象扮演着变量对象的角色，只是在函数中的叫法不同而已（你可以认为变量对象是一个总的概念，而活动对象是它的一个分支）， AO中包含了函数的形参、arguments对象、this对象、以及局部变量和内部函数的定义，然后AO会被推入作用域链的顶端。需要注意的是，在定义函数B的时候，JS引擎同样也会为B添加了一个scope属性,并将scope指向了定义函数B时所在的环境，定义函数B的环境就是A的活动对象AO，而AO位于链表的前端，由于链表具有首尾相连的特点，因此函数B的scope指向了A的整个作用域链。我们再看看此时的ECStack结构：

ECStack = [ //执行环境栈
    EC(A) = { //A的执行环境
        [[scope]]: VO(G), //VO是全局变量对象
        VO(A): {
        	y: 1,
            x: 2, //
            B = function(){...} // 定义函数B
    		B[[scope]] = VO(A), // 而AO位于scopeChain的顶端，因此B[[scope]]指向整个作用域链
           arguments:[],//平时我们在函数中访问的arguments就是AO中的arguments 
           this = window; //函数中的this指向调用者window对象     
        }
        scopeChain: <AO(A), A[[scope]]> //链表初始化为A[[scope]],然后再把AO加入该作用域链的顶端,此时A的作用域链：AO(A)->VO(G)
    },
    EC(G) = {   //全局执行环境
        VO(G):{ //创建全局变量对象
            ... //包含全局对象原有的属性
            x = 1; //定义变量x
            A = function(){...}; //定义函数A
            A[[scope]] = VO(G); //定义A的scope，A[[scope]] == VO(G)
        }
    }

]

3. 执行函数B

函数A被执行以后，返回了B的引用，并赋值给了变量C，执行 C(1) 就相当于执行B(1)，JS引擎需要完成以下工作：

首先，还和上面一样，创建函数B的执行环境EC，然后EC推入执行环境栈的顶部并获取执行权。此时执行环境栈中有两个执行环境，分别是全局执行环境和函数B的执行环境，B的执行环境在栈顶，全局执行环境在栈的底部。（注意：当函数A返回后，A的执行环境就会从栈中被删除，只留下全局执行环境）然后，创建函数B的作用域链，并初始化为函数B的scope所包含的对象，即包含了A的作用域链。最后，创建函数B的活动对象AO,并将B的形参z, arguments对象和 this对象作为AO的属性。此时ECStack将会变成这样：

ECStack = [   //执行环境栈
    EC(B) = {   //创建B的执行环境,并处于作用域链的顶端
        [scope]:AO(A), //指向函数A的作用域链,AO(A)->VO(G)
        var AO(B) = { //创建函数B的活动对象
            z:1,
            arguments:[],
            this:window
        }
        scopeChain:<AO(B),B[[scope]]>  //链表初始化为B[[scope]],再将AO(B)加入链表表头，此时B的作用域链：AO(B)->AO(A)-VO(G)
    },
    EC(A), //A的执行环境已经从栈顶被删除,
    EC(G) = {   //全局执行环境
        VO:{ //定义全局变量对象
            ... //包含全局对象原有的属性
            x = 1; //定义变量x
            A = function(){...}; //定义函数A
            A[[scope]] = this; //定义A的scope，A[[scope]] == VO(G)
        }
    }
];

当函数B执行“x+y+z”时，需要对x、y、z 三个标识符进行一一解析，解析过程遵守变量查找规则：先查找自己的活动对象中是否存在该属性，如果存在，则停止查找并返回；如果不存在，继续沿着其作用域链从顶端依次查找，直到找到为止，如果整个作用域链上都未找到该变量，则返回“undefined”。从上面的分析可以看出函数B的作用域链是这样的：

AO(B)->AO(A)->VO(G)

因此，变量x会在AO(A)中被找到，而不会查找VO(G)中的x，变量y也会在AO(A)中被找到，变量z 在自身的AO(B)中就找到了。所以执行结果：2+1+1=4.

4. 思考

当我们执行函数B的时候，明明A在执行完成后，A的执行环境已经被删除了，但是为什么还是可以访问到A的数据呢？

这里要额外的提一下一些基本的概念：

内存什么时候会被回收
JS的垃圾回收机制

JS的垃圾回收机制

引用计数：（已经被弃用）
- 含义：根据内存地址是否再被引用来判定是否应该被删除
- 缺点：有些循环应用的的无法被清除，导致内存泄露
标记清除：
- 含义：垃圾回收期定期从根部（js的全局对象）开始寻找，找所有从根开始引用的对象，然后找找这些对象引用的对象…….从根开始，垃圾回收器将找到所有可以获得的对象和收集所有不能获得的对象。

分析

当执行完A函数的时候，A的执行栈被释放，但是内存并没有被释放（这里就引发了内存泄露），因为标记清除发现函数A的内存被函数B的作用域链引用scopeChain:<AO(B),AO(A)>, 但是函数B还没有执行，所以并不会释放A的内存。
当执行到函数B的时候，由于作用域链的关系，我们可以访问到A中的活动对象的内存，所以可以当执行栈被剔除后，并不代表内存已经被释放

这也就是常说的，闭包会引发内存的泄露

// 测试闭包引发的内存泄露
var a = null;
var f = 0;
function b() {
    var c = a
    var d = function() {
        console.log(c)
    }
    a = {
        e: d,
        z: new Array(1e7).join('*'),
        f:f++
    }

    // 释放闭包中的变量
    // c = null
}

5. 延伸

展示代码

var x = 1;
function A() {
    var x = 2;
    console.log(x)
}
function B() {
    var x = 3;
    console.log(x)
}
A()
B()

执行前（内存图分析）

ECStack = [
    EC(G): {
    	VO(G): {
            ... // 包含全局对象原有的属性
    		x = 1,
    		A = function() {....},
            A[[scope]] = VO(G),
            B = function() {...},
            B[[scope]] = VO(G)    
		} 
    }
]

执行函数A

ECStack = [
    EC(A): {
    	AO(A): {
            x = 2,
            arguments: []    
            this: window
		}
		scopeChain: <EC(A), EC(g)>
    }
    EC(G): {
    	VO(G): {
            ... // 包含全局对象原有的属性
    		x = 1,
    		A = function() {....},
            A[[scope]] = VO(G),
            B = function() {...},
            B[[scope]] = VO(G)    
		} 
    }
]

当执行完A后，A的执行环境从执行栈中释放，标记清除启动是，从全局对象开始查看，发现了A的引用，继续查看函数A是否被其他对象引用，没有发现被其他内存引用，就会释放对应的空间。

参考链接

内存清除 js引擎

Feb 26 '19 12:02 huangchucai

My-Note-Blog
My-Note-Blog copied to clipboard

JS引擎的工作原理

JS引擎的工作原理

相关知识点

执行原理

1、执行前（全局初始化）

2. 执行函数A

3. 执行函数B

4. 思考

JS的垃圾回收机制

分析

5. 延伸

参考链接

My-Note-Blog My-Note-Blog copied to clipboard

JS引擎的工作原理

JS引擎的工作原理

相关知识点

执行原理

1、执行前（全局初始化）

2. 执行函数A

3. 执行函数B

4. 思考

JS的垃圾回收机制

分析

5. 延伸

参考链接

My-Note-Blog
My-Note-Blog copied to clipboard