频繁 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），耗时通常在数百毫秒到数秒之间。触发条件有五种：触发条件说明典型场景老年代空间不足新对象晋升到老年代或大对象直接进入老年代，空间不够