本文目录导读：
- 目录导读
- 什么是OOM？—— 认识OutOfMemoryError
- 经典案例一：堆内存溢出（Heap Space）
- 经典案例二：元空间溢出（Metaspace）
- 经典案例三：栈溢出（StackOverflow）
- 案例实战：一步步定位OOM的根因
- 如何预防和解决OOM？—— 调优策略
- 常见问答（FAQ）
- 总结与最佳实践
Java OOM实战：从内存泄漏到性能调优的完整案例解析
目录导读
- 什么是OOM？—— 认识OutOfMemoryError
- 经典案例一：堆内存溢出（Heap Space）
- 经典案例二：元空间溢出（Metaspace）
- 经典案例三：栈溢出（StackOverflow）
- 案例实战：一步步定位OOM的根因
- 如何预防和解决OOM？—— 调优策略
- 常见问答（FAQ）
- 总结与最佳实践
什么是OOM？—— 认识OutOfMemoryError
在Java虚拟机（JVM）中，当内存分配无法满足程序运行需求时，会抛出java.lang.OutOfMemoryError，这是所有Java开发者都会遇到的“噩梦”，但也是提升调优能力的“磨刀石”。
根据触发区域不同,OOM主要分为以下四类：
- 堆内存溢出：
java.lang.OutOfMemoryError: Java heap space - 元空间溢出：
java.lang.OutOfMemoryError: Metaspace - 栈溢出：
java.lang.StackOverflowError（严格来说不算OOM，但常被归为内存异常） - 直接内存溢出：
java.lang.OutOfMemoryError: Direct buffer memory
核心根源：要么是内存泄漏（对象无法被GC回收），要么是内存溢出（分配对象超过了堆/非堆的最大容量）。
经典案例一：堆内存溢出（Heap Space）
场景还原：一个电商订单处理系统，每天处理百万级订单，某天开始，系统频繁Full GC，最终抛出Java heap space。
代码复现：
List<Order> orders = new ArrayList<>();
while (true) {
orders.add(new Order(UUID.randomUUID().toString()));
}
根因分析：
orders是一个静态集合，持有所有订单对象的强引用。- 即使订单处理完,集合仍然保留引用，导致GC无法回收。
- 最终堆内存被占满,触发OOM。
解决思路：
- 使用
WeakHashMap或WeakReference弱化引用。 - 定期清理无用对象,或采用分页/批量处理。
- 调整堆大小：
-Xms与-Xmx，但治标不治本。
经典案例二：元空间溢出（Metaspace）
场景还原：一个使用CGLib动态代理的框架，运行几天后抛出Metaspace溢出。
代码复现：
while (true) {
Enhancer enhancer = new Enhancer();
enhancer.setSuperclass(OrderService.class);
enhancer.setUseCache(false);
enhancer.create();
}
根因分析：
- 每次循环生成一个新的类,加载到元空间（JDK 8+）。
- 元空间默认使用系统内存,无上限（除非设置
-XX:MaxMetaspaceSize）。 - 类加载器即使卸载,元空间也不一定立即回收。
解决思路：
- 设置
-XX:MaxMetaspaceSize=256m，提前触发告警。 - 避免重复生成类,缓存代理对象。
- 检查类加载器泄漏根因（如
ClassLoader引用未释放）。
经典案例三：栈溢出（StackOverflow）
场景还原：递归函数计算阶乘，传入参数过大，程序直接崩溃。
代码复现：
public int factorial(int n) {
if (n == 1) return 1;
return n * factorial(n - 1);
}
根因分析：
- 每次递归调用会分配一个栈帧（局部变量、操作数栈等）。
- 默认栈大小约512KB~1MB，递归深度过多即溢出。
解决思路：
- 改为迭代算法（循环）。
- 若必须递归,设置
-Xss2m（如线程栈大小2MB）。 - 增加递归退出条件约束。
案例实战：一步步定位OOM的根因
获取dump文件
启动时添加JVM参数：
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/to/dump.hprof使用MAT分析
- 打开Eclipse MAT（Memory Analyzer Tool）。
- 加载dump.hprof，选择“Leak Suspects Report”。
- 查看“Dominator Tree”，找出占用内存最大的对象路径。
结合线程分析
- 使用
jstack获取线程快照。 - 查找
RUNNABLE状态下的任务，看是否卡在某个循环或集合操作。
修复并验证
- 修改代码后,压测观察GC日志及内存趋势。
如何预防和解决OOM？—— 调优策略
| 策略 | 具体措施 |
|---|---|
| JVM参数调优 | -Xmx合理设置（不超过物理内存70%）；-XX:+UseG1GC；-XX:MaxMetaspaceSize限制元空间；-XX:+PrintGCDetails看日志。 |
| 代码层面 | 使用对象池（如数据库连接池）；及时清空集合；选用Stream代替大列表；避免大对象直接复制。 |
| 框架使用 | MyBatis批量操作时注意resultType返回集合大小；ES查询避免scroll大返回。 |
| 监控告警 | 接入Prometheus + Grafana，监控堆内存使用量、GC频率；设置阈值告警。 |
常见问答（FAQ）
Q1：OOM一定会导致进程退出吗？
不一定。OutOfMemoryError是Error而非Exception，JVM可能继续运行，但非常不稳定，多数情况下应尽快dump堆并重启。
Q2：如何区分内存泄漏与内存溢出？ 内存泄漏：对象不再使用却无法回收，长期耗尽堆，内存溢出：单次申请对象过大（如超大数组）瞬间撑爆堆。
Q3：-Xmx设置越大越好吗？
不是，堆越大，GC停顿时间越长，吞吐量下降，应根据应用的实际存活对象大小设置，且预留系统内存给元空间、线程栈。
Q4：使用System.gc()能解决OOM吗？
无济于事，它只是建议JVM执行GC，Oracle默认会忽略该调用（使用-XX:+DisableExplicitGC）。
总结与最佳实践
从上面的案例可以看出,OOM的本质是“资源管理失控”，解决任何内存问题，建议遵循以下流程：
- 先定位：通过dump文件+日志，找到占用内存最高的对象或方法。
- 再分型：判断是泄漏还是瞬时峰值。
- 后根治：修改代码结构，而非单纯调大堆。
- 最后预防：加入监控和自动化告警，未雨绸缪。
在实际工作中,多利用工具（如VisualVM、Arthas、JProfiler）进行日常诊断，而不是等OOM发生了再手忙脚乱。调优无止境，但原则永不变——用最合适的内存，做最多的事。
如果你刚接触OOM,建议从阅读官方Java GC调优指南开始，并在一台测试机器上复现上述案例，亲手体验“从内存爆炸到修复”的完整过程。
