前提概要

对于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 1048576K
Exception 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的最大大小与永恒代很大的不同就是，如果不指定大小的话，随着更多类的创立，虚构机会耗尽所有可用的零碎内存。

关于java:JVM性能优化服务发生OOM故障定位方案

前提概要

剖析起因

排查计划

确认是不是内存自身就调配过小

找到最耗内存的对象

确认是否是资源耗尽

工具：

Java内存溢出OOM

StackoverFlowError

运行后果

OutOfMemoryError：java heap space

GC overhead limit exceeded

运行后果

Direct buffer memory

unable to create new native thread

导致起因：

解决办法

如何查看线程数

Metaspace

元空间是什么

代码如下：

留神

评论

发表回复取消回复

更多文章

DDN HPC 存储硬件架构设计深度分析

探秘IO500：从Lustre并行文件系统出发，开启HPC存储性能新征程

苹果iOS打包的ipa应用无法安装？一篇文章带你了解可能的原因及排查方法

图解Golang：从零开始实现简易版过期LRU缓存

关于java:JVM性能优化服务发生OOM故障定位方案

前提概要

剖析起因

排查计划

确认是不是内存自身就调配过小

找到最耗内存的对象

确认是否是资源耗尽

工具：

Java内存溢出OOM

StackoverFlowError

运行后果

OutOfMemoryError：java heap space

GC overhead limit exceeded

运行后果

Direct buffer memory

unable to create new native thread

导致起因：

解决办法

如何查看线程数

Metaspace

元空间是什么

代码如下：

留神

评论

发表回复 取消回复

更多文章

DDN HPC 存储硬件架构设计深度分析

探秘IO500：从Lustre并行文件系统出发，开启HPC存储性能新征程

苹果iOS打包的ipa应用无法安装？一篇文章带你了解可能的原因及排查方法

图解Golang：从零开始实现简易版过期LRU缓存

发表回复取消回复