GC日志是JVM调优最直接可信依据，需重点分析GC类型、触发原因（如Allocation Failure、Ergonomics）、内存变化（晋升量、老年代释放量）及停顿时间（real值），据此定位Eden过小、Survivor不合理、内存泄漏或元空间不足等问题。
GC 日志是 JVM 性能调优最直接、最可信的依据，它不依赖采样、不丢失时间序列、不掩盖偶发问题。调优不是靠猜参数，而是从日志里读出 JVM 正在“真实经历什么”。
看 GC 类型和触发原因，判断内存分配是否健康
日志中像 [GC (Allocation Failure)] 或 [Full GC (Ergonomics)] 这类括号里的内容，就是 GC 的“病因”。
- Allocation Failure 频繁出现 → Eden 区太小或对象创建速率过高
- Ergonomics 触发 Full GC → JVM 自动调优失败，老年代已逼近极限
- System.gc() 出现 → 代码里有显式调用，需排查并移除
- G1 Evacuation Pause 后紧接 mixed → G1 正在清理老年代分区，属正常；若 full 出现 → G1 回退到单线程 Full GC，严重告警
盯住内存变化数字，识别晋升与泄漏模式
关键要看三组“回收前→回收后(总容量)”结构：
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 年轻代行：如 PSYoungGen: 8192K->1024K(9216K) → 回收掉 7MB，说明存活对象仅 1MB，合理
- 整堆行：如 78656K->67890K(256000K) → 年轻代回收后，老年代多了约 60MB → 对象大量晋升，需查晋升阈值（-XX:MaxTenuringThreshold）或 Survivor 区是否过小
- 老年代行：如 PSOldGen: 102400K->102399K(102400K) → 几乎没释放 → 典型内存泄漏信号，配合堆转储可定位对象
分析停顿时间与频率，评估 STW 影响
每条日志末尾的 [Times: user=0.09 sys=0.01, real=0.02 secs] 中，real 就是应用卡顿的真实毫秒数。
- Minor GC 超过 50ms → 新生代可能过大，或存在大对象直接进老年代
- Full GC 单次 > 1s → 必须干预，常见于元空间爆满、堆碎片、CMS 失败或 G1 回退
- Young GC 间隔
- Full GC 每小时 ≥ 3 次 → 老年代已失守，优先检查缓存未清理、监听器未注销、静态集合滥用
结合工具做趋势分析，让问题浮出水面
单条日志只能看瞬时状态，批量日志才能暴露规律。推荐用 GCViewer 或 GCEasy 导入 gc.log：
- 画出 Heap Usage Over Time → 若老年代使用率持续爬升不回落，基本锁定泄漏
- 查看 Pause Time Distribution → 若出现长尾（如 95% 500ms），说明有异常大对象或 CMS 并发失败
- 统计 GC Cause 分布 → 若多数是 Metadata GC Threshold → 元空间不足，加 -XX:MaxMetaspaceSize
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
