遇到oom怎么处理？

OOM（Out Of Memory Error）是 Java 程序运行中常见的致命错误，本质是 JVM 内存不足以支撑程序继续运行。处理 OOM 需要结合具体场景分析内存溢出的类型、定位根源，并针对性优化。以下是系统的处理流程和解决方案：

一、先明确 OOM 的类型（关键！不同类型处理方向不同）

JVM 内存区域分为堆、方法区（元空间）、虚拟机栈、本地方法栈、程序计数器，其中前三者是 OOM 的高发区，错误信息会明确指出溢出区域：

1. java.lang.OutOfMemoryError: Java heap space
   堆内存溢出（最常见）：对象实例过多/过大，GC 无法及时回收，堆空间耗尽。

2. java.lang.OutOfMemoryError: Metaspace
   元空间（JDK 8+，替代永久代）溢出：类信息（类定义、方法、常量池等）过多，超出元空间限制。

3. java.lang.OutOfMemoryError: StackOverflowError
   虚拟机栈溢出：方法调用栈过深（如无限递归），栈帧耗尽栈空间。

4. java.lang.OutOfMemoryError: Direct buffer memory
   直接内存溢出：NIO 直接内存（不受 JVM 堆管理，由 OS 分配）使用过多，超出系统限制。

5. java.lang.OutOfMemoryError: unable to create new native thread
   线程创建过多：系统无法创建新线程（受 OS 进程线程数限制或内存不足）。

二、紧急处理：先恢复服务，再排查根源

若 OOM 导致服务不可用，需先快速恢复：

1. 重启服务：临时释放内存，恢复基本可用性（适合非核心服务，核心服务需配合扩容）。
2. 临时扩容内存：
   • 堆内存：调整 -Xms（初始堆）、-Xmx（最大堆）参数（如 -Xms2g -Xmx4g）。
   • 元空间：调整 -XX:MetaspaceSize、-XX:MaxMetaspaceSize（如 -XX:MaxMetaspaceSize=512m）。
   • 直接内存：调整 -XX:MaxDirectMemorySize（默认与堆最大值一致）。
3. 限流降级：通过网关限制流量，减少请求压力，避免内存持续飙升。

三、根源排查：定位内存溢出的具体原因（核心步骤）

1. 收集关键信息（复现或线上排查）

• OOM 错误日志：JVM 会打印溢出时的内存区域、线程栈信息（需保留完整日志）。
• 堆 Dump 文件：通过 JVM 参数 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/to/dump.hprof 配置，OOM 时自动生成堆快照（关键！用于分析对象分布）。
• 实时内存监控：用 jmap（查看堆使用）、jstat（GC 统计）、jstack（线程栈）等工具：

  jmap -heap <pid>  # 查看堆内存使用情况
  jmap -histo:live <pid>  # 查看存活对象统计（按内存/数量排序）
  jstat -gcutil <pid> 1000  # 每秒打印 GC 回收情况（关注 Full GC 频率和耗时）
  

2. 针对不同 OOM 类型分析

（1）堆内存溢出（Java heap space）

常见原因：

• 内存泄漏：对象被长期引用（如静态集合缓存未清理、线程池核心线程持有大对象），GC 无法回收。
• 大对象/批量对象：一次性创建大量对象（如加载超大列表、解析大文件），超出堆承载能力。
• GC 配置不合理：老年代空间过小，或垃圾收集器效率低（如串行收集器在高并发下无法及时回收）。

排查步骤：

1. 分析堆 Dump 文件：用 MAT（Eclipse Memory Analyzer）、JProfiler 等工具，查看：
   • 哪些对象占用内存最多（Dominator Tree 视图）。
   • 对象的引用链（Path to GC Roots），定位谁在持有这些对象（如静态 Map、长生命周期的缓存）。
2. 结合业务逻辑：是否有无限创建对象的逻辑（如循环中 new 对象未释放）、缓存是否设置过期时间、大文件处理是否分片。

（2）元空间溢出（Metaspace）

常见原因：

• 动态生成类过多：如频繁使用 CGLib、JDK 动态代理生成代理类，或 Groovy 等动态语言频繁编译类。
• 类加载器泄漏：自定义类加载器未被回收（如热部署场景，旧类加载器及其加载的类常驻内存）。
• 元空间参数设置过小：MaxMetaspaceSize 限制过严，无法容纳应用所需的类信息。

排查步骤：

1. 查看类加载数量：jmap -clstats <pid> 统计类加载器和加载的类数量，是否异常增长。
2. 检查动态代理/反射场景：是否有未限制的类生成逻辑（如循环生成代理类）。
3. 检查类加载器：是否存在自定义类加载器未被 GC 回收（通过堆 Dump 查看类加载器的引用链）。

（3）栈溢出（StackOverflowError）

常见原因：

• 无限递归调用：方法自身或间接递归，导致调用栈深度超过虚拟机栈限制。
• 单个栈帧过大：方法参数/局部变量过多，导致单个栈帧占用内存过大。

排查步骤：

1. 查看错误日志中的栈跟踪（stack trace），定位递归的方法（日志会显示重复的方法调用链）。
2. 检查递归逻辑：是否缺少终止条件，或递归深度设计不合理（如递归层级超过 1 万）。

（4）直接内存溢出（Direct buffer memory）

常见原因：

• NIO 直接缓冲区未释放：ByteBuffer.allocateDirect() 创建的缓冲区未调用 cleaner().clean() 释放，且未被 GC 回收（直接内存不受 JVM 管理，需等待 GC 触发 Cleaner 机制）。
• 直接内存参数设置过小：MaxDirectMemorySize 小于实际需求（如大量网络 IO、文件读写使用直接内存）。

排查步骤：

1. 检查 NIO 代码：是否有频繁创建直接缓冲区且未释放的逻辑（如网络框架未正确回收缓冲区）。
2. 监控直接内存使用：通过 jconsole 或自定义指标跟踪直接内存分配情况。

（5）无法创建新线程（unable to create new native thread）

常见原因：

• 线程创建过多：如高并发下未限制线程池大小，导致线程数暴增（Linux 系统默认进程线程数有限制，可通过 ulimit -u 查看）。
• 系统内存不足：每个线程占用栈内存（-Xss 配置，默认 1M），线程过多导致总内存超过系统限制。

排查步骤：

1. 查看线程数量：jstack <pid> | grep -c "java.lang.Thread.State" 统计线程数，是否远超预期（如几万甚至几十万）。
2. 检查线程池配置：是否核心线程数/最大线程数设置过大，或未使用线程池（直接创建新线程）。

四、解决方案：针对性优化

1. 堆内存溢出优化

• 修复内存泄漏：
  • 清理无用缓存：为静态集合设置最大容量和过期时间（如用 LinkedHashMap 实现 LRU 缓存，或使用 Guava Cache）。
  • 释放资源引用：IO 流、数据库连接等资源使用后及时关闭，避免被长期引用。
• 优化对象创建：
  • 大对象分片处理：如大文件读取采用缓冲区分片，避免一次性加载到内存。
  • 复用对象：使用对象池（如 Apache Commons Pool）复用频繁创建的对象（如数据库连接）。
• 调整 JVM 参数：
  • 合理设置堆大小：-Xms 与 -Xmx 设为相同值（避免动态扩容开销），根据业务压力测试确定最优值（如 4G~16G）。
  • 优化 GC 策略：大堆场景使用 G1 或 ZGC（如 -XX:+UseG1GC），减少 Full GC 停顿，提高回收效率。

2. 元空间溢出优化

• 控制动态类生成：
  • 缓存动态代理类：避免重复生成相同的代理类（如 Spring AOP 已做优化，但自定义代理需注意）。
  • 限制脚本引擎编译：如 Groovy 脚本设置缓存，避免频繁编译。
• 修复类加载器泄漏：
  • 热部署场景：确保旧类加载器被正确回收，避免静态引用持有。
• 调整元空间参数：
  • 增大 MaxMetaspaceSize（如 -XX:MaxMetaspaceSize=1g），或不设置上限（默认受系统内存限制）。

3. 栈溢出优化

• 避免无限递归：添加明确的递归终止条件，或改为迭代实现（如用栈数据结构模拟递归）。
• 减少单个栈帧大小：拆分大方法为多个小方法，减少局部变量数量。
• 调整栈大小：通过 -Xss 增大栈空间（如 -Xss2m，但需注意线程过多时的总内存消耗）。

4. 直接内存溢出优化

• 手动释放直接缓冲区：对长期持有的 DirectByteBuffer，调用 sun.misc.Cleaner.clean() 主动释放（需反射获取 Cleaner）。
• 控制直接内存使用量：设置合理的 MaxDirectMemorySize（如 -XX:MaxDirectMemorySize=2g），避免无限制分配。

5. 线程创建过多优化

• 合理配置线程池：
  • 核心线程数 = CPU 核心数 ± 1（CPU 密集型）或 2~4 倍 CPU 核心数（IO 密集型）。
  • 使用有界队列（如 ArrayBlockingQueue），配合拒绝策略（如 CallerRunsPolicy 限流）。
• 减少线程数：用线程池替代手动创建线程，避免短任务创建大量线程。
• 调整系统限制：Linux 下通过 ulimit -u <num> 增大进程最大线程数（需谨慎，避免系统资源耗尽）。

五、预防措施：避免 OOM 再次发生

1. 压测与监控：
   • 上线前通过 JMeter 等工具进行压力测试，模拟高并发场景，观察内存使用趋势。
   • 线上部署监控：用 Prometheus + Grafana 监控 JVM 堆/元空间/线程数，设置告警阈值（如堆内存使用率 > 80% 告警）。
2. 规范代码编写：
   • 避免静态集合无限制缓存，优先使用带过期策略的缓存框架（如 Redis、Caffeine）。
   • 大对象/批量数据处理时，采用流式处理（如 Java 8 Stream）或分页加载。
3. 合理配置 JVM 参数：
   • 根据服务类型（如微服务、大数据处理）调整堆大小、GC 收集器、元空间等参数，并定期review。

总结

处理 OOM 的核心流程是：明确类型 → 收集信息 → 定位根源 → 针对性优化。堆内存溢出和元空间溢出是最常见的场景，需重点关注对象引用和类加载问题；栈溢出和线程问题多与代码逻辑相关，需从调用链和线程池配置入手。长期来看，通过压测、监控和规范编码，可以有效预防 OOM 的发生。