V8引擎将超过1MB的大对象直接分配至大对象区，避免Scavenge复制开销；该区独占内存页、不移动对象、仅标记-清除回收，并需开发者注意及时解除引用以防内存泄漏。
V8 引擎对大对象的分配和回收有专门的处理路径，不走新生代的 Scavenge 流程，而是直接进入大对象区（Large Object Space），避免频繁复制带来的性能开销。
大对象的判定标准
V8 将“大对象”定义为体积超过 一个内存页大小（通常约 1MB） 的对象。例如：
- 超长字符串（如 Base64 编码的几 MB 图片数据）
- 大型 TypedArray（如
new Uint8Array(2 * 1024 * 1024)） - 深度嵌套或字段极多的对象字面量（实际少见，但可能触发）
大对象区的内存管理特点
该区域独立于新生代和老生代，具有以下关键行为：
- 每个大对象独占一个连续内存页，不与其他对象共享空间
- 分配时直接在操作系统层面申请整页内存（mmap 或 VirtualAlloc）
- 垃圾回收时不移动、不复制，只做标记-清除：一旦对象不可达，整页内存被立即释放归还系统
- 不参与晋升机制——它既不从新生代来，也不会升到老生代
为什么跳过新生代？
Scavenge 算法依赖快速复制存活对象。若将大对象放入 From/To 空间：
立即学习“Java免费学习笔记（深入）”；
- 一次复制就需搬运数 MB 数据，严重阻塞主线程
- To 空间未必有足够连续空间容纳它
- 违背“新生代应轻量高效”的设计初衷
开发者注意事项
虽然 V8 自动处理，但不当使用仍易引发问题：
- 避免反复创建/丢弃大数组或大字符串（如循环中
JSON.stringify(bigData)） - 用完后及时解除引用（
largeArray = null），否则标记-清除阶段无法识别其不可达 - 对持续增长的大对象（如日志缓冲区），考虑分块或流式处理，而非累积到单个实例
