最有效手段是合理调优JVM参数：固定堆大小（-Xms=-Xmx）、按业务生命周期分配新生代与老年代、防早熟晋升、限制大对象直入老年代、设元空间上限、配置OOM日志及选用合适GC收集器。
直接调优 JVM 参数是解决线上频繁 GC 最有效、最可控的手段。关键不是堆参数堆得越大越好，而是让内存分配节奏匹配业务对象生命周期——新生代扛得住短时压力，老年代不被“误灌”，GC 停顿可控、可预期。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
堆内存必须固定且合理分配
-Xms 和 -Xmx 必须设为相同值（如 -Xms4g -Xmx4g），避免运行中动态扩容触发 Full GC；总堆大小建议设为物理内存的 50%～70%，单实例不超过 16GB。年轻代不能太小：用 -Xmn1280m 或 -XX:NewRatio=2（即老年代:年轻代 = 2:1），确保 Eden 区能容纳几十秒的对象分配量；Survivor 区要够用（建议每块 ≥ 100MB），否则存活对象因空间不足提前晋升老年代。
新生代结构要防“早熟晋升”
Eden 和 Survivor 比例默认是 8:1:1（-XX:SurvivorRatio=8），但若业务中对象平均存活 2～3 次 GC 才死亡，建议适当调大 Survivor（如 -XX:SurvivorRatio=6），减少因 S 区撑满导致的被动晋升。同时显式限制大对象直入老年代：-XX:PretenureSizeThreshold=5120000（5MB），避免 JSON 序列化、大 byte[] 等绕过新生代直接压垮老年代。
元空间和兜底机制不能漏
元空间必须设上限：-XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=256m，防止 Spring Boot 动态代理、热加载类撑爆 Metaspace 触发 Full GC；OOM 时必须自留证据：-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/jvm/dump/heap_%p_%t.hprof，配合 -Xloggc:/data/jvm/gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps，日志才能真实反映 GC 类型、频率与原因。
GC 收集器要按场景选型
吞吐优先（后台批处理）→ 用 ParallelGC：-XX:+UseParallelGC -XX:GCTimeRatio=19；低延迟敏感（交易/接口服务）→ 用 G1GC：-XX:+UseG1GC -XX:MaxGCPauseMillis=200；超大堆（>16GB）+ 极低停顿要求 → 考虑 ZGC（JDK11+）。别用 CMS（已废弃），也别在小堆（<4GB）上强行用 G1，反而增加开销。
不复杂但容易忽略
