大对象直接进入老生代，绕过新生代Scavenge算法，导致回收延迟、Mark-Sweep/Compact开销增大，易引发主线程阻塞；应通过拆分处理、复用缓冲区、扁平化结构和及时解除引用等策略主动控制。
大对象在 V8 中不会走常规的新生代路径，而是直接绕过复制算法，进入老生代内存空间。这种“跳级分配”看似省事，实则埋下性能隐患——它让本该快速回收的临时数据，变成需要长时间标记、扫描甚至整理的沉重负担。
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
大对象直接进入老生代
V8 对新生代内存有硬性限制（通常为 1–8 MB），任何单个对象超过阈值（如一个 1MB 的 TypedArray 或含 10 万条记录的数组），引擎会跳过新生代，直接在老生代分配空间。这意味着： • 它从诞生起就失去 Scavenge 算法的高效清理机会； • 即使只用一次、几秒后就丢弃，也要等到下一轮 Full GC 才可能被回收； • 频繁创建这类对象，容易推高老生代占用，触发更频繁的 Mark-Sweep，拖慢主线程。
老生代回收代价显著更高
老生代使用 Mark-Sweep + Mark-Compact 算法，其耗时与存活对象数量强相关： • 标记阶段需遍历整个老生代堆，大对象本身体积大、引用链深，会延长标记时间； • 清除后易产生内存碎片，后续 Mark-Compact 还要移动对象、重排内存，进一步增加延迟； • 实测显示，释放一个 500MB 对象可能阻塞主线程 300ms 以上，相当于丢失约 5 帧动画。
避免隐性晋升的实用策略
不是所有“大”都必须进老生代，关键在于控制对象生命周期和结构： • 拆分处理：把 10 万条数据的数组改为流式分块（如每次处理 1000 条），用小对象替代单一大对象； • 复用缓冲区：对图像、音频等二进制数据，优先使用 ArrayBuffer + TypedArray，并在不再需要时显式置 null； • 避免深层嵌套：扁平化数据结构（如用 Map 替代多层嵌套对象），减少引用跳转开销； • 监控实际大小：用 performance.memory 或 Chrome DevTools 的 Memory 面板定期检查堆中大对象分布。
主动干预比等待 GC 更可靠
V8 不保证立即回收，尤其对老生代。开发者能做的不是“等它收”，而是“帮它减”： • 及时解除引用：处理完大对象后，将其变量赋值为 null 或 undefined； • 清理闭包捕获：避免函数无意中持有大对象的引用（例如事件回调中闭包引用了整个数据集）； • 谨慎使用全局缓存：缓存大对象前评估必要性，设置明确的淘汰策略（如 LRU + size 限制）； • 在合适时机调用 chrome.runtime.gc()（仅限 Chrome 扩展）或触发手动快照辅助诊断，但不可依赖其强制回收。
