内存碎片是标记-清除GC后存活对象分散导致的空闲空间不连续现象，引发分配失败、内存虚高和GC效率下降；V8通过空闲期压缩缓解，开发者应复用大对象、减少波动并及时解引用。
JavaScript 中的内存碎片化，是指堆内存中空闲空间被分割成大量不连续的小块，导致虽有足够总容量，却无法分配较大连续对象的现象。它不是由开发者直接写代码造成，而是垃圾回收（尤其是标记-清除算法）反复执行后自然产生的副作用。
内存碎片是怎么产生的
现代 JavaScript 引擎（如 V8）主要采用标记-清除（Mark-and-Sweep）进行老生代回收。该算法分两步：先从根对象出发标记所有可达对象；再统一清除未标记对象，但不移动存活对象的位置。多次回收后，存活对象像岛屿一样散落在堆中，它们之间的空隙大小不一、彼此隔离——这些就是内存碎片。
- 例如：某次 GC 后，堆中留下三块空闲区域，大小分别为 128KB、64KB、32KB；此时若需分配一个 200KB 的 ArrayBuffer，即使总空闲达 224KB，也无法满足，只能触发另一次 GC 或向系统申请新内存。
- 碎片化在长期运行、频繁创建/销毁大对象（如 Canvas 帧数据、大型 JSON 解析结果、临时数组）的应用中尤为明显。
对长期运行应用的实际影响
碎片本身不会立即报错，但会通过三种方式持续拖慢应用：
- 分配失败引发额外 GC：当引擎无法找到足够连续空间时，会提前触发更耗时的老生代 GC（Major GC），打断主线程，造成卡顿或帧率下降。
- 内存占用虚高：碎片区域无法复用，引擎可能被迫向操作系统申请更多内存页，导致任务管理器中看到的 JS 堆内存持续上涨，甚至触发浏览器内存限制警告。
- 间接加剧内存泄漏感知：碎片多时，GC 效率下降，本可回收的对象可能因扫描延迟或压缩缺失而滞留更久，掩盖真实泄漏点，让排查变得更困难。
V8 如何缓解碎片问题
V8 并非放任碎片积累。它在特定条件下会启动内存压缩（Compaction）——将存活对象向堆的一端集中移动，腾出大块连续空闲空间。但压缩是昂贵操作，只在以下情况谨慎触发：
立即学习“Java免费学习笔记（深入）”；
- 老生代内存使用率超过阈值（如 70%）且碎片比例显著升高；
- 最近几次 Major GC 回收效果变差（释放量减少）；
- 应用处于空闲期（如页面不可见、无用户交互）以降低对体验的影响。
注意：压缩不是每次 GC 都发生，也不是实时进行。因此开发者仍需主动规避加剧碎片的行为。
开发者可做的实际优化
虽然无法消除碎片，但可通过控制对象生命周期和分配模式，显著延缓其恶化：
- 复用大对象：避免频繁 new ArrayBuffer、new Array(100000)；改用对象池（Object Pool）或 resize 已有数组/TypedArray。
- 减少短期大对象波动：图像处理、音视频帧等场景，尽量固定缓冲区大小，而非每帧都分配新内存。
- 及时解除强引用：尤其注意闭包捕获、事件监听器、定时器回调中对大对象的隐式持有——它们会阻止对象进入新生代并快速释放，被迫留在老生代加剧碎片。
- 监控堆状态：使用 Chrome DevTools 的 Memory 面板录制堆快照，重点关注“JS Heap”增长趋势与“Fragmentation”指标（可通过 v8.getHeapStatistics() 查看 total_heap_size、total_heap_size_executable、heap_size_limit 等字段辅助判断）。
