监控gc耗时需在performance面板勾选memory和javascript samples后录制，通过火焰图识别v8.gc（≤1ms）、v8.gcincrementalmarking（增量标记）和v8.gcmarksweepcompact（5–20ms+），再结合memory面板观察内存曲线锯齿与手动gc快照对比定位抖动根源。
监控垃圾回收（GC）耗时，核心是捕获 GC 事件的触发时机与执行时长，而不是等卡顿发生后再回溯。Chrome DevTools 提供了直接可观测的底层指标，关键在于用对面板、选对录制配置、读懂时间轴信号。
Performance 面板抓取 GC 实际耗时
这是最直观、最可靠的方式：
- 打开 Chrome DevTools → Performance 面板 → 勾选 Memory 和 JavaScript samples（必须勾选，否则看不到 GC 类型和堆栈）
- 点击录制按钮，执行一段易触发 GC 的操作（如快速滚动长列表、高频渲染帧、连续创建对象）
- 停止录制后，在时间轴下方查看主线程火焰图：
– 浅蓝色竖条代表 V8.GC（Scavenge，新生代回收），通常 单次 ≤ 1ms
– 浅绿色竖条代表 V8.GCIncrementalMarking（增量标记），说明老生代正在分片处理
– 深绿色长条代表 V8.GCMarkSweepCompact（老生代全量回收），单次常达 5–20ms+，是卡顿主因 - 鼠标悬停在 GC 条上，可看到精确毫秒数（如 “Duration: 12.4 ms”）以及触发前紧邻的 JS 函数（如
renderItems或updateState）
Memory 面板辅助验证 GC 频率与压力
Performance 看“单次耗时”，Memory 看“是否过载”：
- 切换到 Memory 面板 → 选择 Heap snapshot 或 Allocation instrumentation on timeline
- 录制过程中观察顶部内存曲线：
– 若出现密集锯齿（快速上升 + 急剧回落），说明 Scavenge 频繁，新生代压力大
– 若内存回落缓慢、每次 GC 后仍高位横盘，说明有对象滞留或持续分配，可能逼近老生代晋升阈值 - 点左上角垃圾桶图标手动触发一次 GC，再立即拍快照：对比前后，若 Objects allocated between snapshots 中大量小对象（Object/Array）Distance 为 1 且 Retained Size 不为 0，就是抖动证据——GC 耗时高正是因为它反复被逼着干活
代码中粗略感知 GC 压力（仅限开发/测试环境）
注意：performance.memory 在生产环境常被禁用，不可用于线上监控，但可用于本地压测预警：
- 通过
performance.memory获取堆使用率，间接反映 GC 压力趋势：const usage = performance.memory.usedJSHeapSize / performance.memory.jsHeapSizeLimit; - 当 usage > 0.7 且持续上升时，V8 很可能已启动更激进的 GC 策略（如提前触发 Mark-Sweep）
- 配合
console.time('gc-impact')在疑似重逻辑前后打点，虽不能测 GC 本身，但能暴露“某段 JS 执行后总伴随长 GC”，从而定位源头
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
