GCEasy不分析变量回收趋势，而是分析堆内存中对象的分配、晋升与GC活动趋势；它通过GC日志识别年轻代分配速率、晋升速率、老年代增长斜率等宏观模式，并评估吞吐量（≥95%为佳）、平均停顿时间等核心指标。
GCEasy 本身不分析“变量”回收趋势，它分析的是对象内存的分配、晋升与回收行为，也就是 JVM 堆中新生代、老年代、元空间等区域的内存使用和 GC 活动趋势。所谓“变量”在 Java 中只是栈上引用，真正被回收的是堆上的对象实例。因此，GCEasy 关注的是对象生命周期的宏观模式，而非单个变量。
识别对象分配与晋升趋势
上传 GC 日志后，在 GCEasy 报告的「GC Interactive View」或「Allocation & Promotion」模块中，可观察以下关键趋势：
- 年轻代分配速率（Allocation Rate）：单位时间（如每秒）新分配的对象字节数。若持续高于 10MB/s 且 Young GC 频繁，说明业务创建对象过快，需检查高频 new、集合扩容、日志/JSON 序列化等场景。
- 晋升速率（Promotion Rate）：每次 Young GC 后进入老年代的对象大小。若该值稳定上升（如从 50KB/GC 增至 500KB/GC），可能预示对象存活时间变长，或 Survivor 区过小导致提前晋升。
- 老年代增长斜率：在「Heap After GC」曲线中，Full GC 之间的老年代占用是否呈线性缓慢上升？若上升陡峭且无 Full GC 清理，可能是内存泄漏；若每次 Full GC 后老年代残留占比长期 >85%，说明老年代空间不足或对象无法释放。
评估 GC 回收效率的核心指标
效率不是看“回收了多少”，而是看“花了多少代价换回多少空间”。重点关注报告中「Key Metrics」和「GC Statistics」板块：
- 吞吐量（Throughput）：正常值应 ≥95%。低于 90% 表明 GC 占用过多 CPU 时间，需调优或排查对象膨胀问题。
- 平均停顿时间（Avg Pause Time）：Young GC 通常应
- 回收比（Reclaimed per GC）：对比「GC Before Heap」与「GC After Heap」差值。例如某次 Young GC 前 Eden 占满 2GB，GC 后仅剩 200MB，则回收了 1.8GB —— 效率高；若只回收 100MB，说明大量对象幸存，Survivor 区可能溢出或对象本就不该在新生代。
- GC 频率与回收量比值：例如 100 次 Young GC 总共只回收 50MB，而其中 80 次都在 10ms 内回收
定位低效根源的实操线索
不要只盯数字，要结合上下文交叉验证：
- 查看「GC Cause」列：若大量 Young GC 原因为 Allocation Failure，说明 Eden 空间吃紧，优先考虑增大 -Xmn 或调整 G1RegionSize；若出现 Promotion Failed，则老年代或 Survivor 已无法承接晋升对象，需检查 -XX:MaxTenuringThreshold 或老年代容量。
- 对照「Object Age Distribution」：若大量对象在 Survivor 中停留 1–2 次 GC 就晋升，说明 -XX:MaxTenuringThreshold 设置过低，或 Survivor 空间不足被迫提前晋升。
- 关注「Metaspace Usage」：元空间持续增长且触发 Metadata GC Threshold 导致 Full GC，说明类加载过多（如热部署、动态代理泛滥），应设置 -XX:MetaspaceSize 和 -XX:MaxMetaspaceSize 并监控类加载数。
辅助验证：结合其他工具交叉确认
GCEasy 是起点，不是终点：
- 发现老年代缓慢上涨 → 用 jmap -histo 或 VisualVM heap dump 查看 Top 对象类名及数量，确认是否为缓存未清理、监听器未注销等典型泄漏模式。
- 怀疑对象创建热点 → 用 Arthas trace 命令追踪高频 new 指令所在方法，定位代码层源头。
- 想验证调优效果 → 修改 JVM 参数后重新生成 GC 日志，用 GCEasy 对比「Throughput」「Avg Pause」「Full GC Count」三项核心指标变化。
