高并发应用避免频繁Full GC的核心是控制对象生命周期与晋升路径。需固定堆大小、合理分配新生代比例，调大Survivor容量、限制大对象直入老年代、调整晋升年龄阈值，JDK 8优选G1GC并配置关键参数，辅以完整监控与兜底策略。
高并发应用避免频繁 Full GC，核心是让对象“该死在年轻代，就别活到老年代”，同时不让老年代被误灌、撑爆或碎片化。参数不是堆得越大越好，而是要匹配业务对象的生命周期节奏——比如订单服务每秒生成上千个短命对象，就得让 Eden 区扛住几十秒分配量，Survivor 区留足空间让它们多熬几轮 GC 再决定去留。
固定堆大小并合理分配新生代比例
堆太小会逼对象早进老年代；堆太大又可能拉长停顿，还掩盖晋升问题。关键动作是：
- -Xms 和 -Xmx 必须相等（如 -Xms4g -Xmx4g），避免运行时扩容触发 Full GC
- 总堆建议设为物理内存的 50%～70%，单实例不超过 16GB
- 年轻代占 1/3～1/2：可用 -XX:NewRatio=2（老:新 = 2:1）或直接 -Xmn1280m，确保 Eden 能容纳高峰时段几十秒的对象分配量
- Survivor 区每块建议 ≥ 100MB，防因空间不足导致存活对象被动晋升
控制对象晋升路径，堵住老年代“漏水口”
多数 Full GC 根源是老年代被短期对象误填满。需从晋升机制入手干预：
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 调大 Survivor 容量：默认 -XX:SurvivorRatio=8（Eden:S0:S1 = 8:1:1），若对象平均存活 2～3 次 GC 才死亡，可改为 -XX:SurvivorRatio=6
- 限制大对象直入老年代：-XX:PretenureSizeThreshold=5120000（5MB），避免 JSON 序列化、大 byte[] 绕过新生代
- 调整晋升年龄阈值：-XX:MaxTenuringThreshold=15（默认 15），防止短期对象因阈值过低被提前送进老年代
- 禁用 -XX:+AlwaysTenure（强制所有幸存对象进老年代），这个参数必须关掉
选对 GC 收集器并配准关键参数
GC 算法本身决定了 Full GC 是否容易发生。高并发、低延迟场景下：
- JDK 8 推荐 -XX:+UseG1GC，它能主动预测并增量回收老年代，大幅降低 Full GC 概率
- G1 关键调参：-XX:MaxGCPauseMillis=200（目标停顿，别设太低）、-XX:InitiatingHeapOccupancyPercent=45（并发标记启动阈值，老年代使用率达此值即开始标记）
- JDK 11+ 可考虑 -XX:+UseZGC 或 -XX:+UseShenandoahGC，它们支持并发回收，基本不触发传统 Full GC
- 避免使用 CMS（JDK 14+ 已移除），失败后会退化为 Serial Old，直接 Full GC
补全监控与兜底配置
没日志的调优等于蒙眼开车。必须加上：
- GC 日志：-Xloggc:/data/jvm/gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps
- OOM 自动 dump：-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/jvm/dump/heap_%p_%t.hprof
- 元空间设上限：-XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=256m，防 Spring Boot 动态代理类撑爆 Metaspace 导致 Full GC
- 屏蔽显式 GC：-XX:+DisableExplicitGC，拦截 System.gc() 调用
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
