01

60 秒回答模板

Full GC 通常意味着 JVM 需要对老年代或整个堆做更重的回收。常见触发包括老年代空间不足、年轻代对象晋升失败、元空间不足、大对象或 humongous 对象分配失败、System.gc 或 jcmd/jmap 等显式请求，以及某些收集器并发回收失败后的退化。主动触发可以用 System.gc、jcmd GC.run 或诊断工具，但线上不应把它当治理手段。真正要回答的是看 GC 日志里的触发原因、回收前后容量、暂停时间、晋升速率、老年代增长和引用链，定位是内存泄漏、分配过快、参数不合理还是显式调用。

考点 核心机制与工程取舍
难度 中高频面试题
回答目标 按定义、机制、场景讲清楚
02

深入解析

01

空间不足触发

老年代没有足够连续或可用空间承接晋升对象、大对象分配失败、元空间加载类过多，都可能触发更重的回收。不同收集器名称和细节不同，但本质都是某个关键区域无法继续分配。

02

晋升和担保失败

年轻代回收后仍存活的对象要晋升到老年代。如果老年代空间不足，或者晋升担保判断风险过高，就可能触发 Full GC 或退化回收。频繁晋升通常和对象生命周期、Survivor 配置、分配速率有关。

03

显式 GC 要谨慎

System.gc、Runtime.gc、jcmd GC.run、jmap -histo:live 等都可能请求一次完整回收。它们可用于诊断或特定离线场景，但在线上高峰期可能造成长暂停，且不应该替代内存泄漏治理。

04

收集器退化场景

CMS 可能出现 concurrent mode failure，G1 可能因为 humongous 对象、to-space exhausted 或并发标记来不及而退化为更重回收。回答时可以说明触发条件要结合具体 GC 算法看日志。

05

诊断要看证据链

排查频繁 Full GC 要看触发原因、GC 前后各区容量、暂停时间、对象晋升速率、元空间增长、分配热点、堆 dump 引用链和是否有显式 GC 调用。只背触发条件不能指导线上问题。

03

易错点

  • 只罗列触发条件，不会结合 GC 日志判断真实原因。
  • 把 System.gc 当成线上释放内存的常规方案。
  • 忽略元空间、直接内存、humongous 对象和收集器退化。
  • 看到 Full GC 就调大堆，没有分析对象存活和分配速率。
04

面试官追问

System.gc 一定会触发 Full GC 吗？

不一定，取决于 JVM 参数和收集器实现，例如可以通过参数禁用显式 GC 或让它走并发回收。但它通常是危险信号，线上要查调用来源。

频繁 Full GC 怎么定位？

先打开并分析 GC 日志，确认触发原因和回收效果；再看老年代是否回收后仍高位、元空间是否增长、对象晋升是否过快；必要时抓堆 dump 分析引用链和对象数量。

Full GC 后内存降不下来说明什么？

说明大量对象仍然可达，可能是缓存无界、集合持有、ThreadLocal 未清理、监听器未注销或类加载器泄漏。也可能是堆目标容量策略导致未立即还给操作系统。

主动 Full GC 有哪些合法场景？

离线诊断、压测验证、停机维护前清理、某些工具采样可以接受；用户请求链路和高峰生产流量中不应依赖主动 GC 释放内存。