V8 引擎与 JS 编译执行

本节目标

V8 执行流程（简化）：

JS 源码
  → Parser 解析成 AST
  → Ignition 解释器：逐行解释执行（启动快）
  → 热点函数（执行多次）→ TurboFan 编译器：编译成机器码（执行快）
  → 运行中若假设不成立（如类型变了）→ 反优化回解释器

JIT（Just-In-Time）：解释器先跑（启动快），把「跑得热」的函数编译成机器码（后续快）。这就是「JS 明明是解释型，却能越来越快」的原因。

隐藏类（Hidden Class）与内联缓存（IC）：V8 给每个对象背后偷偷建了一个「形状描述」（隐藏类），记录「有哪些属性、内存偏移在哪」。属性添加顺序一致的对象共享同一隐藏类，属性访问走内联缓存，极快；一旦顺序不一致或动态增删属性，隐藏类「分裂」，访问变慢。

下面这段 Node 代码会真实测出「形状一致」和「delete 破坏形状（字典模式）」的性能差：

// 运行环境：Node.js 14+
// 步骤：node brw-l7.js
// 它会分别用「形状一致的对象」和「被 delete 破坏形状（退化字典模式）的对象」大量访问属性，打印耗时

const N = 2_000_000

// ✅ 形状一致：所有对象都按 x→y 顺序添加，共享同一隐藏类，内联缓存命中，快
function makeNormal(n) {
  const arr = []
  for (let i = 0; i < n; i++) arr.push({ x: i, y: i })
  return arr
}

// ❌ 被 delete 破坏形状：先加 z 再删掉，V8 无法用固定偏移，退化「字典模式」，慢
function makeDictionary(n) {
  const arr = []
  for (let i = 0; i < n; i++) {
    const o = { x: i, y: i, z: i }
    delete o.z
    arr.push(o)
  }
  return arr
}

function read(arr) {
  let s = 0
  for (const p of arr) s += p.x + p.y
  return s
}

// 预热：让 JIT 编译热点函数，避免首轮冷启动干扰
makeNormal(100000); makeDictionary(100000)

for (let round = 1; round <= 2; round++) {
  const a = makeNormal(N), b = makeDictionary(N)
  const t1 = performance.now(); read(a); const normal = performance.now() - t1
  const t2 = performance.now(); read(b); const dict = performance.now() - t2
  console.log(`第${round}轮  形状一致: ${normal.toFixed(1)}ms  字典模式(delete): ${dict.toFixed(1)}ms`)
}

补充说明：现代 V8 对「两三种形状」也能通过多态内联缓存（polymorphic IC）保持不错的速度，所以「属性顺序略有不同」这类轻微差异往往不明显；真正让 V8 放弃优化、退化成字典查找的，是 delete 这种「破坏形状」的操作（或动态塞进过多不同属性）。上面的对比正是用 delete 把「形状分裂」放大到肉眼可见——这也是面试常问「为什么 delete obj.prop 对性能不友好」的直接依据。

给 V8 的优化建议：对象属性初始化顺序保持一致、不要随意增删属性、避免 delete obj.prop、函数参数类型尽量稳定。

垃圾回收（GC）：

分代收集：新生代（存活短，Scavenge 快速回收）+ 老生代（存活久，标记-清除/标记-整理）
可达性：从「根」（全局对象、调用栈）出发能到达的对象才存活，其余回收
Stop The World：GC 运行时 JS 暂停——大对象堆积会造成卡顿

内存泄漏排查：Chrome DevTools 的 Performance 面板录内存曲线 + Memory 面板抓堆快照对比，找「本该消失却持续增长」的对象。

名词解释

JIT（即时编译，Just-In-Time Compilation）：边运行边把「热代码」编译成机器码的技术。它的「方法」是「解释执行 + 热点探测 + 编译加速 + 反优化回退」。你可以把它类比成「同声传译」：先口头翻（解释），发现某段话反复说（热点），就提前写好稿子（编译）念得更快。

隐藏类（Hidden Class / Shape）：V8 给对象「形状」建的幕后描述，记录属性名与内存偏移。方法/能力：getShape(obj)（概念上）查看形状；当属性按相同顺序添加，多个对象共享同一 Shape，访问走内联缓存（IC）极快；顺序不同则 Shape 分裂，退化为字典查找（慢）。

可达性（Reachability）：GC 判断「对象还该不该活着」的标准——从根（全局、调用栈上的变量）出发，沿着引用链能摸到的对象就是活的。方法/规则：标记(mark) 从根遍历打标，清除(sweep) 回收未打标的。闭包、未移除的监听器，常让本该死的对象的引用链不断，造成泄漏。

课后练习

练习 1：为什么 delete obj.prop 会被认为「对性能不友好」？

答案：delete 会破坏对象原有的隐藏类形状，V8 可能被迫把它转到「字典模式」存储，属性访问从「偏移直读」退化为「哈希查找」，明显变慢。相比之下，把属性设为 obj.prop = null 保留形状，性能更好（若只是想「清空值」的话）。

练习 2：下面代码为什么可能内存泄漏？怎么改？

function onResize() { /* 处理逻辑 */ }
window.addEventListener('resize', onResize)
// 组件销毁时只调用了 remove() 清了 DOM，却忘了移除监听器

答案：监听器 onResize 持有对组件内部变量/函数的引用，DOM 虽被移除，但监听器仍挂在 window 上，引用链不断，组件对象无法被 GC 回收 → 泄漏。改法：组件销毁时显式 window.removeEventListener('resize', onResize)；或使用 AbortController 统一取消一批监听器（addEventListener('resize', fn, { signal })）。

总结

这一节能颠覆一个常见错觉：很多人以为「JS 慢」是语言本身的锅。其实 V8 已经把 JS 优化到了令人发指的程度——解释器保启动速度，JIT 把热代码编译成机器码保运行速度，隐藏类让属性访问接近 C 语言的直接内存寻址。所以「JS 慢」往往不是语法慢，而是我们写的代码破坏了 V8 的优化假设：属性顺序乱跳、类型反复横跳、闭包hold住大对象不放。我的观点是：高级语言把性能优化的责任从「写编译器的人」转移到了「写业务的人」身上——你越懂引擎怎么工作，它就越为你加速；你越随意，它就只能保守降级。学 V8 不是为了去手写编译器，而是为了「别亲手关掉引擎的涡轮」。