前提概要

对于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/fdll /proc/9339/task

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

  • 0 -> 规范输出
  • 1 -> 规范输入
  • 2 -> 规范谬误输入
  • 3 -> socket(容易想到是监听端口)

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

所以,只有

ll /proc/${PID}/fd | wc -lll /proc/${PID}/task | wc -l (成果等同pstree -p | wc -l)

就能晓得过程关上的句柄数和线程数。

Java内存溢出OOM

JVM中常见的两个谬误

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

除此之外,还有以下的谬误

java.lang.StackOverflowErrorjava.lang.OutOfMemoryError:java heap spacejava.lang.OutOfMemoryError:GC overhead limit exceeededjava.lang.OutOfMemoryError:Direct buffer memoryjava.lang.OutOfMemoryError:unable to create new native threadjava.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引起的
  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的最大大小 与永恒代很大的不同就是,如果不指定大小的话,随着更多类的创立,虚构机会耗尽所有可用的零碎内存