频繁 Full GC 根因分析
本文是《JVM调优实战》专栏第 23 讲。
你刚上线一个新版本，监控告警就响了：Full GC 频率从每小时1次飙升到每分钟2次，每次耗时 500ms+。应用响应时间从 50ms 拉到 2s，用户开始投诉。这时候你能做什么？——不少人会直接加大-Xmx，但如果根因是内存泄漏，加大堆只是延缓死亡，泄漏的对象仍然在持续积累，早晚还是会频繁 Full GC。
频繁 Full GC 是 JVM 在拼命自救的信号：老年代快满了，GC 反复回收但收效甚微。就像一个房间越来越满，保洁阿姨反复打扫却总扫不完——问题不是阿姨干活不够快，而是有人持续往房间里堆东西不清理。你得找到"堆东西的人"。
本讲将系统梳理 Full GC 的触发条件和六大常见原因，给出从jstat到 dump 的完整排查方法论，并通过实战案例带你从告警到定位根因。
Full GC 的触发条件
Full GC 是对整个堆（新生代 + 老年代）和元空间的全面回收，代价极高——会暂停所有应用线程（STW），耗时通常在数百毫秒到数秒之间。触发条件有五种：
| 触发条件 | 说明 | 典型场景 |
|---|---|---|
| 老年代空间不足 | 新对象晋升到老年代或大对象直接进入老年代，空间不够< |
