gc日志是发现内存抖动最直接信号，表现为minor gc间隔＜200ms、eden区锯齿状高频震荡、survivor区使用率偏低，而老年代平稳或缓升、full gc释放量大；抖动≠泄漏，后者老年代持续单边上涨且full gc无效。
GC 日志是发现线上内存抖动最直接、最可靠的信号源。抖动本质是短命对象高频分配，它不会立刻爆 OOM，但会在日志里留下清晰节奏：年轻代反复填满、快速回收、间隔极短。关键不是看有没有 GC，而是看“频率、幅度、触发原因”三者的异常组合。
盯住 Minor GC 的节奏和规模
内存抖动最典型的表现就是 Young GC 过于密集且“浅回收”：
- Minor GC 间隔持续小于 200ms（比如每 100–150ms 就来一次），说明 Eden 区几秒内就被打满
- 每次 GC 后 Eden 使用量（EU）从接近 EC（Eden 容量）迅速回落到接近 0，但下一波又立刻冲顶——呈现锯齿状高频震荡
- Survivor 区（S0/S1）使用率长期偏低（
关注日志中的触发关键词和分配速率
现代 JVM（如 G1、ZGC）的日志会明确标注 GC 触发原因，抖动场景下常见以下线索：
- Allocation Failure 高频出现：这是最核心指标，表示 Eden 区真的不够用了，不是参数调得小，而是业务在疯狂 new
- Humongous Allocation 频繁记录：说明大对象（如 byte[]、JSON 字符串）正绕过年轻代直入老年代，可能引发 Mixed GC 加速或老年代假性饱和
- 日志中显示 “Objects allocated: X MB/s”（需开启 -Xlog:gc+allocation）持续 >10MB/s，远超正常业务波动范围
交叉验证老年代行为，排除干扰
抖动 ≠ 内存泄漏，两者 GC 日志特征相反：
- 抖动时：老年代（Old / Heap）使用量整体平稳或缓慢爬升，但 Full GC 很少发生；即使有，Full GC 后老年代释放量也较大（说明对象真被回收了）
- 泄漏时：老年代使用量持续单边上涨，Full GC 后 OU（老年代已用）几乎不降，甚至越收越高
- 若发现 Minor GC 频繁 + 老年代同步缓慢上涨 + Full GC 效果差 → 要警惕是否因抖动导致大量对象提前晋升（如 Survivor 区太小、MaxTenuringThreshold 过低）
搭配简单命令快速初筛
不用等完整日志归档，生产环境可实时抓取关键信号：
- grep "Allocation Failure" gc.log | tail -20 —— 看最近 20 次是不是全集中在某几分钟内
- awk '/Young/ && /time.*ms/ {print $NF}' gc.log | sort -n | tail -5 —— 查看最近几次 Young GC 耗时是否明显拉长（可能伴随 Eden 碎片化）
- grep -E "(Humongous|G1H)" gc.log | wc -l —— 统计大对象分配次数，超过几十次/分钟就值得深挖
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
