新生代GC触发条件是From空间占满即触发Scavenge回收；老生代GC触发条件包括：老生代内存占用达阈值、新生代对象晋升时老生代空间不足、手动调用global.gc()。
新生代 GC 触发条件很直接：From 空间一满就回收
新生代 GC 不依赖全局内存占用率，只看当前 From space 是否填满。V8 默认新生代堆大小约 1–8 MB（具体取决于平台和启动参数），一旦新对象分配导致 From space 耗尽，立刻触发 Scavenge 回收。
这意味着：哪怕整个 Node.js 进程只用了 50 MB 内存，只要新生代的 From 区被撑爆，GC 就会马上发生。它不等、不预测、不合并——高频但轻量。
- 典型场景：
for (let i = 0; i 这类循环中创建的临时对象几乎全在新生代诞生并快速死亡 - 晋升不是“时间到了”，而是“活过两次 GC”：一个对象在 From→To 复制一次后仍存活，下次 GC 再存活，就会被移到老生代（
survival count ≥ 2） - 如果 To space 不够装下所有存活对象，V8 会提前把部分对象晋升到老生代，避免复制失败——这叫“晋升溢出”，是性能隐患信号
老生代 GC 触发更复杂，但后果更重
老生代 GC 不是空间“满了才动”，而是一套基于使用率 + 晋升压力 + 延迟策略的组合判断。主要触发点有三个：
-
old_space_usage / old_space_capacity > 0.75（默认阈值，可调）——老生代已用超 75%，V8 开始准备标记-清除 - 新生代 GC 时发生大量晋升，且老生代剩余空间不足容纳这些晋升对象，会强制触发老生代 GC 来腾地方
- 长时间未触发 GC（如低负载服务），V8 可能主动做一次轻量标记以更新内存视图，但不会立即清扫
一旦触发，就是 Mark-Sweep 或 Mark-Compact，耗时从几毫秒到上百毫秒不等，且会阻塞 JS 主线程。尤其 Mark-Compact 需移动大量存活对象，CPU 和内存带宽压力明显。
为什么不能靠增大新生代来规避老生代 GC？
增大新生代（如用 --max-new-space-size=8192）看似能减少晋升频率，但实际会放大两个问题：
- Scavenge 时间变长：Scavenge 是 O(存活对象数) 的复制操作，新生代越大，每次复制的存活对象越多，单次 GC 暂停时间上升
- 晋升延迟导致老生代“突然膨胀”：本该早期清理的中生命周期对象（比如缓存里没及时失效的中间数据）被卡在新生代多活几轮，最终一次性涌进老生代，反而加剧后续老生代 GC 压力
- V8 对新生代大小有硬限制（通常不超过 16 MB），设得过高可能被忽略或引发分配失败
真正可控的调优点其实是控制晋升节奏——比如避免闭包意外持有短期对象、及时解除事件监听器引用、用 WeakMap 存储元数据而非强引用。
监控时别只盯 heap_used，重点看 young_gen_size 和 old_gen_size 的比例变化
用 process.memoryUsage() 或 heapdump 抓快照时，heapUsed 总量掩盖了代际失衡。真正危险的信号是：
- 新生代 GC 频率骤降 + 老生代尺寸持续缓慢上涨 → 对象正在“悄悄晋升”，可能是缓存泄漏或闭包引用未释放
- 老生代 GC 后
heapUsed下降很少，但heapTotal明显增大 → 出现内存碎片，V8 启动了Mark-Compact，说明老生代已长期高负载 - 同一段代码在压测中新生代 GC 次数翻倍但老生代 GC 没增加 → 说明对象确实短命，无需干预；反之若老生代 GC 频次上升，则要检查是否误将临时结构挂到了全局或模块级变量上
代际边界不是黑盒分界线，而是你代码中对象生命周期真实分布的投影。看得清晋升路径，才压得住 GC 波动。
