选对垃圾回收器是解决oom的关键，需按场景匹配：低延迟服务用g1或zgc，高吞吐批处理用parallel gc，小堆单核用serial gc；误用cms或serial会加剧问题。
调整垃圾回收算法是解决Java内存溢出（OOM）的关键手段之一，它不单是换一个GC参数，而是根据应用特征匹配回收行为——比如响应延迟敏感型服务适合低停顿算法，吞吐量优先的批处理则倾向高效率回收。选对算法，能显著缓解因GC不及时、回收不彻底导致的堆内存持续增长问题。
识别当前GC瓶颈
先确认是不是GC本身拖了后腿。观察以下现象：
- 频繁发生Full GC，且每次耗时超过1秒
- 年轻代对象大量晋升到老年代（可通过-XX:+PrintGCDetails日志中的“Promotion Failed”或“Allocation Failure”判断）
- 老年代使用率缓慢但持续上升，GC后回落极少
- 应用吞吐量下降、响应毛刺增多，而堆内存并未明显泄漏
这些往往是默认GC（如Parallel GC）在大堆或复杂引用场景下力不从心的表现。
按场景选择合适GC算法
G1 GC：适用于堆内存≥4GB、要求可控停顿（目标通常设为200ms以内）的中大型应用。
- 启用方式：-XX:+UseG1GC
- 关键调优参数：-XX:MaxGCPauseMillis=200（JVM尽力满足，非强保证），-XX:G1HeapRegionSize（避免大对象直接进Humongous区引发碎片化）
- 优势：分区回收 + 并发标记，兼顾吞吐与响应；自动避免内存碎片
ZGC 或 Shenandoah：适用于堆内存≥16GB、对STW（Stop-The-World）极度敏感的系统（如实时交易、高频API网关）。
- ZGC启用：-XX:+UseZGC（JDK11+，需开启-XX:+UnlockExperimentalVMOptions旧版本）
- 特点：停顿时间稳定在10ms内，支持TB级堆；但会略微增加CPU开销
避免误用Serial或CMS：Serial仅适合单核嵌入式场景；CMS在JDK9后已废弃，且易因并发模式失败触发Full GC雪崩。
配合算法调整关键内存策略
GC算法不是孤立生效的，需与内存布局协同：
- 关闭显式GC调用：-XX:+DisableExplicitGC（防止
System.gc()打断G1/ZGC的并发节奏） - 限制大对象分配：-XX:G1LargeObjectThreshold（G1下）或合理设置-XX:MaxMetaspaceSize（防元空间溢出干扰堆GC）
- 启用GC日志分析：-Xlog:gc*,gc+heap=debug,gc+ergo*=info:file=gc.log:tags,time,uptime,level（JDK10+统一日志格式）
- 验证效果：用工具如GCViewer或JDK自带jstat -gc
观察YGC频率、FGC次数、各代回收前后占比变化
注意算法切换的副作用
换GC不是万能解药：
- G1在小堆（
- ZGC对Linux内核版本和大页支持有要求（如需Transparent Huge Pages禁用）
- 所有新GC都依赖足够CPU资源——若应用本就CPU饱和，GC线程争抢反而恶化性能
- 必须配合堆大小设置：-Xms和-Xmx建议设为相同值，避免G1动态调优区间的震荡
真正有效的GC优化，始于日志诊断，成于参数收敛，稳于长期监控。算法只是杠杆，支点永远是你的应用行为本身。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
