面试分析GC日志关键在于用数据反推配置合理性：一看Minor GC频率与Eden使用率判断年轻代过小，二看Full GC回收率低揭示老年代失衡，三查Metaspace和直接内存溢出线索，四借时间戳链识别负载与配置不匹配。
面试中分析GC日志破除堆内存配置隐患，关键不是背参数，而是用日志反推配置是否合理——看数据，不猜逻辑。
一眼识别年轻代过小：盯住Minor GC频率和Eden回收率
如果日志里频繁出现类似这样的条目：
[GC (Allocation Failure) [PSYoungGen: 102400K->16384K(122880K)] ...]
注意三个数字：回收前Eden使用量（102400K）、回收后剩余（16384K）、Eden总容量（122880K）。若回收前几乎打满（如 >95%），且回收间隔短于2秒，说明Eden区太小。更直接的证据是：连续多次Minor GC后，老年代占用却稳步上升——说明大量对象“躲过”年轻代回收，直接晋升，这是Survivor区过小或MaxTenuringThreshold设置不当的信号。
建议快速判断方式：
- 统计1分钟内Minor GC次数：＞30次 → Eden大概率不足
- 看每次Minor GC后Eden使用率是否长期＞90% → 新生代空间压得过紧
- 对比两次Minor GC间老年代增长量：若单次增长＞5MB → 晋升压力大，需调大Survivor或延长对象年龄阈值
直击Full GC根源：从回收效果反推老年代配置失衡
Full GC日志里最危险的不是耗时长，而是“收效低”。例如：
[Full GC (Ergonomics) [PSOldGen: 1843200K->1835000K(2097152K)] ...] 3.212 secs
老年代回收前1843200K，回收后仅降到1835000K，只释放了约8MB，回收率＜0.5%。这说明：要么老年代堆满但对象都还活着（典型内存泄漏），要么碎片严重导致无法压缩——而后者往往源于老年代初始大小（-XX:OldSize）和最大大小（-Xmx减去-XX:NewSize）之间差距过大，JVM为避免频繁扩容而保守分配，结果造成空间虚高、实际可用率低。
面试中可点明：
- 若Full GC后老年代使用率仍＞85%，且无OOM，优先检查是否存在缓存未清理、静态集合持续add等泄漏模式
- 若Full GC耗时长（＞1s）且回收率低，同时日志中伴随“concurrent mode failure”或“promotion failed”，说明老年代空间设计与晋升速率不匹配，应调小-XX:NewRatio或改用G1收集器
戳破“堆够大就安全”的错觉：关注元空间与直接内存溢出线索
很多候选人只盯着-Xmx，却忽略元空间（Metaspace）和直接内存。当看到OutOfMemoryError但堆内存使用率仅60%时，要立刻扫日志头部或错误栈：
java.lang.OutOfMemoryError: Metaspace → 查-XX:MetaspaceSize是否过小，或应用动态生成类（如Spring CGLIB、JSON序列化框架）过多；
java.lang.OutOfMemoryError: Direct buffer memory → 日志中虽无显式GC记录，但应用大量使用ByteBuffer.allocateDirect()，需检查-XX:MaxDirectMemorySize是否缺失或偏小（默认等于-Xmx）。
这类问题在面试中属于“高阶陷阱”，能指出说明你真正理解JVM内存分域管理，而非只记堆参数。
用时间戳链还原真实负载节奏，暴露配置僵化问题
开启-Xloggc时务必加:time或:uptime。观察GC事件的时间分布：如果白天每5分钟一次Minor GC，夜间却变成每30秒一次，说明业务流量突增，但堆配置是静态的（-Xms = -Xmx），无法弹性应对。更隐蔽的问题是：-Xms设得过高，导致JVM启动慢、容器冷启动超时，或在K8s资源限制下触发OOMKilled——这些都不是GC日志直接写的，但时间轴+GC频率突变就是线索。
一句话总结：GC日志不是用来“读发生了什么”，而是用来“问为什么刚好这时发生、为什么只收这么点、为什么不能少停一会”。答到这一层，配置隐患自然浮出水面。
