我不知道的 V8（08）— 字典模式下的非线性优化与限制

前面的文章解释了 V8 为什么会切换到字典模式（Dictionary Mode）——对象结构变得不稳定，维持隐藏类的成本超过了收益。但字典模式并不意味着”放弃优化”。V8 在哈希表层面做了一系列针对性的优化，同时，字典模式也有硬性的性能天花板。理解这两面，才能在实际开发中做出准确的判断。

一、V8 字典模式的内部实现

V8 的字典模式使用两种哈希表结构（取决于属性名是字符串还是 Symbol）：

NameDictionary：存储字符串键属性（最常见）
OrderedNameDictionary：保证插入顺序的版本，用于特定场景

以 NameDictionary 为例，当一个对象转为字典模式时：

const obj = { a: 1, b: 2, c: 3 };
delete obj.a; // 触发字典模式转换
obj.d = 4;
// obj 现在是字典模式，属性存储在 NameDictionary 里

NameDictionary 的内存布局（简化）：

NameDictionary:
  容量: 8（初始）
  已使用: 3
  删除槽: 1（"a" 删除后留下的标记）

  桶 0: <empty>
  桶 1: { key: "b", value: 2, attributes: [...] }
  桶 2: <deleted>     ← "a" 被删除，保留删除标记
  桶 3: { key: "c", value: 3, attributes: [...] }
  桶 4: { key: "d", value: 4, attributes: [...] }
  桶 5-7: <empty>

注意每个槽位还存储了属性描述符（attributes），包含 writable、enumerable、configurable 等信息。这是字典模式额外占用内存的原因之一——快属性模式下，这些信息通过隐藏类统一描述，不需要每个槽位单独存储。

二、哈希函数与冲突处理

V8 对字符串键使用自定义哈希算法（类似 MurmurHash 的变种），把键映射到桶位置：

桶位置 = hash("b") % 容量

当两个键映射到同一个桶（哈希冲突），V8 使用线性探测（Linear Probing）：从冲突位置开始，依次检查下一个桶，直到找到空桶或目标键：

// 假设 "b" 和 "x" 都映射到桶 2
桶 2: { key: "b", value: 2 }
桶 3: { key: "x", value: 99 }  ← "x" 被线性探测到桶 3

// 查找 "x" 的过程：
// 计算 hash("x") % 容量 = 2
// 检查桶 2：key 是 "b" 不匹配 → 继续
// 检查桶 3：key 是 "x" 匹配 → 返回 value 99

线性探测的优点是内存连续（探测序列在相邻内存），对 CPU 缓存相对友好。缺点是聚集效应（Clustering）：一旦某块区域键很多，新键也容易聚集到这块区域，导致探测步数增加。

三、V8 对字典模式做的优化

字典模式虽然放弃了快属性的结构优化，但 V8 并没有完全放弃对它的优化：

优化一：内联缓存仍然有效（但能力受限）

即使对象处于字典模式，内联缓存（IC）也会尝试缓存属性访问结果。字典模式下，IC 缓存的是”这个对象当前字典里，这个键的槽位位置”——只要对象的字典没有被重哈希，下次访问同一个键可以跳过哈希计算，直接到缓存的槽位。

限制：字典发生扩容/缩容（重哈希）后，所有槽位位置都变了，IC 缓存失效。

优化二：for...in 的专用迭代器

for...in 需要遍历对象的所有可枚举属性，包括原型链上的。V8 为字典模式对象的 for...in 提供了专用迭代器，直接遍历 NameDictionary 的槽位，跳过空桶和删除标记，效率比通用属性遍历高。

优化三：预分配容量

创建字典时，V8 会预留额外容量，减少早期扩容的频率：

初始创建 1 个属性 → 分配 8 个桶的 NameDictionary
添加到 5-6 个属性 → 填充率约 70% → 扩容到 16 个桶

预分配减少了前期的扩容操作，但初始内存占用比快属性模式高。

四、字典模式的性能天花板

尽管有这些优化，字典模式有一些快属性模式无法克服的结构性限制：

限制一：每次属性访问都有哈希计算开销

即使内联缓存命中，字典模式也需要验证缓存是否仍然有效（字典是否被重哈希）。快属性模式的隐藏类 + 偏移量访问，没有这个验证步骤。

限制二：TurboFan 对字典模式对象的优化能力有限

TurboFan 擅长优化结构稳定的对象（快属性），可以根据隐藏类生成高度专用的机器码。对字典模式对象，TurboFan 无法做同等程度的静态分析，生成的代码更通用，速度更慢。

限制三：内存开销更大

快属性模式：
  隐藏类（多个对象共享）+ 紧凑的值数组

字典模式：
  每个对象独立的 NameDictionary
  每个槽位：key + value + attributes（3 个字段 vs 快属性的 1 个字段）
  + 哈希表本身的预留空间（容量 > 实际使用量）

对于大量结构相同的对象，字典模式的内存开销可能比快属性模式高几倍。

五、字典模式也适用的场景

字典模式不是纯粹的负面结果。有些场景中，字典模式是合理的选择：

// 小型配置对象，创建一次，访问次数有限
const config = {};
config[getKeyFromServer()] = getValue(); // 键不确定，无法预定义
// 字典模式的开销与访问次数的少量相比，影响可忽略

// 大量动态属性（几十到几百个）
const store = {};
for (const item of apiData) {
  store[item.id] = item; // 属性数量多，快属性模式也会自动降级
}
// 对于这类场景，直接用 Map 会更可预测
const map = new Map();
for (const item of apiData) {
  map.set(item.id, item); // Map 专为此设计，性能更稳定
}

六、诊断：对象是否处于字典模式

// 开发/调试时使用，生产环境不要用（需要特殊启动标志）
// node --allow-natives-syntax your-script.js

function checkMode(obj, label) {
  console.log(`${label}: ${%HasFastProperties(obj) ? '快属性' : '字典模式'}`);
}

const a = { x: 1, y: 2 };
checkMode(a, '初始'); // 快属性

delete a.x;
checkMode(a, 'delete 后'); // 可能是字典模式

const b = {};
for (let i = 0; i < 200; i++) {
  b[`key${i}`] = i; // 大量属性
}
checkMode(b, '大量属性'); // 字典模式

七、总结

字典模式是 V8 在对象结构不稳定时的妥协方案。它用灵活性换取了一定的性能代价：每次属性访问比快属性多了哈希计算的步骤，TurboFan 的优化能力受限，内存开销更大。

V8 在字典模式上也做了针对性优化（IC 缓存、专用 for...in 迭代器、预分配容量），但这些优化都有固有上限，无法弥补快属性的结构优势。

实践建议：

避免触发字典模式的操作（频繁 delete、大量动态属性）
必须动态增删的场景，直接用 Map 替代对象——Map 的设计天生适合动态键值对，不依赖隐藏类，无字典模式问题
诊断性能瓶颈时，用 %HasFastProperties 验证关键对象是否意外进入了字典模式

本系列其他文章：