优化jvm垃圾回收的核心是让对象尽量在年轻代被回收，减少晋升老年代：合理设置新生代比例与大小、控制晋升年龄阈值、减少短期对象逃逸与大对象直接分配，并选用匹配业务特征的gc器，配合日志持续调优。
核心是让对象尽量在年轻代被回收，减少晋升到老年代的频率。老年代回收成本高、停顿长，所以优化重点在于控制对象生命周期和内存分布。
合理设置新生代比例与大小
新生代是对象诞生和快速消亡的地方，Eden区越大，越能容纳短生命周期对象；Survivor区太小会导致对象“熬不过几次GC”就提前进入老年代。建议通过 -XX:NewRatio 控制新老年代比例（如 2 表示新生代占堆的 1/3），用 -XX:SurvivorRatio 调整 Eden 与 Survivor 比例（默认 8，即 Eden 占新生代 8/10）。若 GC 日志显示每次 Minor GC 后大量对象直接晋升，说明 Survivor 空间不足或对象存活时间偏长，可适当调大 Survivor 或检查业务逻辑中是否存在缓存滥用。
控制对象晋升年龄与阈值
对象在 Survivor 区每经历一次 Minor GC，年龄 +1；达到 -XX:MaxTenuringThreshold（默认 15）后进入老年代。但 JVM 实际晋升可能早于该阈值——当 Survivor 空间不足以容纳同龄对象时，会把部分对象提前送入老年代（动态年龄判定）。若发现老年代增长快、Full GC 频繁，可结合日志分析晋升速率；适当提高阈值（如设为 6–8），并确保 Survivor 有足够空间承载“中年对象”，避免被动提前晋升。
减少短期对象逃逸与大对象直接分配
避免在循环或高频方法中创建临时对象（如 new String()、ArrayList、包装类等），改用基本类型、静态常量或复用对象（如 StringBuilder、ThreadLocal 缓存）。特别注意：超过 -XX:PretenureSizeThreshold 的大对象（如大数组、大缓存）会直接分配到老年代，绕过年轻代。若应用存在较多生命周期不长的大对象，应调低该阈值，或拆分处理，防止老年代被“悄悄填满”引发频繁 Full GC。
选用匹配业务特征的垃圾收集器
不同场景适用不同回收器：
- 吞吐优先（批处理、后台计算）→ Parallel GC：多线程并行回收，暂停稍长但总耗时少
- 响应敏感（Web API、实时服务）→ G1 GC：可预测停顿（-XX:MaxGCPauseMillis）、支持并发标记、自动分区回收
- 超低延迟（金融交易、游戏引擎）→ ZGC 或 Shenandoah：几乎不 STW，适合百GB级堆
启用后务必配合 GC 日志（-Xlog:gc*:file=gc.log:time,uptime,tags）持续观察 Young GC 频率、晋升量、老年代占用趋势，而非仅依赖参数“设完就放”。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
