GC Observability是V8提供的一套真实、低干扰捕获Major/Minor GC时机、耗时、影响及原因的能力集合，含运行时参数、性能计数器、调试钩子和内置统计字段；Scavenge为Minor GC，Mark-sweep为Major GC。
理解 V8 的垃圾回收观测器（GC Observability），核心是掌握如何**真实、低干扰地捕获 Major GC 与 Minor GC 的发生时机、耗时、影响范围及触发原因**，而不是依赖黑盒日志或事后推测。
什么是 GC Observability？
它不是某个具体 API，而是 V8 提供的一套可观测能力集合，包括：
运行时参数支持
：如
、
、
，直接输出 GC 类型、阶段、内存前后变化、晋升数量等原始信息；
性能计数器接口
：通过
或 Chrome DevTools 的 Performance 面板，间接观察堆使用趋势与 GC 关联性；
调试钩子机制
：在 d8 或启用
的 Node.js 中，可手动触发 GC 并结合断点定位回收行为；
V8 内置统计字段
：如
（需通过 d8 或 C++ Embedder 调用），返回已执行的 Scavenge（Minor）、Mark-sweep（Major）、Incremental-marking 次数等。
如何区分并识别 Minor GC 与 Major GC 日志
开启
后，每行日志首部明确标注类型：
Scavenge
：即 Minor GC。典型输出如
，只涉及新生代（semi-space），速度快（通常
Mark-sweep
或
Mark-compact
：即 Major GC。输出如
或
，覆盖整个老年代（有时含全部堆），停顿明显；
注意：
不是独立 GC，而是 Major GC 的标记阶段被拆分为多次小任务，日志中会显示
，最终仍需一次
收尾。
关键指标怎么看才有效？
仅看“发生了 GC”没意义，要结合上下文判断是否异常：
Minor GC 频率过高
：比如 100ms 内触发多次
，说明新生代太小或对象创建过快，可能引发 Premature Promotion（对象未经历足够 Minor GC 就升入老年代）；
Major GC 后老生代释放少
：如
区从 92% → 89%，反复如此，大概率存在内存泄漏或缓存未清理；
晋升量突增
：
日志中若出现
单次超大值，意味着大量对象逃逸新生代，需检查长生命周期对象误分配；
停顿时间超标
：Node.js 服务中单次 Major GC > 50ms 可能影响请求延迟，需结合
与实际负载评估是否调参。
实用监控组合建议
生产环境不推荐长期开
（I/O 开销大），可用分层策略：
基础层
：启动时加
+ 定期采样
，记录
与
波动；
诊断层
：问题复现时，用
（Node.js 进程需启用 JMX 或通过
配合 Chrome DevTools 的 Memory 面板）；
深度层
：离线分析 GC 日志，用
GCeasy.io
自动识别 Major/Minor 模式、停顿分布、内存泄漏线索。
--trace-gc--trace-gc-verbose--trace-gc-object-statsprocess.memoryUsage()--expose-gc%GetHeapStatistics()--trace-gc-verbose[Scavenge / 12.3 ms][Mark-sweep / 47.8 ms][Mark-compact / 62.1 ms]IncrementalMarking[IncrementalMarking: ...]Mark-compactScavengeO(Old)--trace-gc-verbosepromotion: 12.4 MB--max-old-space-size--trace-gc-verbose--trace-gcprocess.memoryUsage()heapUsedheapTotaljstat -gc 1000 node --inspect