阅读JavaScript标准库源码：Array与Promise的实现细节

阅读现代 JavaScript 引擎的标准库源码，是理解语言规范行为与底层执行性能分界线的最高效途径。在大多数开发者的日常编码中，Array 与 Promise 是使用频率最高的两组内置对象，但在底层它们却遵循着完全不同的系统设计哲学：数组追求高密度的连续内存与极致的分支指令优化，而 Promise 则依赖轻量结构体与确定性的微任务事件循环排队。本文以 Google Chrome / Node.js 所采用的 V8 引擎为核心观察对象，拆解 Array 与 Promise 在 Torque 语言与底层 C++ 中的具体源码实现细节，理清它们如何平衡动态类型与执行性能。

定位内置源码：V8 中的 Builtins 组织方式

很多初学者尝试在 V8 仓库中查找标准库时，会直接搜索 .js 文件，但实际上 V8 早已将几乎全部标准库实现从纯 JavaScript 迁移到了 Torque（文件后缀为 .tq）以及 CodeStubAssembler (CSA)。Torque 是一种为 V8 深度定制的强类型领域特定语言，它在编译期生成高效的汇编指令或中间代码，既保持了可读性，又消除了传统 JS 自举时的性能损耗与作用域污染。

在 V8 源码目录（v8/src/builtins/）中，标准库实现按照特性划分为不同模块：

• src/builtins/array-*.tq：包含 push, pop, slice, join 等绝大多数数组原型方法的核心快慢分支逻辑；
• src/builtins/promise-*.tq：包含 Promise 构造函数、then、resolve、reject 以及微任务反应队列的处理流程；
• src/objects/elements-kind.h 与 src/objects/js-array.h：定义了数组对象的内部内存布局与元素存储种类（ElementsKind）的枚举；
• src/objects/promise.h：定义了 JSPromise 对象的 C++ 数据结构与底层标志位。

Array 的底层实现：ElementsKind 与内存自适应

JavaScript 规范中的数组表现为一种键为整数、长度动态自增的“特殊对象”。如果引擎严格将它实现为字典（哈希表），那么每次索引访问都将产生哈希计算与冲突解决开销，性能将极其低下。为此，V8 在底层对数组的存储实施了极度细致的分层优化，核心机制就是 ElementsKind。

1. 内存存储模式与单向状态机

在 V8 的 JSArray 结构中，对象本身只包含两个关键属性槽位：elements（指向底层承载连续数据的 FixedArray）以及 length。根据当前数组内存储的值类型与密度，ElementsKind 分为以下主要状态：

• PACKED_SMI_ELEMENTS：紧凑存储 31 位/32 位有符号小整数（Smi，Small Integer）。不需要进行指针解引用与浮点装箱，直接以原生字长连续存放。
• PACKED_DOUBLE_ELEMENTS：当向 Smi 数组中写入第一个浮点数（如 3.14）时，数组会被升级为存储未经装箱的 IEEE-754 双精度浮点数组。
• PACKED_ELEMENTS：当向数组中写入对象、字符串或函数等引用类型时，存储池变为包含指针引用的对象数组。
• HOLEY 变种（HOLEY_SMI / HOLEY_DOUBLE / HOLEY_ELEMENTS）：如果在数组中留出未初始化的“空洞”（孔洞，如 const a = []; a[5] = 1），数组就会退化为带有空洞标志（the_hole 哨兵对象）的模式。
• DICTIONARY_ELEMENTS：当数组极其稀疏（例如 a[1000000] = 1）或被调用了 Object.preventExtensions() 等破坏性操作时，连续内存被释放，退化为哈希字典存储模式。

2. 原型方法在 Torque 中的快慢分流：以 Array.prototype.push 为例

打开 src/builtins/array-push.tq，可以观察到 V8 是如何处理数组追加元素的。其核心逻辑并非简单的动态扩容，而是严密的防御式分支校验：

// 摘录自 V8 src/builtins/array-push.tq (概念逻辑精简)
transitioning macro ArrayPushFast(
    implicit context: Context)(receiver: JSArray, elements: FixedArray,
    newLength: Smi): void {
  // 1. 检查底层连续数组容量是否足够
  const capacity = elements.length;
  if (newLength <= capacity) {
    // 快速分支：直接计算偏移写入内存，并更新 length 字段
    StoreFixedArrayElement(elements, newLength - 1, value);
    receiver.length = newLength;
    return;
  }
  // 容量不足时：调用通用扩容例程 (GrowCapacityByFactor)
  // 遵循黄金分割扩容原则 (通常为 new_capacity = old_capacity + (old_capacity >> 1) + 16)
}

当满足以下任一条件时，push 会脱离 Torque 快速路径，直接回退到缓慢的运行时通用函数（Runtime::kArrayPush）：

1. receiver 不是原生 JSArray（例如在伪数组类对象上通过 Array.prototype.push.call(obj, 1) 调用）；
2. 原型链上被定义了只读属性，或被 Object.freeze() 冻结；
3. 原型链上存在同名整型属性的访问器（Getter/Setter），修改可能触发原型副作用。

Promise 的底层实现：状态机与反应作业（Reactions）

与数组强调内存密集存储不同，Promise 在引擎内部是一套遵循 ECMAScript 规范严格编排的状态机与异步任务驱动器。规范要求 Promise 必须具备三种状态且只能发生一次不可逆跃迁，同时所有的 then 回调必须在微任务阶段以 FIFO（先进先出）的顺序执行。

1. JSPromise 的内部字段定义

在 V8 C++ 源码的 src/objects/promise.h 中，一个 JSPromise 实例包含以下关键私有槽位（Slots）：

• reactions_or_result：当 Promise 处于 Pending 状态时，该字段是一个单向链表或数组，依次记录调用 .then() 时挂载的 PromiseReaction 节点；一旦 Promise 进入 Fulfilled 或 Rejected 状态，该字段被就地复用，直接存储最终的解析值（Result）或拒绝原因（Reason）。这种结构极大地复用了内存槽位；
• flags：一个 32 位整型位域，包含 status（0 表示 Pending，1 表示 Fulfilled，2 表示 Rejected）、has_handler（标记该 Promise 是否绑定过 catch 处理函数，用于未捕获异常监控）以及调试器标识。

2. Promise.prototype.then 与微任务排队源码剖析

在 src/builtins/promise-then.tq 中，then 方法的核心调用为 PerformPromiseThen。源码逻辑清晰地展现了以下判断：

// 摘录自 V8 src/builtins/promise-then.tq (概念逻辑精简)
transitioning builtin PerformPromiseThen(
    implicit context: Context)(
    promise: JSPromise, onFulfilled: Callable|Undefined,
    onRejected: Callable|Undefined, resultPromise: JSPromise): JSAny {
  
  // 1. 获取当前 Promise 的状态位
  const status = promise.Status();

  // 2. 如果当前 Promise 仍处于 Pending
  if (status == PromiseState::kPending) {
    // 构造新的 PromiseReaction 结构体
    // 将 onFulfilled / onRejected / resultPromise 打包并挂入 promise 的反应链表
    const handler = AllocatePromiseReaction(
        promise.reactions_or_result, onFulfilled, onRejected, resultPromise);
    promise.reactions_or_result = handler;
  } 
  // 3. 如果当前 Promise 已经稳定 (Fulfilled 或 Rejected)
  else {
    // 不再挂载链表，直接向当前 Isolates 的微任务队列派发 Job
    const result = promise.reactions_or_result;
    if (status == PromiseState::kFulfilled) {
      EnqueuePromiseFulfillReactionJob(resultPromise, result, onFulfilled);
    } else {
      EnqueuePromiseRejectReactionJob(resultPromise, result, onRejected);
    }
  }
  return resultPromise;
}

从源码逻辑中可以看出一个重要的执行特征：即便一个 Promise 已经处于 Fulfilled 状态，调用 .then(cb) 依然不会同步执行回调，而是通过 EnqueuePromiseFulfillReactionJob 将执行动作包装成一个独立微任务放入微任务队列。这完全契合了 Promise/A+ 规范中对“异步执行”的确定性约束。

3. Promise.resolve 的 Unwrap 扁平化机制

另一个在源码中非常具有代表性的逻辑是 PromiseResolve。许多开发者容易混淆 new Promise(resolve => resolve(otherPromise)) 与直接 Promise.resolve(otherPromise) 的行为差异：

• 如果传给 Promise.resolve() 的参数本身就是原生的 JSPromise 实例，且其构造器指向标准的全局 Promise，V8 会在 promise-resolve.tq 中直接走短路返回该实例自身，不发生任何额外对象分配；
• 如果在一个已经存在的 Promise 的 resolve() 中传入另一个 Promise 或带有 then 方法的对象（Thenable），引擎必须启动规范中的 PromiseResolveThenableJob 流程。这个过程需要额外消耗至少两个微任务轮次来执行展开操作（Unwrap），以确保外部状态与传入对象的最终落地状态同步。

源码机制带来的工程启示与性能总结

深入标准库源码不仅能够解释“为什么这段代码会这样输出”，还能为编写高吞吐量的高性能代码提供明确的准则：

• 保持数组元素类型的均一性：避免在一个数组中混用整型数字、浮点数与对象。如果初始化为整型数组，尽量始终写入整数；频繁混合类型将引发不可逆的 ElementsKind 降级，迫使 JIT 编译器（如 TurboFan）放弃基于偏移量直接寻址的紧凑机器指令。
• 避免随手制造稀疏数组：尽量不要使用 delete arr[index] 删除数组元素（这会在该槽位写入 the_hole 导致数组退化为 HOLEY 模式），推荐使用 splice 或重新构造密集数组；也不要直接跳跃设置大索引，避免触发 DICTIONARY_ELEMENTS 降级。
• 审慎理解微任务交替粒度：在编写复杂的异步流程或单元测试时，不要随意依赖“微任务在下一个事件轮次立刻同步完成”的假设。一旦涉及嵌套 Promise 的 resolve 链式展开，V8 会在底层严格调度 PromiseResolveThenableJob，带来多微任务步长的推迟。

通过阅读 V8 标准库源码可以清楚地发现，JavaScript 在高层呈现的“自由灵活”与底层展现的“高度规范”之间，依靠的是精巧的状态机迁移与自适应内存模式。理解了 Array 的连续内存与 ElementsKind，开发者就能写出让 JIT 编译器无需兜底的高性能数据结构；理解了 Promise 的槽位复用与 PromiseReaction 微任务机制，开发者就能在复杂的异步协作中准确预测执行时序，写出更鲁棒的前端与服务端应用。