浏览器原理：4.2 JS执行时的内存情况

---

JS 执行时的内存情况

众所周知，操作系统为各个进程提供了一个内存的抽象——虚拟内存，让开发者无需关注底层的硬件存储部分的技术细节，JS也是一样，只不过一般来说JS是运行在浏览器上的。

执行上下文

上节讲到，JS会首先由 JS引擎编译后再执行，编译后会产生执行上下文。执行上下文包括变量环境和词法环境。编译的时候然后会把声明变量以外的代码编译成可执行代码。编译完成后会一行一行开始执行。

以这个例子说明

var foo = 2
function add(){
var bar = 3
return a + b}
add() // 5

当编译完成后，可执行代码为

foo = 2
add()

• JS 首先从变量环境中找到 foo 变量，并为其赋值
• add函数调用，JS引擎判断出这是一个函数调用，会按一下流程来执行
  - 首先，从当前执行上下文中，取出 add函数 的代码
  - 其次，对 add 函数的这段代码进行编译，跟上面一样，生成执行上下文和可执行代码
  - 最后执行代码

不难发现，JS执行一个函数调用的过程跟JS执行的过程是大体一致的，但这里有一个问题，浏览器是通过怎样的数据结构来管理多个执行上下文之间的关系的，比如怎样传参，确定返回值，函数调用结束后怎么回到函数调用的下一行代码？

调用栈

答案就是栈，JS引擎通过栈来管理执行上下文，在执行上下文创建好后，JS引擎会将其压入栈中，当一个函数调用完毕后，JS引擎会将其弹出，通常把这种用来管理执行上下文的栈叫做 调用栈 call stack

• 在Chrome devtool 调试中可以观察 call stack 的状态
• console.trace() 可以输出当前函数的调用关系

栈溢出

计算机的内存是有限的，栈肯定也是。当执行上下文的个数超出了调用栈的容量时，JS引擎就会报错，比如当递归层数太大的时候就会发生这种状况。因为一般是函数调用时才会创建执行上下文，所以尽量减少递归的层树调用成了解决栈溢出问题的主要措施。尾递归就是一种优化方案，但大多数浏览器未支持这种技术