前提概要

对于JVM服务而言出现了OOM(Out Of Memory)问题，并且对其进行相关的解决是作为一个Java技术栈人员必备的实战能力。在此总结了一些相对通用的方案，希望能帮助到大家。

分析原因

某Java服务出现了OOM，最常见的原因为：

有可能是内存分配确实过小，而正常业务使用了大量内存（正常现象）
某一个对象被频繁申请，却没有释放，内存不断泄漏，导致内存耗尽（内存泄漏、代码问题）
某一个资源被频繁申请，系统资源耗尽，例如：不断创建线程，不断发起网络连接（线程不断创
建、代码问题）

排查方案

确认是不是内存本身就分配过小

方法：jmap -heap pid

如上图，可以查看新生代，老生代堆内存的分配大小以及使用情况，看是否本身分配过小。

找到最耗内存的对象

方法：jmap -histo:live 10765 | more

如上图，输入命令后，会以表格的形式显示存活对象的信息，并按照所占内存大小排序：

实例数
所占内存大小
类名

是不是很直观？对于实例数较多，占用内存大小较多的实例/类，相关的代码就要针对性review了。

上图中占内存最多的对象是RingBufferLogEvent，共占用内存18M，属于正常使用范围。

如果发现某类对象占用内存很大（例如几个G），很可能是类对象创建太多，且一直未释放。例如：

申请完资源后，未调用close()或dispose()释放资源
消费者消费速度慢（或停止消费了），而生产者不断往队列中投递任务，导致队列中任务累积过多

线上执行该命令会强制执行一次fullgc。另外还可以dump内存进行分析。

确认是否是资源耗尽

工具：

pstree
netstat

查看进程创建的线程数，以及网络连接数，如果资源耗尽，也可能出现OOM。

这里介绍另一种方法，通过

/proc/${PID}/fd
/proc/${PID}/task
复制代码

可以分别查看句柄详情和线程数。

例如，某一台线上服务器的sshd进程PID是9339，查看

ll /proc/9339/fd
ll /proc/9339/task
复制代码

如上图，sshd共占用了四个句柄

0 -> 标准输入
1 -> 标准输出
2 -> 标准错误输出
3 -> socket（容易想到是监听端口）

sshd只有一个主线程PID为9339，并没有多线程。

所以，只要

ll /proc/${PID}/fd | wc -l
ll /proc/${PID}/task | wc -l （效果等同pstree -p | wc -l）
复制代码

就能知道进程打开的句柄数和线程数。

Java内存溢出OOM

JVM中常见的两个错误

StackoverFlowError ：栈溢出
OutOfMemoryError: java heap space：堆溢出

除此之外，还有以下的错误

java.lang.StackOverflowError
java.lang.OutOfMemoryError：java heap space
java.lang.OutOfMemoryError：GC overhead limit exceeeded
java.lang.OutOfMemoryError：Direct buffer memory
java.lang.OutOfMemoryError：unable to create new native thread
java.lang.OutOfMemoryError：Metaspace
复制代码

OutOfMemoryError和StackOverflowError是属于Error，不是Exception

StackoverFlowError

堆栈溢出，我们有最简单的一个递归调用，就会造成堆栈溢出，也就是深度的方法调用栈一般是512K，不断的深度调用，直到栈被撑破

public class StackOverflowErrorDemo {
  public static void main(String[] args) {
    stackOverflowError();
  }
  /**
   * 栈一般是512K，不断的深度调用，直到栈被撑破
   * Exception in thread "main" java.lang.StackOverflowError
   */
  private static void stackOverflowError() {
    stackOverflowError();
  }
}
复制代码

运行结果

Exception in thread "main" java.lang.StackOverflowError
  at com.moxi.interview.study.oom.StackOverflowErrorDemo.stackOverflowError(StackOverflowErrorDemo.java:17)
复制代码

OutOfMemoryError：java heap space

创建了很多对象，导致堆空间不够存储

public class JavaHeapSpaceDemo {
  public static void main(String[] args) {
    // 堆空间的大小 -Xms10m -Xmx10m
    // 创建一个 80M的字节数组
    byte [] bytes = new byte[80 * 1024 * 1024];
  }
}
复制代码

我们创建一个80M的数组，会直接出现Java heap space

Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
复制代码

GC overhead limit exceeded

GC回收时间过长时会抛出OutOfMemoryError，过长的定义是，超过了98%的时间用来做GC，并且回收了不到2%的堆内存

为了更快的达到效果，我们首先需要设置JVM启动参数

-Xms10m -Xmx10m -XX:+PrintGCDetails -XX:MaxDirectMemorySize=5m
复制代码

异常出现的步骤就是，我们不断的像list中插入String对象，直到启动GC回收

public class GCOverheadLimitDemo {
  public static void main(String[] args) {
    int i = 0;
    List<String> list = new ArrayList<>();
    try {
      while(true) {
      //1.6时intern()方法发现字符串常量池(存储永久代)没有就复制,物理拷贝
      //1.7时intern()方法发现字符串常量池(存储堆)没有就在保存地址值映射实际堆内存对象
        list.add(String.valueOf(++i).intern());
      }
    } catch (Exception e) {
      System.out.println("***************i:" + i);
      e.printStackTrace();
      throw e;
    } finally {
    }
  }
}
复制代码

运行结果

[Full GC (Ergonomics) [PSYoungGen: 2047K->2047K(2560K)] [ParOldGen: 7106K->7106K(7168K)] 9154K->9154K(9728K), [Metaspace: 3504K->3504K(1056768K)], 0.0311093 secs] [Times: user=0.13 sys=0.00, real=0.03 secs] 
[Full GC (Ergonomics) [PSYoungGen: 2047K->0K(2560K)] [ParOldGen: 7136K->667K(7168K)] 9184K->667K(9728K), [Metaspace: 3540K->3540K(1056768K)], 0.0058093 secs] [Times: user=0.00 sys=0.00, real=0.01 secs] 
Heap
 PSYoungGen   total 2560K, used 114K [0x00000000ffd00000, 0x0000000100000000, 0x0000000100000000) eden space 2048K, 5% used [0x00000000ffd00000,0x00000000ffd1c878,0x00000000fff00000) from space 512K, 0% used [0x00000000fff80000,0x00000000fff80000,0x0000000100000000) to  space 512K, 0% used [0x00000000fff00000,0x00000000fff00000,0x00000000fff80000) ParOldGen    total 7168K, used 667K [0x00000000ff600000, 0x00000000ffd00000, 0x00000000ffd00000) object space 7168K, 9% used [0x00000000ff600000,0x00000000ff6a6ff8,0x00000000ffd00000) Metaspace    used 3605K, capacity 4540K, committed 4864K, reserved 1056768K class space  used 399K, capacity 428K, committed 512K, reserved 1048576KException in thread "main" java.lang.OutOfMemoryError: GC overhead limit exceeded  at java.lang.Integer.toString(Integer.java:403)  at java.lang.String.valueOf(String.java:3099)  at com.moxi.interview.study.oom.GCOverheadLimitDemo.main(GCOverheadLimitDemo.java:18)复制代码

我们能够看到多次Full GC，并没有清理出空间，在多次执行GC操作后，就抛出异常 GC overhead limit

Direct buffer memory

Netty + NIO：这是由于NIO引起的

NIO程序的时候经常会使用ByteBuffer来读取或写入数据，这是一种基于通道(Channel)与缓冲区(Buffer)的I/O方式，它可以使用Native函数库直接分配堆外内存
然后通过一个存储在Java堆里面的DirectByteBuffer对象作为这块内存的引用进行操作。这样能在一些场景中显著提高性能，因为避免了在Java堆和Native堆中来回复制数据。

ByteBuffer.allocate(capability)：第一种方式是分配JVM堆内存，属于GC管辖范围，由于需要拷贝所以速度相对较慢

ByteBuffer.allocteDirect(capability)：第二种方式是分配OS本地内存，不属于GC管辖范围，由于不需要内存的拷贝，所以速度相对较快

如果不断分配本地内存，堆内存很少使用，那么JVM就不需要执行GC，DirectByteBuffer对象就不会被回收，这时候堆内存充足，但本地内存可能已经使用光了，再次尝试分配本地内存就会出现OutOfMemoryError，那么程序就崩溃了。

一句话说：本地内存不足，但是堆内存充足的时候，就会出现这个问题

我们使用 -XX:MaxDirectMemorySize=5m 配置能使用的堆外物理内存为5M

-Xms20m -Xmx20m -XX:+PrintGCDetails -XX:MaxDirectMemorySize=5m
复制代码

然后我们申请一个6M的空间

// 只设置了5M的物理内存使用，但是却分配 6M的空间 ByteBuffer bb = ByteBuffer.allocateDirect(6 * 1024 * 1024); 这个时候，运行就会出现问题了

配置的maxDirectMemory：5.0MB

[GC (System.gc()) [PSYoungGen: 2030K->488K(2560K)] 2030K->796K(9728K), 0.0008326 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[Full GC (System.gc()) [PSYoungGen: 488K->0K(2560K)] [ParOldGen: 308K->712K(7168K)] 796K->712K(9728K), [Metaspace: 3512K->3512K(1056768K)], 0.0052052 secs] [Times: user=0.09 sys=0.00, real=0.00 secs] 
Exception in thread "main" java.lang.OutOfMemoryError: Direct buffer memory
  at java.nio.Bits.reserveMemory(Bits.java:693)
  at java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:123)
  at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:311)
  at com.moxi.interview.study.oom.DIrectBufferMemoryDemo.main(DIrectBufferMemoryDemo.java:19)
复制代码

unable to create new native thread

不能够创建更多的新的线程了，也就是说创建线程的上限达到了

在高并发场景的时候，会应用到

高并发请求服务器时，经常会出现如下异常java.lang.OutOfMemoryError:unable to create new native thread，准确说该 native thread 异常与对应的平台有关

导致原因：

应用创建了太多线程，一个应用进程创建多个线程，超过系统承载极限

服务器并不允许你的应用程序创建这么多线程，Linux系统默认运行单个进程可以创建的线程为1024个，如果应用创建超过这个数量，就会报 java.lang.OutOfMemoryError:unable to create new native thread

解决方法

想办法降低你应用程序创建线程的数量，分析应用是否真的需要创建这么多线程，如果不是，改代码将线程数降到最低
对于有的应用，确实需要创建很多线程，远超过linux系统默认1024个线程限制，可以通过修改linux服务器配置，扩大linux默认限制

public class UnableCreateNewThreadDemo {
  public static void main(String[] args) {
    for (int i = 0; ; i++) {
      System.out.println("************** i = " + i);
      new Thread(() -> {
        try {
          TimeUnit.SECONDS.sleep(Integer.MAX_VALUE);
        } catch (InterruptedException e) {
          e.printStackTrace();
        }
      }, String.valueOf(i)).start();
    }
  }
}
复制代码

这个时候，就会出现下列的错误，线程数大概在 900多个

Exception in thread "main" java.lang.OutOfMemoryError: unable to cerate new native thread
复制代码

如何查看线程数

ulimit -u
复制代码

Metaspace

元空间内存不足，Matespace元空间应用的是本地内存

-XX:MetaspaceSize 的初始化大小为20M

元空间是什么

元空间就是我们的方法区，存放的是类模板，类信息，常量池等

Metaspace是方法区HotSpot中的实现，它与持久代最大的区别在于：Metaspace并不在虚拟内存中，而是使用本地内存，也即在java8中，class metadata（the virtual machines internal presentation of Java class），被存储在叫做Metaspace的native memory

永久代（java8后背元空间Metaspace取代了）存放了以下信息：

虚拟机加载的类信息
常量池
静态变量
即时编译后的代码

模拟Metaspace空间溢出，我们不断生成类往元空间里灌输，类占据的空间总会超过Metaspace指定的空间大小

代码在模拟异常生成时候，因为初始化的元空间为20M，因此我们使用JVM参数调整元空间的大小，为了更好的效果

-XX:MetaspaceSize=8m -XX:MaxMetaspaceSize=8m
复制代码

代码如下：

public class MetaspaceOutOfMemoryDemo {
  // 静态类
  static class OOMTest {
  }
  public static void main(final String[] args) {
    // 模拟计数多少次以后发生异常
    int i =0;
    try {
      while (true) {
        i++;
        // 使用Spring的动态字节码技术
        Enhancer enhancer = new Enhancer();
        enhancer.setSuperclass(OOMTest.class);
        enhancer.setUseCache(false);
        enhancer.setCallback(new MethodInterceptor() {
          @Override
          public Object intercept(Object o, Method method, Object[] objects, MethodProxy methodProxy) throws Throwable {
            return methodProxy.invokeSuper(o, args);
          }
        });
      }
    } catch (Exception e) {
      System.out.println("发生异常的次数:" + i);
      e.printStackTrace();
    } finally {
    }
  }
}
复制代码

会出现以下错误：

发生异常的次数: 201

java.lang.OutOfMemoryError:Metaspace
复制代码

注意

在JDK1.7之前:永久代是方法区的实现，存放了运行时常量池、字符串常量池和静态变量等。

在JDK1.7:永久代是方法区的实现，将字符串常量池和静态变量等移出至堆内存。运行时常量池等剩下的还再永久代(方法区)

在JDK1.8及以后：永久代被元空间替代，相当于元空间实现方法区，此时字符串常量池和静态变量还在堆，运行时常量池还在方法区(元空间)，元空间使用的是直接内存。

-XX:MetaspaceSize=N//设置Metaspace的初始（和最小大小）

-XX:MaxMetaspaceSize=N//设置Metaspace的最大大小与永久代很大的不同就是，如果不指定大小的话，随着更多类的创建，虚拟机会耗尽所有可用的系统内存。

【JVM性能优化】服务发生OOM故障定位方案

前提概要

分析原因

排查方案

确认是不是内存本身就分配过小

找到最耗内存的对象

确认是否是资源耗尽

工具：

Java内存溢出OOM

StackoverFlowError

运行结果

OutOfMemoryError：java heap space

GC overhead limit exceeded

运行结果

Direct buffer memory

unable to create new native thread

导致原因：

解决方法

如何查看线程数

Metaspace

元空间是什么

代码如下：

注意

热门文章

最新文章

相关课程

相关电子书

热门

活动广场

任务中心

开发者评测

高校计划

乘风者计划

训练营

阿里云MVP

话题

直播

下载

镜像站

技术资料

插件

【JVM性能优化】服务发生OOM故障定位方案

前提概要

分析原因

排查方案

确认是不是内存本身就分配过小

找到最耗内存的对象

确认是否是资源耗尽

工具：

Java内存溢出OOM

StackoverFlowError

运行结果

OutOfMemoryError：java heap space

GC overhead limit exceeded

运行结果

Direct buffer memory

unable to create new native thread

导致原因：

解决方法

如何查看线程数

Metaspace

元空间是什么

代码如下：

注意

热门文章

最新文章

相关课程

相关电子书