快速定位Java 内存OOM的问题

Java服务出现了OOM(Out Of Memory)问题,总结了一些相对通用的方案,希望能帮助到Java技术栈的同学。

某Java服务(假设PID=10765)出现了OOM,最常见的原因为:

有可能是内存分配确实过小,而正常业务使用了大量内存

某一个对象被频繁申请,却没有释放,内存不断泄漏,导致内存耗尽

某一个资源被频繁申请,系统资源耗尽,例如:不断创建线程,不断发起网络连接

画外音:无非“本身资源不够”“申请资源太多”“资源耗尽”几个原因。

更具体的,可以使用以下工具逐一排查。

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

方法:jmap -heap 10765

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

二、找到最耗内存的对象

方法:jmap -histo:live 10765 | more

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

实例数

所占内存大小

类名

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

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

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

申请完资源后,未调用close()或dispose()释放资源

消费者消费速度慢(或停止消费了),而生产者不断往队列中投递任务,导致队列中任务累积过多

画外音:线上执行该命令会强制执行一次fgc。另外还可以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

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

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

/**
 * Java堆内存不足
 */
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%的堆内存

连续多次GC都只回收了不到2%的极端情况下,才会抛出。假设不抛出GC overhead limit 错误会造成什么情况呢?

那就是GC清理的这点内存很快会再次被填满,迫使GC再次执行,这样就形成了恶性循环,CPU的使用率一直都是100%,而GC却没有任何成果。

代码演示:

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

-Xms10m -Xmx10m -XX:+PrintGCDetails -XX:MaxDirectMemorySize=5m

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

/**
 * GC 回收超时
 * JVM参数配置: -Xms10m -Xmx10m -XX:+PrintGCDetails
 */
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),被存储在叫做Matespace的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的最大大小 与永久代很大的不同就是,如果不指定大小的话,随着更多类的创建,虚拟机会耗尽所有可用的系统内存。

以上为个人经验,希望能给大家一个参考,也希望大家多多支持我们。如有错误或未考虑完全的地方,望不吝赐教。

(0)

相关推荐

  • Java虚拟机内存区域划分详解

    在谈 JVM 内存区域划分之前,我们先来看一下 Java 程序的具体执行过程,我画了一幅图. Java 源代码文件经过编译器编译后生成字节码文件,然后交给 JVM 的类加载器,加载完毕后,交给执行引擎执行.在整个执行的过程中,JVM 会用一块空间来存储程序执行期间需要用到的数据,这块空间一般被称为运行时数据区,也就是常说的 JVM 内存. 所以,当我们在谈 JVM 内存区域划分的时候,其实谈的就是这块空间--运行时数据区. 大家应该对官方出品的<Java 虚拟机规范>有所了解吧?了解这个规范可

  • Java中的内存泄漏

    Java.Lang.OutOfMemoryError: Java Heap Space Java应用程序只允许使用有限的内存.此限制在应用程序启动期间指定.为了使事情更复杂,Java内存被分成两个不同的区域.这些区域称为永久生成区域(permgene和Permgen): 这些区域的大小是在Java虚拟机(JVM)启动期间设置的,可以通过指定JVM参数-Xmx和-XX:MaxPermSize进行定制.如果未显式设置大小,则将使用特定于平台的默认值. 这个java.lang.OutOfMemoryE

  • Java程序执行过程及内存机制详解

    本讲将介绍Java代码是如何一步步运行起来的,其中涉及的编译器,类加载器,字节码校验器,解释器和JIT编译器在整个过程中是发挥着怎样的作用.此外还会介绍Java程序所占用的内存是被如何管理的:堆.栈和方法区都各自负责存储哪些内容.最后用一小块代码示例来帮助理解Java程序运行时内存的变化. Java程序执行过程 步骤 1: 写源代码,源代码将以.java的文件格式保存在电脑硬盘中. 步骤 2: 编译器(compiler)检查是否存在编译期错误(例如缺少分号,关键字拼写错误等).若通过检测,编译器

  • 深入理解JVM之Java对象的创建、内存布局、访问定位详解

    本文实例讲述了深入理解JVM之Java对象的创建.内存布局.访问定位.分享给大家供大家参考,具体如下: 对象的创建 一个简单的创建对象语句Clazz instance = new Clazz();包含的主要过程包括了类加载检查.对象分配内存.并发处理.内存空间初始化.对象设置.执行ini方法等. 主要流程如下: 1. 类加载检查 JVM遇到一条new指令时,首先检查这个指令的参数是否能在常量池中定位到一个类的符号引用,并且检查这个符号引用代表的类是否已被加载.解析和初始化过.如果没有,那必须先执

  • 排查Java应用内存泄漏问题的步骤

    什么是内存泄漏 内存泄漏是指java应用的堆内存使用率持续升高,直至内存溢出. 内存泄漏的的原因可能有多种 分配给应用程序的内存本身过小.而应用的业务代码,确实需要生成大量的对象 代码bug,某些需要被回收的对象,由于代码bug,却持续的被引用,导致java虚拟机无法回收这些对象.从而撑爆内存 无论哪种内存泄露,我们的解决方法都是要定位到具体是什么对象,占用了大量内存,从而方便我们基于此进行代码分析,debug,找出代码问题. 而能够帮助我们实现这一目的的方式就是获取java应用的内存 dump

  • 详解Java中一维、二维数组在内存中的结构

    前言 我们知道在Java中数组属于引用数据类型,它整个数组的数组元素既可以是基本数据类型的(如 byte \ int \ short \ long \ float \ double \ char \ boolean 这些),也可以是引用数据类型的.当它的数组元素是基本数据类型时,这个数组就是一个一维数组:当它的数组元素是引用数据类型时,它就是一个多维数组.比如,在一个数组中它的某个元素值其实是一个一维数组,而其他不同的元素也各自包含了一个一维数组,我们就把这个包含很多个一维数组的数组叫做二维数组

  • Java内存释放实现代码案例

    先贴代码: StringBuilder dada = null; for(int i=0; i<1000; i++){ dada = new StringBuilder(); for(int j=0; j<1000; j++){ dada.append("FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF"); } } System.out.println("释放前"); StringBuilder dad

  • windows java.exe内存暴涨解决、idea跑java\ tomcat内存无限增长

    最近突然遇到个问题:用 idea 跑 Tomcat 服务,不到30分钟 内存就吃完了.用任务管理器查看,发现 java.exe占了10G内存!! 查了各种方法 一. idea Tomcat 配置 没用!!! 二.idea idea64.exe.vmoptions 安装目录下的 bin 下的 idea64.exe.vmoptions 配置,还是 C:\Users\Administrator\.IntelliJIdea2019.1\config 下的 idea64.exe.vmoptions 配置

  • JAVA内存模型和Happens-Before规则知识点讲解

    我们在本篇内容里聊一聊JAVA的内存模型和Happens-Before规则. JAVA内存模型 这里的JAVA内存模型指的不是我们JVM专栏中提到的内存分布模型,而是针对并发编程的,小伙伴们不要混淆概念了. 我们已经知道,导致可见性问题的是缓存,导致有序性问题的是指令重排,那么禁用缓存和禁用指令重排不就可以避免出现这两种问题了吗. 但想想也知道,如果直接禁用掉,性能会大打折扣,所以正确的方式应该是按需禁用. 只有程序员才能分析出什么时候应该禁用,所以为了解决可见性和有序性,其实只要提供给程序员按

  • java使用内存数据库ssdb的步骤

    看这篇文章的同学,redis相信你一定很熟悉了,ssdb是一个功能类似于redis,性能稍弱于redis的高性能数据库,主要是可以使用磁盘代替内存,使得小内存可以胜任请求不高的大部分场景,从而节约资源.ssdb官方是这样评价的 : 一个高性能的支持丰富数据结构的 NoSQL 数据库, 用于替代 Redis. 1. 特性 替代 Redis 数据库, Redis 的 100 倍容量 LevelDB 网络支持, 使用 C/C++ 开发 Redis API 兼容, 支持 Redis 客户端 适合存储集合

  • Java 内存溢出的原因和解决方法

    你是否遇到过Java应用程序卡顿或突然崩溃的情况?您可能遇到过Java内存泄漏.在本文中,我们将深入研究Java内存泄漏的确切原因,并推荐一些最好的工具来防止内存泄漏发生. 什么是JAVA内存泄漏? 简单地说,Java内存泄漏是指对象不再被应用程序使用,而是在工作内存中处于活动状态. 在Java和大多数其他编程语言中,垃圾收集器的任务是删除不再被应用程序引用的对象.如果不选中,这些对象将继续消耗系统内存,并最终导致崩溃.有时java内存泄漏崩溃不会输出错误,但通常错误会以java.lang.Ou

  • 详解Java对象的内存布局

    前言 今天来讲些抽象的东西 -- 对象头,因为我在学习的过程中发现很多地方都关联到了对象头的知识点,例如JDK中的 synchronized锁优化 和 JVM 中对象年龄升级等等.要深入理解这些知识的原理,了解对象头的概念很有必要,而且可以为后面分享 synchronized 原理和 JVM 知识的时候做准备. 对象内存构成 Java 中通过 new 关键字创建一个类的实例对象,对象存于内存的堆中并给其分配一个内存地址,那么是否想过如下这些问题: 这个实例对象是以怎样的形态存在内存中的? 一个O

  • Java运行Jar包内存配置的操作

    如下: java -jar -Xms1024m -Xmx1536m -XX:PermSize=128M -XX:MaxPermSize=256M car.jar 说明: 1.堆内存: 最小1024M,最大1536M.(对象使用的内存) 2.永久内存: 最小128M,最大256M.(类使用的内存,PermGen) 补充:JAVA -JAR 运行SPRINGBOOT项目时内存设置 java -Xms64m #JVM启动时的初始堆大小 -Xmx128m #最大堆大小 -Xmn64m #年轻代的大小,其

  • 浅析JAVA中的内存结构、重载、this与继承

    一.对象在JVM的内存结构 JAVA内存管理由JVM来管理. 1)堆,所有new出来的对象(包括成员变量) 2)栈,所有局部变量(包括方法的参数) 3)方法区,class字节码文件(包括方法,静态数据) 1.引用变量指向null时,会发生空指针异常 public class student { int age; String name; public student(int age,String name){ this.age=age; this.name=name; } public stat

  • java应用占用内存过高排查的解决方案

    故障:收到服务器报警,内存使用率超过80% 1.查看 使用dstat和top查看内存使用最高的应用 使用dstat 查到内存占用最高的是java应用,使用2253M内存,但是这台服务器跑了好几个java,具体哪个进程使用top看下资源情况 使用top 可以看到java应用整体内存使用率超过了70%,其中pid为16494的进程 一个应用占了28.7的内存 2.定位线程问题 使用ps查看16494的线程情况 命令:ps p 16494 -L -o pcpu,pmem,pid,tid,time,tn

  • java 进程是如何在Linux服务器上进行内存分配的

    众所周知,Java进程在启动的时候我们可以通过 -Xms 和-Xmx来设置内存的上限和下限.直到我发现使用top命令监控的Java进程在-Xms设置4g的情况下占用的内存并不是4g,这就产生了一个疑问Linux服务器的内存到底是如何进行分配的. 于是乎,我查阅了一些知乎,课程以及Linux相关的书籍.这里分享并记录的一下相关的知识. 在Linux上运行的进程不仅限于Java.都有一个概念,逻辑内存(Logic Memory),而物理机真是持有的内存,我们称为 物理内存(Physic Memory

随机推荐