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