Closure in V8 - 技术栈

本文作者：Vice

前言

对于我们前端开发来说，无时无刻不在接触着闭包。比如在 React Hooks 中利用了闭包来捕获组件的状态，并在组件的生命周期中保持状态的一致性。在 Vue 中利用闭包来定义计算属性和监听器，以及在组件之间共享数据。在 Angular 中利用闭包可以用于创建服务和依赖注入。

所以理解闭包产生的原因和原理对我们的日常开发非常重要。

热个身

其实 JavaScript 本身的特性决定了一定要实现闭包：

JavaScript 允许在函数内部定义新的函数。
因为 词法作用域，可以在内部函数中访问父函数中定义的变量。
函数作为一等公民，函数可以作为返回值。

利用上面三点列举一个贯穿全文的 JavaScript 经典闭包代码：

JavaScript 复制代码

function multi() {
    var a = 10;
    return function inner() {
        return a * 10;
    }
}
const p = multi();

此段代码声明了 multi 函数，在函数内部定义了变量 a，并且返回了 inner 函数，inner 函数中访问 multi 函数中声明的 a，最后执行了 multi 函数并且将返回值返回给 p。这个时候闭包就创建完成啦，闭包让开发者可以从内部函数访问外部函数的作用域，p 函数始终能访问到 multi 函数中的 a。

但是大家都知道，multi 函数执行完之后，理应内部声明的变量都会被销毁，但是因为闭包的原因，这个 a 变量突破了这种限制。

为了实现闭包，我们来看看 V8 都是怎么做的吧。

V8 是如何执行一段 JavaScript 代码的

我们都知道，我们写的 JavaScript 代码，是需要经过编译的步骤，让 CPU 获取到一串二进制的指令去执行的。完成这一步的通常有两种方法：

解释执行，将源代码通过解析器生成中间代码，然后用解释器解释执行，它的优势在于快速启动执行，但执行速度相对较慢。
编译执行，也是先生成中间代码，然后通过编译器将中间代码直接转换成二进制代码，执行的时候直接执行二进制文件即可，它的优势在于执行时直接操作二进制文件，执行速度更快，并且编译过程只进行了一次，所以在多次执行相同代码时，编译执行的性能更高，但是相对的启动速度就会比较慢。

V8 采取的策略是混合编译执行和解释执行，也就是我们经常听到的 JIT，是一种对上述两种策略的一种权衡。流程如下：

初始化执行环境，比如堆栈空间、事件循环系统等。
解析器解析代码生成 AST 和作用域。
根据 AST 和作用域生成中间代码，也就是字节码。
解释器解释执行中间代码输出结果。
监控解释器执行，发现频繁执行的热点代码会生成二进制代码以提高执行速度。
热点代码改变或者执行频率下降，编译器会执行反优化重新让这段代码生成字节码。

V8 遇到函数是如何编译的？

上面说到执行 JavaScript 代码需要经过编译到中间代码的步骤，但是实际上 V8 并不会把所有代码全部进行解析，是因为如果一次性编译所有 JavaScript 代码，编译时间会很长，需要全部编译完才能执行代码，对用户来说会感到严重的延迟特别是大型项目。并且编译产生的大量中间代码会非常占用内存资源，特别是移动设备，内存的消耗是需要谨慎考虑的。

所以包括 V8，所有主流浏览器都实现了延迟解析（lazy parsing）。顾名思义，V8 会推迟对代码的解析，直到代码被实际执行时才进行解析。具体就是在解析器遇到函数声明时，只会解析函数的声明部分，而不会解析函数内部的代码。在执行函数的时候 V8 会对函数进行各种优化，例如内联优化、类型推断等。延迟解析也可以使 V8 有更多的执行上下文和运行时信息，从而更好地进行优化，提高代码的执行效率。

我们来使用 D8 工具具体看个例子：

JavaScript 复制代码

var top = 1;
function multi(a) {
    return a * 10;
}

通过 d8 --print-ast 命令打印出 AST 信息：

V8 首先会接收到我们书写的源代码，为了理解这段源代码，它需要结构化这段字符串来生成源代码中的语法结构和关系，便于后续 V8 的理解。比如语言转换器 Babel、语法检查工具 ESLint 等，底层都使用了 AST 去实现。

AST 复制代码

--- AST ---
FUNC at 0
. KIND 0
. LITERAL ID 0
. SUSPEND COUNT 0
. NAME ""
. INFERRED NAME ""
. DECLS
. . VARIABLE (0x7fa6a5810050) (mode = VAR, assigned = true) "top"
. . FUNCTION "multi" = function multi
. BLOCK NOCOMPLETIONS at -1
. . EXPRESSION STATEMENT at 10
. . . INIT at 10
. . . . VAR PROXY unallocated (0x7fa6a5810050) (mode = VAR, assigned = true) "top"
. . . . LITERAL 1

简单解释下这段被解析器解析生成的 AST，着重看 DECLS 和 EXPRESSION STATEMENT。

DECLS 代表一组声明，此处声明了一个名为 top 的变量，并且该变量被赋值（assigned = true）。还声明了一个名为 multi 的函数。

EXPRESSION STATEMENT 表示一个表达式语句节点，这里就是 var top = 1;，下面的内容代表这段表达式的结构化表述，将变量 top 的 proxy（指向了实际 top 的值，可以看到 0x7fbc75010c50 地址相同）并且初始化为字面量 1。

所以自始至终解析器并没有解析函数体内部的代码，仅仅只解析了函数的声明部分。

我们也可以通过 d8 --print-scopes 打印此时 multi 函数的作用域：

scopes 复制代码

Global scope:
global { // (0x7ff32601e030) (0, 53)
  // will be compiled
  // NormalFunction
  // 1 stack slots
  // temporary vars:
  TEMPORARY .result;  // (0x7ff32601e530) local[0]
  // local vars:
  VAR top;  // (0x7ff32601e250) 
  VAR multi;  // (0x7ff32601e4a0) 

  function multi () { // (0x7ff32601e2e0) (27, 53)
    // lazily parsed
    // NormalFunction
    // 2 heap slots
  }
}

我们可以看到它没有为 multi 函数生成作用域，而是进行 lazily parsed。

那我们执行一下这个 multi 函数，看看 AST 会是什么样子：

JavaScript 复制代码

var top = 1;
function multi(a) {
    return a * 10;
}
multi(3);

AST 复制代码

[generating bytecode for function: multi]
--- AST ---
FUNC at 27
. KIND 0
. LITERAL ID 1
. SUSPEND COUNT 0
. NAME "multi"
. PARAMS
. . VAR (0x7fe75782f670) (mode = VAR, assigned = false) "a"
. DECLS
. . VARIABLE (0x7fe75782f670) (mode = VAR, assigned = false) "a"
. RETURN at 37
. . MUL at 46
. . . VAR PROXY parameter[0] (0x7fe75782f670) (mode = VAR, assigned = false) "a"
. . . LITERAL 10

执行 multi 函数时，从 multi 函数对象中取出函数代码，和顶层代码一样编译为 AST 和字节码，然后再解释执行，这里我们简单看看生成的 AST 吧：

PARAMS 代表函数参数部分，表示函数有一个参数 a，且该参数未被赋值（在执行阶段才会指向堆和栈中相应的数据）。DECLS 中声明了 a 变量，地址与参数 a 相同。RETURN at 代表函数返回语句位于源代码的位置。MUL at 代表返回值是一个乘法表达式。下面一行代表乘法表达式的第一个操作数是参数 a。LITERAL 10 代表乘法表达式的第二个操作数是字面量 10。

延迟解析 & 闭包

当延迟解析遇到了闭包，那么情况就又复杂了，我们来稍微改造一下上面的 multi 函数。

JavaScript 复制代码

function multi() {
    var a = 10;
    return function inner() {
        return a * 10;
    }
}
const p = multi();

这是一段闭包代码，我们简单分析下上述代码的执行流程：

执行 multi 函数时，multi 函数会将它的内部函数 inner 返回给全局变量 p。
然后 multi 函数执行结束，执行上下文被 V8 销毁。

V8 用执行上下文来维护执行当前代码所需要的变量声明、this 指向等，比如这里的 a 变量。

虽然 multi 函数的执行上下文被销毁了，但是被全局 p 引用的 inner 函数引用了 multi 函数作用域中的变量 a。

为什么 inner 函数中的 a 引用的是 multi 中的 a，这是因为 JavaScript 是基于词法作用域，是静态的作用域，和函数如何调用如何执行没有关系，是代码编译阶段就决定好的，查找顺序都是照当前函数作用域向上冒泡，最后到全局作用域。所以这里的变量查找规则为 inner 函数作用域 -> multi 函数作用域 -> 全局作用域。

所以这里就会带来两个问题？

当 multi 函数执行完成时，因为闭包的存在，此时 multi 的执行上下文被销毁，但是 a 变量又被引用了，肯定不能被销毁，那么 V8 会采取什么策略。
因为 V8 采用的延迟解析，在 inner 函数未执行的时候，是不会解析 inner 内部的代码的，所以 V8 并不知道是否引用了外部作用域中的变量。

预解析器（preparser）

V8 为了解决这两个问题的，引入了 预解析器（preparser） 模块来解决，主要是做了两件事：

当解析到顶层函数时，预解析器并不会直接跳过该函数，而是对该函数做一次快速的预解析，是为了判断当前函数是不是存在一些语法上的错误。

在过去的版本中，预解析器在解析脚本时会忽略变量声明，例如在同一作用域中两次声明同名的变量应该被视为语法错误，但预解析器会允许这样的代码通过预解析阶段。当时是为了追求性能的提升，预解析器忽略了变量声明的处理。现在修复后的预解析器能够正确处理变量声明和引用，符合ECMAScript规范，并且也没有明显的性能损失。

当执行函数时，只会将当前函数生成 AST 以及字节码，对内部声明的其他函数进行预解析，是为了检查函数内部是否引用了外部变量。如果函数内部引用了外部变量，预解析器会将这些变量从栈中复制（值类型复制值，引用类型复制地址）到堆中。这样，在下次执行该函数时，函数可以直接使用堆中的引用，从而解决了闭包所带来的问题。

我们来具体通过执行 multi 函数的字节码来理解下，通过 d8 --print-bytecode 来打印：

其实早期的 V8 为了提升代码的执行速度，是直接将 JavaScript 源代码编译成了没有优化的二进制的机器代码，但是随着移动设备的普及，V8 团队逐渐发现将 JavaScript 源码直接编译成二进制代码存在两个致命的问题。第一是编译时间过久，影响代码启动速度；第二是缓存编译后的二进制代码占用更多的内存。所以便引入字节码来解决上述启动问题和空间问题。

bytecode 复制代码

[generated bytecode for function: multi (0x06d300259e19 <SharedFunctionInfo multi>)]
Bytecode length: 14
Parameter count 1
Register count 1
Frame size 8
Bytecode age: 0
         0x6d30025a092 @    0 : 83 00 01          CreateFunctionContext [0], [1]
         0x6d30025a095 @    3 : 1a fa             PushContext r0
         0x6d30025a097 @    5 : 0d 0a             LdaSmi [10]
         0x6d30025a099 @    7 : 25 02             StaCurrentContextSlot [2]
         0x6d30025a09b @    9 : 80 01 00 02       CreateClosure [1], [0], #2
         0x6d30025a09f @   13 : a9                Return
Constant pool (size = 2)
0x6d30025a061: [FixedArray] in OldSpace
 - map: 0x06d300002231 <Map(FIXED_ARRAY_TYPE)>
 - length: 2
           0: 0x06d300259ff9 <ScopeInfo FUNCTION_SCOPE>
           1: 0x06d30025a029 <SharedFunctionInfo inner>
Handler Table (size = 0)
Source Position Table (size = 0)

我们看到 Bytecode age: 0 （代表字节码的执行状态，数字增加代表函数的热度，也就是上面说的热点代码，V8 就会对这串代码进行针对性优化）下的一条条指令就是字节码啦，这六条指令解释器执行完就代表 multi 函数执行完成了，上面打印出来的字节码只是全部的冰山一角，若有同学有兴趣的话，可以到V8源码查看更多。

这里的字节码最终通过解释器解释执行，在执行的过程中，需要通过某些手段去保存参数、中间计算结果等，V8 的解释器（Ignition）采用的是基于寄存器的架构，他通过寄存器来保存所需要的数据。有兴趣的同学可以详细查看Ignition 设计文档中的 register 相关内容。

下面我来简单逐行解释下打印出来的代码。

Bytecode length 表示函数 multi 的字节码长度。Parameter count 1 表示函数 multi 接收一个参数，这里是隐式地传入了 this。Register count 表示使用的寄存器数量。Frame size 代表栈帧大小（因为 V8 是通过栈结构来管理函数调用，栈帧是一个用于存储参数、被调用者的返回值、局部变量和寄存器的空间）。

CreateFunctionContext 是用来创建函数上下文的，会把 multi 函数上下文和作用域信息存到寄存器中，当然 inner 函数也会存进去。PushContext 用于将寄存器中的上下文推入执行上下文栈。LdaSmi 和 StaCurrentContextSlot 代表将值 10 加载到寄存器中并且存储到当前上下文中。CreateClosure 就是通过传入上下文的一些信息，若发现内部有引用外层作用域链上的变量，则输出带有闭包信息的新的 inner 函数存进寄存器中最后返回。

我们重点看下下面的字节码，Constant pool 代表常量池，当代码中使用了多个相同的常量值时，V8 引擎会将这些常量值存储在 Constant pool 中，并在需要使用时直接引用它们，而不是重复创建多个相同的常量值。继续往下看 [FixedArray] in OldSpace 代表下面的常量存到了老生代中，老生代中的对象更稳定，不容易被回收，通常用于用于存储生命周期较长的对象，例如函数、闭包、大型对象。下面的 ScopeInfo FUNCTION_SCOPE 表示函数作用域信息的数据结构，它记录了函数内部的变量和作用域链等信息。SharedFunctionInfo inner 表示用于存储 inner 函数的字节码等。这两个常量同时存在表示内部函数 inner 与外部函数的作用域存在关联，通过 ScopeInfo 中的作用域链查找到内部函数访问了外部函数的变量。最后在 SharedFunctionInfo 中会存储内部函数引用的外部函数的变量作用域范围的信息，这里就是存储了闭包变量 a 的作用域范围，存储到了堆中供后续 inner 函数执行访问。

所以 V8 通过预解析器使得 JavaScript 的闭包特性得以实现。

总结

本文我们介绍了在 V8 中是如何实现闭包这一特性的，V8 在处理函数的时候采用的延迟解析来提高启动速度，但是延迟解析和闭包存在天然的矛盾，所以当一个函数中存在闭包并且执行时，V8 会通过引入预解析器去扫描内部函数使用到的外部变量，并且复制到堆中，下次执行内部函数的时候就是直接访问堆中的引用。

最后我们要注意闭包可能导致的内存泄露问题，我们书写闭包代码时如果引用了一些后续用不到的变量，比如说引用了一个大对象，但是我们只用这个对象中的一个属性值，那么就会导致这个大对象不会被销毁，导致内存泄漏，解决方式们就是要将需要的属性值提取出来成为一个新变量，在函数中引用此新变量就可以。还有一些引用 dom 节点产生的泄露等问题。

参考

图解 Google V8

Blazingly fast parsing, part 2: lazy parsing

最后

更多岗位，可进入网易招聘官网查看 hr.163.com/