美团面试：说说OOM三大场景和解决方案？（绝对史上最全）

最新推荐文章于 2024-09-14 11:33:49 发布

江-小北

最新推荐文章于 2024-09-14 11:33:49 发布

阅读量1.6k

点赞数 25

分类专栏： Java面试文章标签：面试职场和发展 jvm

本文链接：https://blog.csdn.net/liuguojiang1128/article/details/136275108

版权

Java面试专栏收录该内容

28 篇文章 0 订阅

订阅专栏

首先，咱们先聊聊，什么是OOM?

小伙伴们，有没有遇到过程序突然崩溃，然后抛出一个OutOfMemoryError的异常？这就是我们俗称的OOM，也就是内存溢出。简单来说，就是你的Java应用想要的内存超过了JVM愿意给的极限，就会抛出这个错误。
那么为什么会出现OOM呢？一般都是由这些问题引起：

分配过少：JVM 初始化内存小，业务使用了大量内存；或者不同 JVM 区域分配内存不合理
内存泄漏：某一个对象被频繁申请，不用了之后却没有被释放，发生内存泄漏，导致内存耗尽（比如ThreadLocal泄露）

接下来，我们来聊聊Java OOM的三大经典场景以及解决方案，保证让你有所收获！👍

Java OOM的三大核心场景

场景一：堆内存OOM（也叫堆内存溢出）

这是最常见的OOM场景了，发生在JVM试图分配对象空间时，却发现剩余的堆内存不足以存储新对象。

例如我们执行下面的代码，就可以模拟出堆内存OOM的场景：

// 创建大量对象导致堆内存溢出
public class HeapOOM {
    static class OOMObject {
        // 假设这里有一些属性
    }

    public static void main(String[] args) {
        List<OOMObject> list = new ArrayList<>();

        while (true) {
            list.add(new OOMObject()); // 不断创建对象并添加到list中
        }
    }
}

那么当出现线上应用OOM场景时，该如何解决呢？

分析方法通常有两种：

类型一：在线分析，属于轻量级的分析：
类型二：离线分析，属于重量级的分析：

类型一：在线OOM分析：

在线分析Java OOM（内存溢出）问题，通常涉及到监控运行中的Java应用，捕获内存溢出时的信息，分析堆转储（Heap Dump）文件，以及利用一些工具和命令来辅助定位问题。下面是一套详细的分析流程和命令，帮助你在线分析和解决Java OOM问题：

1、启用JVM参数以捕获Heap Dump

在Java应用启动命令中加入以下JVM参数，以确保在发生OOM时能自动生成堆转储文件：

-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/to/heapdump.hprof

这些参数的作用是：

-XX:+HeapDumpOnOutOfMemoryError：指示JVM在遇到OOM错误时生成堆转储文件。
-XX:HeapDumpPath：指定堆转储文件的存储路径，可以自定义路径和文件名。

2、实时监控内存使用情况

使用jvisualvm或jconsole等工具可以实时监控Java应用的内存使用情况。这些工具可以帮助你了解内存消耗的趋势，从而预测和避免OOM的发生。

JVisualVM：集成了多个JDK命令行工具，提供了可视化界面，可以监控内存使用、查看线程、分析堆等。
JConsole：Java监控和管理控制台，用于对JVM中的内存、线程和类等进行监控。

3、分析Heap Dump文件

当应用抛出OOM并且根据上述设置生成了堆转储文件后，使用Heap Dump分析工具来分析这个文件。常用的工具有：

Eclipse Memory Analyzer (MAT)：一个强大的Java堆分析工具，可以帮助识别内存泄露和查看内存消耗情况。
VisualVM：除了监控功能外，也支持加载和分析Heap Dump文件。

在MAT中打开Heap Dump文件，主要关注以下几点：

查找内存中对象的分布，特别是占用内存最多的对象。
分析这些对象的引用链，确定是哪部分代码引起的内存泄漏或过度消耗。
检查ClassLoader，以确认是否有过多的类被加载导致的元空间（Metaspace）OOM。

4、使用命令行工具

JDK提供了一些命令行工具，如jmap，可以用来生成Heap Dump文件：

jmap -dump:live,format=b,file=heapdump.hprof <pid>

其中<pid>是Java进程的ID。-dump:live选项表示只转储活动对象，可以减小Heap Dump文件的大小。

5、分析日志和异常信息

最后，不要忽视应用的日志和抛出的异常信息。OOM之前的日志可能会提供一些导致内存溢出的操作或业务逻辑的线索。

类型二：离线OOM分析，这个属于重量级分析

离线分析Java OOM（OutOfMemoryError）通常是在问题发生后，通过分析JVM生成的堆转储（Heap Dump）文件来进行。这个过程涉及到获取堆转储文件、使用分析工具进行深入分析和解读分析结果

1、获取Heap Dump文件

首先，确保你已经有了一个Heap Dump文件。这个文件可能是在JVM遇到OOM时自动生成的（如果启用了-XX:+HeapDumpOnOutOfMemoryError JVM参数），或者你可以在应用运行期间手动生成：

使用jmap命令生成Heap Dump文件：
```
jmap -dump:live,format=b,file=/path/to/heapdump.hprof <pid>
```
其中<pid>是Java进程的ID，/path/to/heapdump.hprof是你希望保存Heap Dump文件的位置。

2、使用Heap Dump分析工具

有了Heap Dump文件后，你需要使用专门的工具来进行分析。以下是一些常用的分析工具：

Eclipse Memory Analyzer (MAT)：非常强大的内存分析工具，能帮助识别内存泄漏和查看内存消耗情况。
VisualVM：提供了一个可视化界面，可以用来分析Heap Dump文件。
JVisualVM：随JDK一起提供的工具，也支持加载Heap Dump文件进行分析。

3、分析Heap Dump文件

使用MAT（Eclipse Memory Analyzer）作为示例，分析流程如下：

打开Heap Dump文件：启动MAT并打开Heap Dump文件（.hprof）。
运行Leak Suspects Report：MAT可以自动生成一个内存泄漏报告（Leak Suspects Report），这个报告会指出可能的内存泄漏路径。
分析Dominators Tree：这个视图显示了占用最多内存的对象及其引用。通过它，你可以找到最大的内存消耗者。
查看Histogram：对象Histogram列出了所有对象的实例数和总大小，帮助你识别哪种类型的对象占用了最多的内存。
检查GC Roots：为了确定对象为什么没有被垃圾回收，可以查看对象到GC Roots的引用链。
分析引用链：通过分析对象的引用链，你可以确定是什么持有了这些对象的引用，导致它们无法被回收。

下面给大家提供一份Java应用上线前参考的的JVM配置（内存8G）,以后系统上线前可以先配置下JVM，不要啥都不配置就上线了

-Xms6g -Xmx6g （按不同容器，4G及以下建议为50%，6G以上，建议设置为70%）
-Xmn2g    (以8G内存，年轻代可以设置为2G)
-XX:MetaspaceSize=256m
-XX:MaxMetaspaceSize=512m
-Xss256k
-XX:+UseG1GC
-XX:MaxGCPauseMillis=200
-XX:AutoBoxCacheMax=20000
-XX:+HeapDumpOnOutOfMemoryError （当JVM发生OOM时，自动生成DUMP文件）
-XX:HeapDumpPath=/usr/local/logs/gc/
-XX:ErrorFile=/usr/local/logs/gc/hs_err_%p.log （当JVM发生崩溃时，自动生成错误日志）
-XX:+PrintGCApplicationStoppedTime
-XX:+PrintGCDetails
-XX:+PrintGCDateStamps
-Xloggc:/usr/local/heap-dump/

场景二：元空间（MetaSpace）OOM

什么是元空间？

Java元空间（Metaspace）是Java虚拟机（JVM）中用于存放类的元数据的区域，从Java 8开始引入，替代了之前的永久代（PermGen）

图中红色箭头所指就是元空间

元空间是方法区在HotSpot JVM 中的实现，方法区主要用于存储类的信息、常量池、方法数据、方法代码等。方法区逻辑上属于堆的一部分，但是为了与堆进行区分，通常又叫“非堆”。

元空间的本质和永久代类似，都是对JVM规范中方法区的实现。

不过元空间与永久代之间最大的区别在于：元空间并不在虚拟机中，而是使用本地内存。理论上取决于32位/64位系统可虚拟的内存大小，可见也不是无限制的，需要配置参数。

元空间(Metaspace) 垃圾回收，会对僵死的类及类加载器的垃圾回收会进行回收，元空间(Metaspace) 垃圾回收的时机是，在元数据使用达到“MaxMetaspaceSize”参数的设定值时进行。

元空间OOM的现象

JVM 在启动后或者某个时间点开始，MetaSpace 的已使用大小在持续增长，同时每次 GC 也无法释放，调大 MetaSpace 空间也无法彻底解决。

元空间OOM的核心原因：生成了大量动态类

比如：

使用大量动态生成类的框架（如某些ORM框架、动态代理技术、热部署工具等）
程序代码中大量使用反射，反射在大量使用时，因为使用缓存的原因，会导致ClassLoader和它引用的Class等对象不能被回收

例如下面的生成大量动态代理类的代码示例，则会导致元空间的OOM

// 使用CGLIB动态生成大量类导致元空间溢出
public class MetaspaceOOM {
    public static void main(String[] args) {
        while (true) {
            Enhancer enhancer = new Enhancer();
            enhancer.setSuperclass(OOMObject.class);
            enhancer.setUseCache(false);
            enhancer.setCallback(new MethodInterceptor() {
                public Object intercept(Object obj, Method method, Object[] args, MethodProxy proxy) throws Throwable {
                    return proxy.invokeSuper(obj, args);
                }
            });
            enhancer.create(); // 动态生成类并加载
        }
    }

    static class OOMObject {
        // 这里可以是一些业务方法
    }
}

元空间(Metaspace) OOM 解决办法：

减少程序中反射的大量使用
做好熔断限流措施，对应用做好过载保护，比如阿里的sentinel限流熔断中间件

场景三：堆外内存OOM

Java对外内存（Direct Memory）OOM指的是Java直接使用的非堆内存（off-heap memory）耗尽导致的OutOfMemoryError。这部分内存主要用于Java NIO库，允许Java程序以更接近操作系统的方式管理内存，常用于高性能缓存、大型数据处理等场景

例如下面的代码，如何堆外内存太小，就会导致堆外内存的OOM：

// 分配大量直接内存导致OOM
import java.nio.ByteBuffer;

public class DirectMemoryOOM {
    private static final int ONE_MB = 1024 * 1024;

    public static void main(String[] args) {
        int count = 1;

        try {
            while (true) {
                ByteBuffer byteBuffer = ByteBuffer.allocateDirect(ONE_MB);
                count++;
            }
        } catch (Exception e) {
            System.out.println("Exception: instance created " + count);
            throw e;
        }
    }
}

堆外内存的原因

分配过量的直接内存：程序中大量使用DirectByteBuffer等直接内存分配方式，而没有相应的释放机制，导致内存迅速耗尽，常见于NIO、Netty等相关组件。
内存泄露：如果分配的直接内存没有被及时释放（例如，ByteBuffer未被回收），就可能发生内存泄露。
JVM对外内存限制设置不当：通过-XX:MaxDirectMemorySize参数控制对外内存大小，如果设置过小，可能无法满足应用需求。