我不知道的 V8（12）— 内联缓存：属性访问如何变成 O(1) 直接读

obj.x 看起来很简单，但 JavaScript 是动态类型语言，V8 不知道 obj 的 x 在哪——每次都去查？那性能没法看。V8 的解法是内联缓存（Inline Cache，IC）：第一次访问时记录 “这种形状的对象，x 在 offset 0”，后续直接复用这个结论，无需重新查找。理解 IC，就能理解 V8 性能优化中很多反直觉的行为背后的原因。

一、为什么需要内联缓存

JavaScript 属性访问面临的挑战：

function getX(obj) {
  return obj.x;
}

每次调用 getX，obj 可能是任何对象，x 可能在不同的位置。在没有优化的情况下，V8 每次都要：

检查 obj 的类型和隐藏类
沿原型链查找 x
如果是快属性，找到偏移量；如果是慢属性，查哈希表

这比访问 C 语言结构体的字段慢得多。内联缓存的目标：让第二次访问跟第一次一样快，跳过查找过程。

二、IC 的工作原理

IC 与字节码指令绑定。每个属性访问字节码指令（LdaNamedProperty）都有一个关联的缓存槽。

第一次执行：

const o1 = { x: 1, y: 2 };
getX(o1);
// 第一次执行：
// 1. o1 的隐藏类是 C0（有 x 在 offset 0，y 在 offset 1）
// 2. 查找 x → 在 offset 0 找到
// 3. 在 IC 缓存槽里记录：{ 隐藏类: C0, offset: 0 }
// → IC 状态：未初始化 → 单态（Monomorphic）

第二次执行（相同隐藏类）：

const o2 = { x: 3, y: 4 };
getX(o2);
// 1. 检查 o2 的隐藏类：是 C0
// 2. IC 命中：x 在 offset 0
// 3. 直接读取 o2.properties[0]，跳过查找
// → 速度接近直接内存访问

三、IC 的状态演变

IC 有四种状态，随着访问的对象类型多样化而演变：

单态（Monomorphic）：只见过一种隐藏类，最快

// o1, o2 都是 { x: number, y: number }，共享隐藏类 C0
getX(o1); // IC: C0 → offset 0
getX(o2); // IC 命中 C0，直接读
getX({ x: 5, y: 6 }); // 还是 C0，命中

多态（Polymorphic）：见过 2-4 种隐藏类，稍慢

const o3 = { x: 1, y: 2 }; // 隐藏类 C0
const o4 = { y: 2, x: 1 }; // 隐藏类 C1（属性顺序不同）
getX(o3); // IC: { C0 → offset 0 }
getX(o4); // IC 命中失败 → 扩展为多态: { C0 → offset 0, C1 → offset 1 }

多态 IC 内部是一个小型映射表，检查当前隐藏类并返回对应 offset。仍然很快，但比单态多一次比较。

超多态（Megamorphic）：见过超过 4 种（通常是 4 个）隐藏类，显著变慢

// 传入大量不同结构的对象
for (const item of diverseObjects) {
  getX(item); // 每个 item 结构略有不同
}
// IC 超过上限 → 进入超多态，放弃缓存，回归通用查找

超多态意味着 IC 完全失效，每次访问都走通用属性查找路径，TurboFan 也无法对这个访问点做针对性优化。

验证 IC 状态：

# 查看 IC 状态变化
node --trace_ic your-script.js

四、IC 与 TurboFan 的协作

IC 不只是加速属性访问，它收集的类型信息是 TurboFan 做优化决策的原料：

Ignition 阶段：
  → 执行字节码
  → IC 记录每个访问点的隐藏类信息

TurboFan 阶段（当函数成为热点）：
  → 读取 IC 的类型反馈
  → 假设"这个访问点永远是隐藏类 C0"
  → 生成专用机器码：直接读 offset 0，不检查类型
  → 比 IC 还快（连 IC 的比较步骤都省了）

如果 TurboFan 的假设被打破（新的隐藏类出现），会触发去优化，退回到 Ignition，IC 重新收集数据。

五、导致 IC 退化的常见模式

模式一：工厂函数属性顺序不一致

// 不同顺序 → 不同隐藏类 → IC 多态
function makeUser(isAdmin) {
  if (isAdmin) {
    return { role: 'admin', name: 'Bob' }; // 隐藏类 C0
  }
  return { name: 'Alice', role: 'user' }; // 隐藏类 C1（顺序不同！）
}

// 修复：统一属性顺序
function makeUser(isAdmin) {
  return { name: isAdmin ? 'Bob' : 'Alice', role: isAdmin ? 'admin' : 'user' };
  // 所有对象都是 { name, role } 的顺序 → 共享隐藏类
}

模式二：稀疏属性集合

// 不同对象有不同的属性子集 → 每个变体一个隐藏类
function getVal(obj) {
  return obj.value;
}
getVal({ value: 1 }); // 隐藏类 C0
getVal({ value: 2, tag: 'a' }); // 隐藏类 C1
getVal({ value: 3, tag: 'b', extra: true }); // 隐藏类 C2
// IC 在三次调用后变成多态甚至超多态

// 改进：统一对象形状，不需要的属性赋 null
getVal({ value: 1, tag: null, extra: null }); // 都是隐藏类 C0

模式三：在热点循环里动态修改对象

// 循环里改对象结构 → 频繁创建新隐藏类
function processItems(items) {
  for (const item of items) {
    if (item.count > 10) {
      item.isHigh = true; // 动态添加属性，改变隐藏类
    }
    process(item);
  }
}

// 改进：创建对象时就预定义所有属性
// 或者把 isHigh 提到对象创建时初始化

六、IC 与原型链

IC 不仅缓存对象自身的属性访问，也缓存原型链上的属性查找结果：

function Animal(name) {
  this.name = name;
}
Animal.prototype.describe = function () {
  return this.name;
};

const a1 = new Animal('cat');
a1.describe(); // 第一次：沿原型链找到 describe，缓存路径
// IC 记录：对象隐藏类 + 原型链上 describe 的位置

const a2 = new Animal('dog');
a2.describe(); // IC 命中，不需要重新查原型链

注意：如果原型被修改，相关的 IC 会失效：

Animal.prototype.describe = function () {
  return `[${this.name}]`;
};
// 所有之前缓存了 describe 位置的 IC 都失效
// 下次访问需要重新查找并更新缓存

这解释了为什么不推荐在初始化后修改原型——不只是设计上的问题，也会触发 IC 失效。

七、总结

内联缓存让动态语言的属性访问接近静态语言的速度，原理是”第一次查，然后记住结论，后续直接复用”。IC 状态从单态（最优）到多态（可接受）到超多态（失效），取决于同一访问点遇到了多少种不同结构的对象。

写对 IC 友好的代码，核心是让同一段代码始终处理结构相同的对象：属性顺序一致、不动态增删热点对象的属性、避免在一个函数里混用多种结构的参数。

本系列其他文章：