前提概要

对于 JVM 服务而言呈现了 OOM(Out Of Memory)问题，并且对其进行相干的解决是作为一个 Java 技术栈人员必备的实战能力。在此总结了一些绝对通用的计划，心愿能帮忙到大家。

剖析起因

某 Java 服务呈现了 OOM，最常见的起因为：

1. 有可能是内存调配的确过小，而失常业务应用了大量内存（失常景象）
2. 某一个对象被频繁申请，却没有开释，内存一直透露，导致内存耗尽（内存透露、代码问题）
3. 某一个资源被频繁申请，系统资源耗尽，例如：一直创立线程，一直发动网络连接（线程一直创立、代码问题）

排查计划

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

办法：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 引起的

1. NIO 程序的时候常常会应用 ByteBuffer 来读取或写入数据，这是一种基于通道 (Channel) 与缓冲区 (Buffer) 的 I / O 形式，它能够应用 Native 函数库间接调配堆外内存
2. 而后通过一个存储在 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 的最大大小 与永恒代很大的不同就是，如果不指定大小的话，随着更多类的创立，虚构机会耗尽所有可用的零碎内存。