线上系统频繁Full GC导致接口超时雪崩，本质是老年代持续承压、回收不及时，需从JVM配置、代码规范、监控验证三端前置防控，将Full GC压至极低频次甚至接近零触发。
线上系统因频繁 Full GC 导致接口超时雪崩，本质是老年代内存持续承压、回收不及时，引发停顿累积和线程阻塞。解决的关键不是“等它发生再救”，而是从配置、代码、监控三端前置防控，把 Full GC 压到极低频次甚至接近零触发。
一、JVM 参数必须做对的几件事
参数不是越多越好，而是要精准匹配业务对象生命周期特征：
- 堆大小固定且充足：-Xms 和 -Xmx 设为相同值（如 3G～4G），避免运行中扩容触发 Full GC；容量需覆盖高峰期每秒对象分配量 × 2 分钟缓冲（参考：QPS 300、单请求对象约 6MB → 每秒新生代分配约 18MB，Eden 区建议 ≥ 800MB）
- 新生代要够大、比例要合理：用 -XX:NewRatio=2 或直接设 -Xmn1200m，确保 Eden 区能撑住几十秒以上分配压力，降低 YGC 频率；Survivor 区不小于 100MB，防止存活对象因空间不足被迫晋升
- 关掉大对象直入老年代的隐患：显式设置 -XX:PretenureSizeThreshold=5120000（5MB），避免单次创建超大 byte[]、JSON 字符串等直接跳过新生代
- 元数据空间别漏掉：-XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256M，防止动态类加载（如 Spring Boot 热部署、Groovy 脚本）撑爆 Metaspace 触发 Full GC
二、代码层最容易踩的四个“晋升加速器”
90% 的非泄漏型频繁 Full GC，都源于对象被“无意中推”进老年代：
- 静态集合无清理：static Map<String, Object> cache = new ConcurrentHashMap<>() 不加 size 限制或 LRU 清理逻辑，每次 put 都是老年代常驻对象
- ThreadLocal 泄漏：在线程池场景下，用完 ThreadLocal 后没调 remove()，导致 value 对象与线程强绑定，长期存活
- 监听器/回调未注销：注册了事件监听、Spring ApplicationRunner、Netty ChannelHandler 后，在对象销毁时没对应反注册，形成隐式强引用链
- IO 资源未关闭：InputStream、Connection、ResultSet 等未在 finally 或 try-with-resources 中释放，关联的缓冲区、连接池对象无法回收
三、上线前必须验证的三项底线能力
不能只靠“感觉稳定”，要用可观测性数据说话：
立即学习“Java免费学习笔记（深入）”；
- 看 GC 日志趋势：上线后连续跑 30 分钟，执行 jstat -gc <pid> 5s，确认 OU（老年代使用量）波动幅度 ≤ 5%，且每次 Full GC 后回落至 30% 以下
- 压测验证晋升率：用 JMeter 模拟高峰 QPS，观察 jstat 输出中的 YGC 次数与 “YGCT / YGC”（平均耗时），若平均 YGC 耗时 > 200ms 或晋升对象量 > 2MB/次，说明 Survivor 区或对象生命周期预估有偏差
- 检查堆内对象分布：jmap -histo:live <pid> | head -20，重点看 HashMap$Node、ArrayList、ByteString、char[] 是否异常高居前列——它们往往是缓存、日志、序列化过程失控的信号
四、出问题时快速止血不误判
一旦告警响起，按顺序做三件事，不重启、不盲目调参：
- 先保现场：立刻 jcmd <pid> VM.native_memory summary + jmap -dump:format=b,live,file=heap.hprof <pid>（加 live 参数大幅缩短 dump 时间）
- 再查根因线索：用 jstat -gc <pid> 1s 连续采样 1 分钟，重点关注 OU 是否单向爬升、FGC 是否随 YGC 成倍增加（典型担保失败征兆）
- 最后定向干预：若确认是某类对象暴增，临时降级对应功能（如关闭全量日志、禁用某缓存模块），而非直接扩容或调大堆——那只是掩盖问题
