Chrome Trace Viewer 可显示 V8 垃圾回收事件的时间点、时长和线程上下文，需手动启用 v8.gc 等追踪类别；GC 切片以彩色矩形呈现，Scavenger 表示新生代 Minor GC。
Chrome Trace Viewer 本身不直接显示 V8 垃圾回收（GC）的详细切片，但它能呈现 GC 事件的时间点、持续时长和线程上下文——关键在于正确启用 tracing 并识别 GC 相关的 trace event 类别。
开启包含 GC 事件的完整追踪
默认 Performance 面板录制不包含底层 GC 细节。需手动启用：
- 打开
chrome://tracing，点击 “Record” → “Edit categories” - 勾选：
v8.gc（核心）、v8.runtime、disabled-by-default-v8.gc、disabled-by-default-v8.runtime - 若分析内存压力，额外启用：
disabled-by-default-memory-infra - 开始录制，复现目标操作（如连续创建对象、触发强制 GC），停止后加载 trace
在 Trace Viewer 中定位 GC 切片
GC 事件在时间轴上以带颜色的矩形块呈现，类别为 v8.gc，常见类型包括：
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- Scavenger（浅色蓝/绿）：新生代 Minor GC，通常快（
- Mark-Sweep-Compact（深红）：老生代 Major GC，耗时长（几 ms 到几十 ms），易造成主线程卡顿
- IncrementalMarking（浅灰条纹）：增量标记阶段，分散在多个微任务中，降低单次停顿
- 每个 GC 切片下方会标注耗时（如
12.4ms）、触发原因（allocation failure或scavenge）和所属线程（通常是Main Thread或ThreadPoolForegroundWorker）
结合堆快照交叉验证 GC 效果
仅看 trace 不知 GC 是否真正释放了预期对象。建议联动操作：
立即学习“Java免费学习笔记（深入）”；
- 在 GC 事件前后，用 DevTools Memory 面板手动拍两个堆快照（Heap Snapshot）
- 对比两次快照中相同构造函数的实例数变化，确认对象是否被回收
- 若某类对象数量未降反升，说明存在隐式引用（如闭包、事件监听器、缓存 Map 未清理），trace 中 GC 虽执行但无效
识别 GC 异常模式
通过时间轴密度与分布可快速判断问题：
- 高频短 Scavenger（每 100–200ms 一次）→ 新生代分配过快，检查循环中是否频繁生成临时对象（如
{}、[]、字符串拼接） - 密集出现 Mark-Sweep（间隔
- GC 切片与 JS 执行（
FunctionCall或ScriptEvaluation）严重重叠 → 主线程阻塞导致 GC 推迟，加剧内存堆积
