GCEasy分析GC日志需确保日志完整（JDK8用PrintGCDetails等参数，JDK9+用Xlog结构化日志），重点关注JVM堆大小、KPI指标与自动识别问题，并结合Recommendations调优及jmap/jstat等工具交叉验证。
直接上传 GC 日志到 GCEasy 官网，几秒就能生成可视化报告——关键不是“怎么点”，而是日志要全、报告要看懂、问题要能闭环。
确保日志内容完整可用
日志质量决定分析效果。只加 -verbose:gc 太简略，漏掉晋升、元空间、停顿原因等关键信息。
-
JDK 8 推荐参数组合：
-XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -XX:+PrintTenuringDistribution -Xloggc:gc.log -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=20M -
JDK 9+ 更推荐结构化日志：
-Xlog:gc*:gc.log:time,tags,level,pid,tid -Xlog:safepoint
其中gc*表示开启所有 GC 相关标签（含 heap、age、ref 等），pid,tid便于多线程问题定位 -
避免轮转日志直接上传：GCEasy 目前不支持自动合并多个
gc.log.0, gc.log.1文件；建议单次分析用一个完整日志（如连续运行 1–24 小时产生的单个文件）
上传后快速看懂核心报告板块
报告首页分区块呈现，重点关注以下三块：
-
JVM Heap Size：看年轻代、老年代、元空间的分配量与峰值使用量。
老年代持续缓慢上涨且不回落 → 高度提示内存泄漏；
元空间使用率长期 >90% → 检查类加载是否异常（如大量动态代理、热部署） -
Key Performance Indicators (KPI)：吞吐量（Throughput）、平均暂停时间（Avg Pause GC Time）、最长暂停（Max Pause GC Time）
Web 服务建议 Avg < 50ms，Max < 200ms；批处理可放宽 Avg，但 Max 不宜超 2s -
Problems Detected：GCEasy 自动标出问题，如 “Frequent Minor GC”、“High Old Gen Allocation Rate”、“Possible Memory Leak”
每条都附带原始日志行定位和一句话解释，点击可跳转上下文
参考优化建议并验证
报告底部的 Recommendations 是核心价值之一，中文版目前免费提供基础调优建议：
立即学习“Java免费学习笔记（深入）”；
- 提示 “Young Gen too small” → 建议增大
-Xmn或调整 G1RegionSize - 提示 “Old Gen occupancy high after Full GC” → 检查是否存在大对象直入老年代（如
-XX:PretenureSizeThreshold设置不当） - 提示 “Metaspace usage growing steadily” → 建议增加
-XX:MaxMetaspaceSize或排查 Spring AOP/MyBatis Mapper 类爆炸 - 所有建议都需结合实际业务场景验证：比如调大堆后若停顿反而更长，可能是 GC 算法不匹配，可尝试切换 G1 或 ZGC 并重新采集日志对比
配合其他工具交叉验证
GCEasy 是起点，不是终点。发现线索后需用其他工具确认根因：
- 怀疑内存泄漏？用
jmap -dump:format=b,file=heap.hprof <pid>生成堆转储，再用 HeapHero 分析 Retained Heap 占比高的对象 - 观察实时 GC 行为？运行
jstat -gcutil <pid> 500，关注 S0/S1 是否交替高位（Survivor 区过小）、O 列是否持续 >85% - 排查线程栈抖动？
cat /proc/<pid>/status | grep VmStk查栈内存增长，pstack <pid>看线程数是否异常飙升
