★ FEATURED ARTICLE 写技术科普最怕一个情况讲的人自己都没想清楚却在文里塞满术语。这篇想聊的 V8恰恰是 JS 性能话题里最容易聊成名词堆砌的领域。随便一个帖子都能看到 AST、字节码、JIT、去优化可真要把这四者串成一条能讲清为什么快的链路大多数人其实说不完整。我做了几年前端、写引擎相关的脚本也写过不少这篇就用实际调优时最常碰到的场景把 V8 这套翻译官 加速器的协作机制拆开讲透。先说结论JS 之所以快不是因为解释器牛而是靠一条非常成熟的工程管线——把源码变成 AST、把 AST 变成字节码、再用运行时反馈驱动 JIT 把热点函数烧成机器码最后还要靠去优化兜底。这四步缺一不可每一步都有代价也都有各自的取舍哲学。你看完这篇未必能写出一个引擎但再遇到性能问题至少能判断出它卡在哪一环。1. 解释型标签害了不少人一条 JS 代码是怎么被吃进去的1.1 边解释边执行这个说法为什么早就过时了教科书、面试题、不少人的口头禅都在说 JS 是解释型语言。这个标签放在 V8 面前已经非常勉强。V8 不是一边读源码一边执行而是在内部走完一整套编译管线源码先进词法分析拆成 token再进语法分析组成 AST然后编译进字节码最后才有机会被 JIT 编译成机器码。整个过程里真正拿来直接执行的有两条路解释器 Ignition 跑字节码或者优化编译器 TurboFan 跑机器码。所以严格说它是混合执行模型而不是传统意义上那个读一行执行一行的解释器。这个区别不是咬文嚼字。它直接决定了你写代码时的一些直觉。比如function foo() {}定义完后不调用V8 不会马上把 foo 内部给完整编译又比如同一段代码执行一百遍和只执行一遍V8 对它的投入完全不同。这些都是解释型语言四个字无法解释的现实行为。1.2 一次属性访问背后要走多少步我用最简单的一行代码举例const name user.name;。就这一行V8 后面做了至少五件事分词器把const、user、.、name拆成 tokenParser 把这些 token 组装成 AST 节点Ignition 把 AST 编译成字节码并开始解释执行执行到user.name时V8 会启动 IC内联缓存机制记下此刻user的隐藏类Map和属性name在对象里的偏移量当这段代码被反复执行成为热点TurboFan 拿到 IC 反馈把整个函数编译成机器码并且不再用动态查属性而是直接按固定偏移量从内存里取值。所以你看真正让 V8 快的并不是它是个很厉害的解释器。解释器只是翻译官负责把 AST 变成好执行的形式加速器是 JIT它把反复出现的代码路径变成高度专门化的机器指令。翻译官保证什么都能跑加速器保证跑得快的常见路况都有专属通道。至于通道建立在什么假设上以及假设破了会发生什么就是后面要聊的去优化。2. AST 不是给你看的是给引擎吃的解析器到底在忙什么如果以为 parsing 只是把字符串变成对象树那就低估了这一步的工程复杂度。V8 里这句很少见诸教科书默认情况下它不会把你的所有函数一次解析完。2.1 Parser 与 PreParser为什么有的代码整体解析反而更慢V8 对函数声明默认走惰性解析。它的做法是顶层代码会被完整解析成 AST但函数体内部先只做预解析PreParser。预解析不生成完整 AST 节点只快速确认语法骨架、识别出变量声明和函数声明的位置知道这里有一个函数等它将来真的被调用时再彻底解析。这种做法的动机非常直接大部分网站的 JS 包里有两三个 MB 源码函数大几百个但页面启动阶段真正执行到的函数可能只有两三成。如果把每个函数从前到后都完整建 AST启动就要白白浪费大量 CPU 和内存。这里有个反直觉结论一个函数定义得再大只要没执行它对运行的拖累是有限的反而是大量顶层语句会第一时间进入完整解析。所以你写脚本时想减少启动代价不是避免写大函数而是避免在模块顶层堆满初始化语句把初始化放进取一个立刻被调用的函数里反而能利用惰性解析带来的晚做少做。2.2 AST 节点到底有多重为什么非要转成字节码AST 是一棵对象树节点对象有类型、源码位置、子节点链表、语法属性等等非常臃肿。用比较夸张但有效的类比AST 是书稿的批注版每个词旁边都贴着解释、页码、修订标记字节码则是整理过的速记本一条指令就把一长串语义浓缩了。V8 当然可以直接在 AST 上执行但那样每一步都要在树上递归找子节点、判断类型慢得离谱。所以 Ignition 很快把 AST 翻译成紧凑的字节码。字节码好处是密度高、内存占用小、解释器遍历起来简单。现代 CPU 对顺序执行非常友好解释器只要做一个大的 switch 分支把字节码一条条派发出去命中率不错。引擎还能在内存里只保留一份被压缩的字节码而不是整棵 AST 常驻。这一点对移动端格外重要内存就是性能本身。2.3 语法错误的分层哪些阶段立刻挂哪些阶段运行时才暴露很多刚接触引擎源码的人会困惑为什么某些语法错误要运行到那一行才报出来这是因为解析分不同阶段。V8 的 Parser 在遇到完全无法形成语法树的 token 组合时会立刻抛 syntax error代码根本不会执行。但有一些错误其实是运行时检测出来的比如访问 undefined 的属性那是执行阶段的问题跟解析无关。还有一种情况是引擎支持的语法扩展如可选链、空值合并、顶层 await不同引擎版本对它们的解析容忍度不同这也是为什么同一段新语法代码在某台机器上跑着跑着跑到那行才报错。工程上有个常见误解觉得把一个大文件拆成多个小文件也只影响请求数或加载顺序其实也影响解析。因为 V8 是逐段扫描解析的大文件贪恋一次解析太多的 token会拉长启动时间拆成按需加载的 chunk 后每个 chunk 用惰性解析配合可以明显缩短首屏脚本处理时间。这些都是在真实页面里能感受到的差异。3. 字节码Ignition 这位翻译官的底层账本3.1 V8 的字节码为什么是寄存器风格而不是栈风格不少后台同学熟悉 JVM 字节码那是明显的栈式设计——几乎所有操作都 push 到操作数栈、pop 出来计算。V8 的 Ignition 不同它选择了寄存器式字节码而且不是完全寄存器分配是 基于累加器 的简化寄存器设计。我为什么觉得这个选择值得讲因为大多数指令都围绕一个 accumulator累加器寄存器展开解释器既不用像纯栈机那样频繁压栈弹栈也不用做复杂的寄存器分配。比如表达式a b典型字节码序列非常短Ldar a ; 把 a 加载到累加器 Add b ; 累加器 累加器 b Star r0 ; 把累加器结果存到临时寄存器 r0这种序列对后续的机器码翻译也友好。因为真实 CPU 本身就是寄存器运算从 加载到累加器、运算、存储 到机器指令几乎是一一映射的思路。V8 的处理方式是每个函数帧里预留一批虚拟寄存器用来存局部变量和临时值访问时直接通过帧指针偏移找。3.2 从 AST 到字节码编译器顺手做了哪些微优化字节码不是盲目翻译 AST中间有不少编译期小优化。常见有这四类常量折叠1 2这种字面量表达式解析编译时直接算成3省一次运行时加法字符串驻留把字符串字面量统一放到常量表中字节码里只存索引上下文槽位查找对闭包变量或全局变量的访问在编译期就确定是context[slot]还是global[slot]避免执行时再去作用域链表反复找特殊化标记某些操作码会带上类型假设标记比如AddSmi、IncSmi便于 JIT 后续直接使用。这些优化在 AST 树上是没法直接用的因为 AST 是结构化数据而字节码才是真正贴近执行的指令流。不夸张地说AST 转成字节码这个动作本身就带来了一部分性能提升——因为执行单元从大型树形对象变成了短小的指令序列。3.3 为什么不干脆直接编译成机器码非要先整个字节码出来这个问题我见过很多次。如果每段代码都直接编译成机器码启动和内存会被拖垮。V8 面对的是一整个网页的 JS、一个 Node 服务的全部依赖可能动辄几十万行代码。全部机器码化的话编译时间会长得离谱而且很多函数只执行一次编译收益为负。字节码层充当了中间站它启动快编译快内存紧凑还能在运行时被 JIT 重新优化。换句话说字节码让冷启动和热优化这两个目标不需要二选一。V8 在前端和后端都使用字节码以外的策略比如后来的 Sparkplug 是一个不用类型反馈的快速机器码生成器介于 Ignition 和 TurboFan 之间。它不做深入优化但可以把解释执行阶段的一些函数替换成机器码来提速又不花费 JIT 的优化时间。所以说这套管线不是一句话能概括的而是分了好几档速度。4. TurboFan加速器是怎么判断该给谁提速的4.1 热点函数计数器、反馈向量和调用阈值Ignition 在解释执行时V8 会给每个函数维护一个调用计数器埋在 feedback vector反馈向量里。函数每被调用一次计数器就涨一点越过阈值后这个函数会被标记为 hotTurboFan 就会被请出来做优化编译。阈值具体是多少版本之间差异很大通常从几百到上千不等。一句话V8 不会看你代码写得有多优秀来主动优化而是看这段路被走得有多频繁。频率就是投资的依据。这带来一个很实在的编码启示不要优化不热点的地方。你费老大劲把一个每秒钟只调用一次的函数从 10 毫秒优化到 1 毫秒对整体毫无感知而一个每秒执行十万次的循环体哪怕每轮省一个指令收益都很显著。V8 的加速机制是拿你反复执行的代码开刀所以你自己也应该把注意力放在最热的路径上。4.2 内联缓存运行时怎么把类型信息长在代码旁边JIT 最需要的东西是类型信息但 JS 是无类型语言。V8 解决这个问题靠的是 IC。每个属性加载、方法调用、数组元素访问的字节码后面都跟着一个反馈槽位feedback slot。第一次执行user.name时走慢速路径去对象上查属性然后把三个关键信息记下来接收者对象的隐藏类Map、属性的偏移量、还有当前访问模式是 Load 还是 Store。下一次执行同一位置时先检查对象的 Map 是否和缓存的一致如果一致就直接用偏移量取出属性完全不再查对象。IC 有三个状态单态monomorphic、多态polymorphic、超态megamorphic。单态意味着这个地方只见过一种对象形状最快多态见过两三种还会分别缓存超过一定数量就变成超态V8 直接放弃专门优化回退到慢速查找。TurboFan 编译热点函数时吃到 monomorphic 的反馈是最舒服的因为它可以大胆把user.name换成如果 Map 是 M1 就偏移量加载的原生指令。你写代码时如果同一个调用点传来传去全是同一形状的对象那就是在给 TurboFan 送弹药。4.3 类型专门化与逃逸分析优化编译器拿到承诺后怎么干事TurboFan 拿到反馈向量还不够它会把对未来的预示写进生成的代码里。常见手法有三个方向类型专门化加法指令假设两边都是 int32直接用 CPU 整数加法假设失败再去 float 路径或字符串拼接路径Map 检查每个属性访问前面会插入一个 map 比较指令保证对象形状符合缓存时才走快速加载否则跳去慢速路径或触发去优化逃逸分析如果某个对象只在函数内部创建和使用不影响外部TurboFan 可以不做堆分配直接标量替换成几个寄存器和局部变量。所以JIT 快的本质是它把解释器里的通用操作替换成了假设成立就快速执行的专门操作。代价是每一条专门指令都带着一个条件判断——条件成立快到飞起条件不成立就要跳出去兜底这就是下一章的去优化。5. 去优化速度的反向操作比想象中更频繁5.1 优化代码为什么会被推翻优化建立在猜测上而 JS 的动态性注定了猜测一定有失效的一天。TurboFan 生成的机器码里那些 map 检查、int32 检查本质都是关卡。极少数情况下这些关卡全过、一路绿灯性能就拉满但一旦某个关卡失败机器码不能继续走下去因为后续的指令全部建立在之前的假设上一步错步步错。这时 V8 做两件事一是停止当前优化代码二是把这块执行从机器码切回字节码重新解释执行VM 会尽量把上下文恢复到进入优化前逻辑上等价的那个点。这个过程就是 deoptimization翻译成去优化比较直观。你可以想象一辆跑车在高速上飞驰前面突然出现施工区司机必须急刹车并下高速走地面道路。地面道路慢但至少不会翻车。性能冲击点在于任何一次去优化都要有额外的检查成本而且如果去优化频繁发生TurboFan 会反复尝试重新优化、再次失败形成“笑傲”循环——这才是性能断崖的真正元凶。5.2 常见的去优化触发总结成一个检错表我平时排查问题会直接把现象归到三类假设失效上比盲目打开性能面板更有效。假设类型常见触发原因后果类型假设失效同一变量先 number 后 string函数参数类型不稳定整段优化代码作废回退解释执行形状假设失效对象动态加属性、删属性属性定义顺序变化改变原型所有依赖该 Map 的访问点失效结构假设失效数组被越界访问数组从密集变稀疏出现超大整数超出 31 位 SMI元素访问的快速路径全部被打回举个特别典型的例子用户对象一开始没有admin字段某段逻辑里根据登录态user.admin true。这个赋值改变了 user 的隐藏类 Map而几百行之外另一个热点函数正在高频读取user.name它的 JIT 优化是按旧 Map 生成的。赋值发生的那一刻新 Map 和旧 Map 不同热点函数下一次执行就撞上 map 检查失败被去优化。这是动态加属性最具杀伤力的一面。5.3 OSR循环里换挡的机制热点不只在函数层面出现也常出现在循环内部。如果函数整体被反复调用TurboFan 正常编译就行但某个长循环执行一次就要几百万轮下次再调用时热点函数可能早已被优化了问题不大。真正微妙的是一个函数第一次调用内部循环已经跑了 10 万次但此前没有运行过热分析TurboFan 发现它热只能现场编译还要把自己塞进正在执行的栈帧里。这个机制叫 OSRon-stack replacement栈上替换。OSR 很妙的地方在于它可以直接把正在解释执行的循环切到优化后的机器码上。同理优化代码在循环中途发现假设失败也需要切回解释执行这个过程叫反 OSR。如果代码里存在大量短小循环OSR 的切换成本甚至会超过收益所以 V8 对是否 OSR 也是有节制的。这也是为什么盲目把所有代码封装成一个巨型函数指望函数热点一次全优化往往适得其反——太大太长的函数会让 TurboFan 期间失效点增多编译本身也更贵。6. 从机制反推编码让 V8 少踩去优化刹车的习惯聊了不少原理最后落到实践。这些年我在业务代码里总结出来的第一条纪律是性能关键路径上宁可把代码写得呆一点。所谓呆是指让 V8 的猜测更容易正确。6.1 稳定对象形状比代码灵活更值钱想让 IC 和 TurboFan 建立稳定的 map 缓存对象形状最好从头到尾不变。具体操作上构造函数里一次性声明全部字段涉及可选字段也提前置成 null后续不要再obj.newField x更不要无事delete obj.someField。删除属性和增加属性一样都会换 Map而且会把该对象甩出已有 IC 的命中外。如果业务里确实需要动态 key就统一用一个 Map 或Object.create(null)让自己明确知道这段代码不会享受对象形状优化的红利。6.2 保持调用点的单态性同一处接口别干混类型的事一个函数如果被设计成参数可以是 string 也可以是 number反正 JS 能容那它就是这个调用点沦为 polymorphic 甚至 megamorphic 的源头。这不代表业务设计有问题但你心里要有一杆秤在一个高频调用位置上传参类型越单一TurboFan 越容易优化。如果你写了两个计算函数一个专门处理 int一个专门处理 string通常比一个万能处理函数在热路径上快很多。这是典型的让动态语言在热路径上表现得像静态语言的思路。6.3 小心那些让 JIT 不得不加保险丝的写法规避数组是最容易踩坑的领域。V8 对连续密集、索引在 SMI 范围内的数组有非常成熟的元素访问快速路径一旦出现稀疏数组、越界访问、超大整数引擎就得生成边界检查和更慢的元素存取逻辑。我有一次调优经历就是一个高频函数误以为数组一定越界专门用一个if (arr[i] undefined)做兜底。这个兜底让 JIT 认为该数组访问可能越界得在快速路径上挂检查直接影响整个循环的吞吐。后来把循环长度改为精确边界检查问题立刻消失。这里的经验是热路径上不要做防御式访问把越界判断提到循环外而不是在每次取值处埋雷。6.4 遇到突然变卡时先别调算法先查假设团队里有人遇到性能问题我的第一个建议永远是开 devtools 的记录看一段函数时间段的 Compile 和 Deoptimization 事件数量。如果 deopt 计数很高不用急着换数据结构先找到那个反复失效的调用点——通常它就是某个动态类型变化的源头。曾经有个模拟项目就是这么定位的一个列表页面A 路由 60 毫秒处理完B 路由要 800 毫秒。看日志发现同一函数在 B 里被反复优化-去优化根因是 B 页面给 object 加了一个自定义 getter改变了 map。改成普通属性后耗时直接掉到 90 毫秒。这种收益完全不是靠调业务逻辑能达到的。写到这里把 AST、字节码、JIT、去优化这条链路聊完我想留给你的不是一套名词而是一种帮自己画执行图的能力。看到一段性能代码先问两个问题它哪里可能被当成热点TurboFan 对它的假设是什么假设会不会轻易破这两个问题想清楚了很多调优方向自己会浮出来。V8 的细节版本之间会有出入但翻译官负责通用、加速器负责猜测、猜测必须以去优化兜底这套框架长期不变。最后再分享一个小技巧我每次写性能关键模块前会在文件头部注释里写一句话此函数假设入参类型固定、对象形状固定、不使用动态属性。它不改变任何运行时行为但让后来接手的人知道别在这里引入 灵活 的动态把戏。对 V8 来说最贵的从来不是代码行数而是那些让它猜错的行为变化。
阅读完成 · 觉得有帮助？
