V8引擎如何在碎片化内存中存储数组？其数组数据结构解析

嘿，这个问题问到点子上了——V8对数组的内存处理确实是它性能优化的核心之一，尤其是面对JS这种动态语言的灵活性和内存碎片化的挑战。我来拆解一下你关心的两个核心点：V8的数组到底是什么结构，以及它怎么搞定内存碎片化的问题。

和C语言那种固定的连续内存数组不同，V8里的数组会根据元素的类型、是否存在“空洞”（也就是未赋值的索引，比如arr[5] = 10但0-4没赋值），自动切换内部存储类型，核心目标就是在动态特性和连续内存效率之间找平衡：

• PACKED_SMI_ELEMENTS：存储全是小整数（SMI）——V8对32位以内整数的特殊优化，不需要堆分配，直接存在数组的元素槽里。这种数组的内存是连续的，每个元素占4字节，性能最优。
• PACKED_DOUBLE_ELEMENTS：存储全是双精度浮点数，无空洞。内存连续，每个元素直接存8字节的数值，不用指针，性能也很强。
• PACKED_ELEMENTS：存储混合类型（比如同时有整数、字符串、对象），无空洞。这时候数组的元素槽里存的是指向堆中对象的指针，内存依然是连续的，64位系统下每个指针占8字节。
• HOLEY_xxx_ELEMENTS：如果数组存在空洞，V8会标记为这类类型。内存还是连续的，但未使用的槽会用特殊占位符填充，性能会稍差，因为V8无法做某些编译优化。

你担心的“JS数组没法始终用连续内存”确实是个问题，但V8通过一套组合拳来搞定：

1. 数组扩容：优先找连续空间，找不到就“搬家” #

当你给数组push元素导致需要扩容时，V8会先检查当前数组内存块的后面有没有足够的连续空闲空间。如果有，直接扩展；如果遇到你说的碎片化场景——周围都是已分配的块（●），只有零散的空闲块（○），V8不会去凑那些零散空间，而是在堆的其他区域重新分配一块足够大的连续内存，把原数组的元素全部复制过去，旧的内存块会被标记为垃圾，等待后续GC回收。

2. 垃圾回收：主动整理碎片化内存 #

V8的GC分两个世代处理，都能解决碎片化问题：

• 新生代（Scavenger）：小数组一开始会存在这里，用复制算法——把存活对象从From空间复制到To空间，To空间是完全连续的，复制后自然消除了碎片化。
• 老生代：大数组会进入这里，主要用标记-清除+标记-整理算法。标记-清除会标记存活对象，清除垃圾，但会留下零散的空闲块；当需要分配大的连续内存（比如大数组）时，V8会触发标记-整理：把所有存活对象（包括数组）移动到内存的一端，另一端变成整块的连续空闲区域，后续分配数组就能直接用这块连续空间了。

3. 从根源减少碎片化：尽量保持数组的“紧凑”状态 #

V8会通过类型推断尽量让数组保持PACKED_xxx类型，比如你一开始创建全整数数组，它会用PACKED_SMI_ELEMENTS；如果后来添加了字符串，它会转换为PACKED_ELEMENTS，但内存还是连续的。只有当你创建大量空洞的数组时，才会变成HOLEY类型，这也是为什么写JS时尽量避免空洞数组——不仅性能差，还可能增加内存碎片化的概率。

假设堆内存现在是这样的（每个块8字节）：
● ● ○ ● ○ ○ ●
你的数组需要扩容2个元素（16字节），当前数组后面没有连续的2个○块。这时候V8不会去拼零散的○，而是直接在堆的另一块连续空闲区分配16字节的内存，把原数组元素复制过去，旧内存块被标记为垃圾。等GC运行时，那些零散的○会被整理成连续的大块，供后续分配使用。

总结一下：V8通过按需切换的数组内部结构尽量保证数组用连续内存，再配合GC的复制/整理机制解决碎片化，既兼容了JS的动态特性，又保持了接近静态语言数组的性能。

内容的提问来源于stack exchange，提问作者Lance Pollard