jvm内存回收策略需匹配高可用应用的低延迟、强稳定性、可预测停顿诉求：年轻代应快频回收，合理调优survivorratio；老年代须可控回收，禁用动态扩容并监控使用率；元空间需显式限界；收集器按sla选型，zgc/shenandoah适用于延迟敏感场景，g1适合平衡型服务。
JVM 内存回收策略必须匹配高可用应用的核心诉求：低延迟、强稳定性、可预测停顿。不是堆越大越好，也不是GC越勤越稳；关键在于让回收行为与业务节奏对齐，避免突发Full GC或长时间STW打断服务。
年轻代回收要快且高频
高可用服务中，90%以上对象生命周期极短，应集中在Eden区快速分配和释放。默认8:1:1的Eden/S0/S1比例适合多数场景，但若观察到Survivor区频繁溢出、大量对象直接晋升老年代（可通过-XX:+PrintGCDetails日志中的Promotion Failure识别），说明Survivor空间不足或对象存活率偏高。此时可微调-XX:SurvivorRatio=6（即Eden:Survivor=6:1:1），或结合-XX:TargetSurvivorRatio=90提升 Survivor 利用率。避免手动调大Survivor——它不解决根本问题，反而可能延长Minor GC时间。
老年代回收必须可控且低干扰
高可用系统严禁不可预知的老年代爆炸式增长。需做到三点：
- 设置合理的初始与最大堆（
-Xms=-Xmx），杜绝动态扩容引发的内存抖动； - 用
-XX:MaxGCPauseMillis=200（G1/ZGC下）向JVM声明停顿目标，驱动其自动调整回收节奏； - 监控老年代使用率，一旦持续超过75%，立即排查长生命周期对象（如缓存未设淘汰策略、静态集合无清理机制、ThreadLocal泄漏等），而非简单加堆。
元空间不能放任自流
JDK 8+后，类元数据移至本地内存，但默认无上限。微服务频繁加载/卸载类（如Spring Boot热部署、OSGi、动态代理）易导致元空间OOM。应显式限制：-XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m，并配合-XX:+PrintGCDetails观察Metaspace区域GC频率。若发现频繁Metaspace GC，说明类加载失控，需检查ClassLoader泄漏或重复定义类。
收集器选型取决于SLA硬指标
- 延迟敏感型（API网关、实时风控）：优先ZGC（JDK11+）或Shenandoah（JDK12+），停顿稳定
- 吞吐优先型（批处理、报表生成）：Parallel GC更合适，牺牲停顿换吞吐；
- 平衡型（主流Web服务）：G1仍是稳妥选择，尤其在4–32GB堆范围内，通过
-XX:G1HeapRegionSize和-XX:G1MixedGCCountTarget精细控制混合回收节奏。
不建议在生产环境使用Serial或CMS——前者单线程无法承载高并发，后者已从JDK14起彻底移除。
