javascript 运行时无法直接获取 gc 触发次数，但可通过 chrome devtools 的 performance、memory 面板及 performance.memory 采样，结合 gc 条识别、快照对比、分配采样和内存曲线分析，推断 gc 频次、定位高频分配源头与内存滞留问题。
JavaScript 运行时无法直接获取垃圾回收（GC）的触发次数或频率，因为 V8 引擎不暴露 GC 的公开 API。但可以通过 Chrome DevTools 和运行时指标组合观察、推断和量化 GC 活动的频次与模式。
用 Performance 面板识别 GC 事件密度
这是最直观、可复现的方式，适合定位“高频 GC”问题：
- 打开 Chrome DevTools → Performance 面板，勾选 Memory 和 JavaScript samples
- 点击录制（●），执行目标操作（如快速滚动、高频渲染、表单输入等）
- 停止后查看时间轴：蓝色垂直条代表 V8.GC（全堆回收），浅绿色条为 V8.GCIncrementalMarking（增量标记）
- 若在短时间（如 1 秒内）出现多个密集 GC 条，说明新生代 Scavenge 频繁；若间隔较长但单次耗时 >20ms，则可能是老生代 Major GC
- 配合顶部内存曲线观察：GC 后 JS Heap 是否明显回落？回落幅度小且紧接下一次 GC，提示对象存活率高、回收效率低
用 Memory 面板 + 手动 GC 触发验证回收节奏
适用于判断某段逻辑是否引发“不可控的回收压力”：
- 在 Memory 面板中选择 Heap snapshot，先拍一个基线快照（Snapshot 1）
- 执行易分配对象的操作（例如循环创建 500 个对象或调用 10 次数据映射）
- 点击左上角垃圾桶图标（Collect garbage），强制触发一次 GC
- 立即再拍快照（Snapshot 2），切换到 Comparison 视图，筛选 “Objects allocated between Snapshot 1 and 2”
- 若大量临时对象未被释放（尤其是 Distance = 1 且 Retained Size 显著），说明它们被强引用滞留，迫使 GC 反复尝试回收却无效，表现为“伪高频”
用 Allocation Sampling 定位高频分配源头
GC 频率本质由对象分配速率驱动。找到谁在“狂造对象”，就等于找到了 GC 频繁的根因：
- Memory 面板中选择 Allocation sampling → Start
- 复现用户交互（如拖拽、动画帧循环、列表刷新）
- 停止后按 Count 或 Size 排序调用栈，重点关注顶层函数（如
render()、updateItem()、map(() => ({}))） - 高频出现的
Object、Array、Closure构造行为，往往是 GC 压力来源；例如每次滚动都新建坐标对象，就会导致每帧触发 Scavenge
用 performance.memory 辅助趋势判断
虽不能精确计数，但可用于发现 GC 频繁的宏观信号：
- 定期采样
performance.memory.usedJSHeapSize，记录其波动幅度与回落速度 - 若内存曲线呈“锯齿状”：快速上升 → 小幅回落 → 快速上升 → ……，说明 GC 在频繁清理小对象（Scavenge 主导）
- 若曲线呈“阶梯式上涨”：每次操作后内存回落点持续抬高，说明有对象未被释放，GC 不得不更频繁介入尝试回收
- 建议采样间隔 ≥1000ms，避免干扰主线程
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
