V8引擎Smis与HeapNumbers内存解析

V8引擎中Smi（小整数）与HeapNumber（堆数字）看似同属数值类型，实则本质迥异：Smi根本不占用堆内存，而是巧妙地将整数值直接编码在指针的低位，实现零开销、免解引用的高效运算；而HeapNumber是真实分配在堆上的对象，拥有标准的map指针+双精度值的16字节结构，受垃圾回收全程管理。二者唯一共通点仅是利用指针最低位（0/1）作类型标记，但这不是内存布局的相似，而是底层类型区分策略——理解这一根本差异，才能避开隐式装箱导致的性能断崖、去优化陷阱和数组访问模式退化，真正写出V8友好、高性能的JavaScript代码。

Smi 和 HeapNumber 在内存中根本不是同一类东西——前者压根不占堆内存，后者必须分配堆空间；谈“布局异同”容易误以为它们是同类结构的变体，其实连存在位置都不同。

为什么 Smi 没有传统意义上的“内存布局”

Smi（Small Integer）不是对象，不分配堆内存，也不在堆上存储任何字段。它直接编码在指针值里：在 64 位系统中，最低位（LSB）为 0，其余 63 位左移一位后表示整数值（即实际值 = 指针值 >> 1）。比如整数 42 存为指针值 0x54（二进制末位是 0），CPU 拿到这个值，右移一位就得到真实数值，全程无解引用、无内存访问。

这意味着：

• %DebugPrint(42) 会显示 Smi: 0x54，但你找不到它在堆上的地址——它没有堆地址
• 数组 [1, 2, 3] 的元素若全是 Smi，V8 可能用紧凑的整数向量（如 FixedArray）存指针值，每个槽位就是个 uintptr_t，里面直接是编码后的 Smi
• 不存在 Smi::kValueOffset 或类似字段偏移——它没有 C++ 类定义里的成员布局

HeapNumber 真实占用堆内存，有明确对象结构

HeapNumber 是堆上真实分配的对象，继承自 HeapObject，有 map 指针 + value 字段的标准布局。在 64 位 V8 中典型结构如下：

HeapNumber object (16 bytes total):
+---------------------+
| map pointer (8B)    | ← 指向 HeapNumber 的隐藏类
+---------------------+
| value (8B, double)  | ← 实际存储的浮点数值，位于 kValueOffset = 8
+---------------------+

注意：

• 它的地址 LSB 必为 1（因堆地址 8 字节对齐，右移一位后末位补 1 标识堆对象）
• HeapNumber::value() 实际执行的是 READ_DOUBLE_FIELD(this, 8)，即从对象起始地址偏移 8 字节读取 double
• 每次创建 new Number(3.14) 或隐式装箱（如 2147483648）都会触发堆分配，受 GC 管理

二者唯一共性：都通过指针值区分类型

V8 利用指针最低位做类型 tag：0 表示 Smi，1 表示堆对象（含 HeapNumber）。这是唯一可比的“布局规则”，但本质是编码策略，不是内存组织方式。

所以你会看到：

• typeof 42 === 'number' 和 typeof new Number(42) === 'object' —— 运行时类型判断依赖该 tag，但语义完全不同
• %HasSmiValue(x) 返回 true 仅当 x 是未装箱的 Smi；const v = arr[i]; %HasSmiValue(v) 才有效，不能写 %HasSmiValue(arr[i])（表达式求值可能触发临时装箱）
• 混用 | 0、Math.floor 或除法（如 i / 2）会导致索引变成 HeapNumber，让数组访问从 fast mode 切到 slow mode，性能断崖下跌

真正关键的不是记住布局图，而是理解：Smi 是 CPU 寄存器友好的即时值，HeapNumber 是需要 GC 照顾的堆对象。一旦数值运算中出现哪怕一次隐式升格，后续所有路径都可能被去优化——这点在热循环里尤其致命。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《V8引擎Smis与HeapNumbers内存解析》文章吧，也可关注golang学习网公众号了解相关技术文章。