减少JVM垃圾回收开销的核心是少制造垃圾、让GC更省力、让内存更可控，具体包括：避免高频创建临时对象；优先使用基本类型和StringBuilder；显式置空长生命周期中不再使用的对象；预估集合容量；慎用static和强引用缓存；配合G1回收器与合理参数调优。
减少 JVM 垃圾回收（GC）的系统开销，核心在于“少制造垃圾、让 GC 更省力、让内存更可控”。这不是靠调参一蹴而就的事，而是贯穿编码习惯、数据结构选择和运行时策略的综合实践。
控制对象生命周期，从源头减量
GC 开销直接正比于待回收对象的数量与大小。关键不是等对象变垃圾再处理，而是不让它们轻易变成垃圾：
- 避免在循环或高频方法中创建临时对象（如 new String()、new Date()、包装类自动装箱）；能用 int 就不用 Integer，能用 char[] 拼接就不用 String +=
- 及时切断强引用：局部集合使用完后，若后续不再访问，可显式赋 null（尤其在 long-lived 方法或缓存场景中）
- 缩小作用域：把变量声明在最小必要范围内（比如 for 循环内），方法结束即自然不可达，无需额外干预
优化字符串与集合使用
这两类操作是日常代码中最易触发隐式对象爆炸的“重灾区”：
- 字符串拼接优先用 StringBuilder（单线程）或 StringBuffer（多线程），禁用 + 在循环内拼接；对已知长度的拼接，初始化 capacity（如 new StringBuilder(128)）
- 创建集合时预估容量：ArrayList list = new ArrayList(expectedSize)；HashMap map = new HashMap(expectedSize * 4 / 3 + 1)；避免多次扩容复制数组
- 避免无意义的集合转换：如 list.stream().collect(Collectors.toList())，若原 list 已满足需求，直接复用
善用内存模型与引用类型
让 JVM 更精准识别哪些对象“真该回收”，减少误判与扫描压力：
- 慎用 static 持有大对象或集合——static 变量生命周期与类绑定，长期驻留堆中，易促发老年代堆积
- 缓存场景优先考虑 WeakReference 或 SoftReference：当内存紧张时，JVM 可主动回收，避免 OOM 或频繁 Full GC
- 避免长生命周期对象持有短生命周期对象的强引用（典型内存泄漏模式），例如内部类无意持有了 Activity 或 Handler 引用
配合 JVM 运行时调优
代码优化是基础，参数配置是放大器，二者需协同：
- 选用 G1 回收器（JDK9+ 默认）：适合大堆、低延迟场景，能预测停顿时间，避免 CMS 的并发失败风险
- 合理设置年轻代比例（-XX:NewRatio）与 Survivor 区大小（-XX:SurvivorRatio），让多数短命对象在 Eden 区被快速回收，不晋升到老年代
- 启用 GC 日志（-Xlog:gc*:file=gc.log）并定期分析：关注 GC 频率、晋升率、Full GC 次数；若发现大量对象提前晋升，说明年轻代过小或对象存活时间异常
