V8引擎通过动态选择内部表示形式优化数组存储，依据使用特征在快数组（连续内存）、空洞数组（HOLEY）和字典模式（哈希表）间智能切换；快数组默认启用，空洞导致不可逆降级，字典模式用于稀疏或混杂场景，扩容按1.5倍预分配，收缩需满足容量超长度假设条件。
V8 引擎对 JavaScript 数组的内存存储优化，核心在于**动态选择最合适的内部表示形式**，而非统一用某种结构硬套。它不是简单地把数组当“连续块”或“哈希表”，而是根据数组的实际使用特征，在多种底层模式间智能切换，兼顾速度、空间与灵活性。
快数组（Fast Elements）：默认高效路径
新创建的数组（如 [] 或 [1, 2, 3]）默认进入快数组模式，底层是连续内存块（类似 C++ vector）。这种结构支持 O(1) 索引访问，前提是：
- 索引从 0 开始、连续递增（无空洞）
- 元素类型尽量单一（如全是小整数 SMI，会触发
PACKED_SMI_ELEMENTS，这是最快类型） - 长度不过大（通常在几万以内，超大会触发降级）
空洞（Holes）与降级：性能拐点的关键
只要数组中出现“空洞”——比如 arr[100] = 'x' 而中间未赋值，V8 就会从 PACKED 切换为 HOLEY 类型（如 HOLEY_SMI_ELEMENTS）。这不是错误，但访问效率下降约 20%–30%，因为引擎需额外检查该位置是否存在值。
更关键的是：这种降级不可逆。即使你后续删掉那个大索引、清空数组，V8 也不会自动切回 packed 模式。
立即学习“Java免费学习笔记（深入）”；
字典模式（Dictionary Mode）：稀疏或混杂时的兜底方案
当数组极度稀疏（比如只有几个元素但最大索引达百万）、或元素类型高度混杂（数字、字符串、对象、函数全都有），V8 会彻底放弃连续存储，转为哈希表结构（DICTIONARY_ELEMENTS）。此时：
- 内存占用更省（不用预留大片空白）
- 但每次
arr[i]都要走哈希查找，时间复杂度退化为平均 O(1)，但常数因子显著增大 - 常见于手动设置超大索引、或频繁 delete 元素后又 push 的场景
扩容与收缩：背后有策略，不是简单 realloc
数组动态增长时，V8 不是每次 push 都重新分配内存。它采用预分配策略：
- 扩容公式：新容量 ≈ 当前长度 × 1.5 + 16（避免频繁重分配）
- 收缩条件：当已分配容量 >
length × 2 + 16时才真正缩容；否则保留空间，用“holes”标记未初始化位置 - 这意味着
arr.length = 0并不释放内存，只是逻辑清空
