性能文章>JVM源码分析之临门一脚的OutOfMemoryError完全解读>

JVM源码分析之临门一脚的OutOfMemoryError完全解读原创

2年前
8540110

概述

OutOfMemoryError,说的是java.lang.OutOfMemoryError,是JDK里自带的异常,顾名思义,说的就是内存溢出,当我们的系统内存严重不足的时候就会抛出这个异常(PS:注意这是一个Error,不是一个Exception,所以当我们要catch异常的时候要注意哦),这个异常说常见也常见,说不常见其实也见得不多,不过作为Java程序员至少应该都听过吧,如果你对jvm不是很熟,或者对OutOfMemoryError这个异常了解不是很深的话,这篇文章肯定还是可以给你带来一些惊喜的,通过这篇文章你至少可以了解到如下几点:

  • OutOfMemoryError一定会被加载吗

  • 什么时候抛出OutOfMemoryError

  • 会创建无数OutOfMemoryError实例吗

  • 为什么大部分OutOfMemoryError异常是无堆栈的

  • 我们如何去分析这样的异常

OutOfMemoryError类加载

既然要说OutOfMemoryError,那就得从这个类的加载说起来,那这个类什么时候被加载呢?你或许会不假思索地说,根据java类的延迟加载机制,这个类一般情况下不会被加载,除非当我们抛出OutOfMemoryError这个异常的时候才会第一次被加载,如果我们的系统一直不抛出这个异常,那这个类将一直不会被加载。说起来好像挺对,不过我这里首先要纠正这个说法,要明确的告诉你这个类在jvm启动的时候就已经被加载了,不信你就执行java -verbose:class -version打印JDK版本看看,看是否有OutOfMemoryError这个类被加载,再输出里你将能找到下面的内容:

[Loaded java.lang.OutOfMemoryError from /Library/Java/JavaVirtualMachines/jdk1.7.0_79.jdk/Contents/Home/jre/lib/rt.jar]

这意味着这个类其实在vm启动的时候就已经被加载了,那JVM里到底在哪里进行加载的呢,且看下面的方法:

bool universe_post_init() {

    ...    // Setup preallocated OutOfMemoryError errors
    k = SystemDictionary::resolve_or_fail(vmSymbols::java_lang_OutOfMemoryError(), true, CHECK_false);
    k_h = instanceKlassHandle(THREAD, k);
    Universe::_out_of_memory_error_java_heap = k_h->allocate_instance(CHECK_false);
    Universe::_out_of_memory_error_metaspace = k_h->allocate_instance(CHECK_false);
    Universe::_out_of_memory_error_class_metaspace = k_h->allocate_instance(CHECK_false);
    Universe::_out_of_memory_error_array_size = k_h->allocate_instance(CHECK_false);
    Universe::_out_of_memory_error_gc_overhead_limit =
      k_h->allocate_instance(CHECK_false);
    Universe::_out_of_memory_error_realloc_objects = k_h->allocate_instance(CHECK_false);


    ...    if (!DumpSharedSpaces) {    // These are the only Java fields that are currently set during shared space dumping.
    // We prefer to not handle this generally, so we always reinitialize these detail messages.
    Handle msg = java_lang_String::create_from_str("Java heap space", CHECK_false);
    java_lang_Throwable::set_message(Universe::_out_of_memory_error_java_heap, msg());

    msg = java_lang_String::create_from_str("Metaspace", CHECK_false);
    java_lang_Throwable::set_message(Universe::_out_of_memory_error_metaspace, msg());
    msg = java_lang_String::create_from_str("Compressed class space", CHECK_false);
    java_lang_Throwable::set_message(Universe::_out_of_memory_error_class_metaspace, msg());

    msg = java_lang_String::create_from_str("Requested array size exceeds VM limit", CHECK_false);
    java_lang_Throwable::set_message(Universe::_out_of_memory_error_array_size, msg());

    msg = java_lang_String::create_from_str("GC overhead limit exceeded", CHECK_false);
    java_lang_Throwable::set_message(Universe::_out_of_memory_error_gc_overhead_limit, msg());

    msg = java_lang_String::create_from_str("Java heap space: failed reallocation of scalar replaced objects", CHECK_false);
    java_lang_Throwable::set_message(Universe::_out_of_memory_error_realloc_objects, msg());

    msg = java_lang_String::create_from_str("/ by zero", CHECK_false);
    java_lang_Throwable::set_message(Universe::_arithmetic_exception_instance, msg());    // Setup the array of errors that have preallocated backtrace
    k = Universe::_out_of_memory_error_java_heap->klass();
    assert(k->name() == vmSymbols::java_lang_OutOfMemoryError(), "should be out of memory error");
    k_h = instanceKlassHandle(THREAD, k);

    int len = (StackTraceInThrowable) ? (int)PreallocatedOutOfMemoryErrorCount : 0;
    Universe::_preallocated_out_of_memory_error_array = oopFactory::new_objArray(k_h(), len, CHECK_false);    for (int i=0; i<len; i++) {
      oop err = k_h->allocate_instance(CHECK_false);
      Handle err_h = Handle(THREAD, err);
      java_lang_Throwable::allocate_backtrace(err_h, CHECK_false);
      Universe::preallocated_out_of_memory_errors()->obj_at_put(i, err_h());
    }
    Universe::_preallocated_out_of_memory_error_avail_count = (jint)len;
  }

}

上面的代码其实就是在vm启动过程中加载了OutOfMemoryError这个类,并且创建了好几个OutOfMemoryError对象,每个OutOfMemoryError对象代表了一种内存溢出的场景,比如说Java heap space不足导致的OutOfMemoryError,抑或Metaspace不足导致的OutOfMemoryError,上面的代码来源于JDK8,所以能看到metaspace的内容,如果是JDK8之前,你将看到Perm的OutOfMemoryError,不过本文metaspace不是重点,所以不展开讨论,如果大家有兴趣,可以专门写一篇文章来介绍metsapce来龙去脉,说来这个坑填起来还挺大的。

能通过agent拦截到这个类加载吗

熟悉字节码增强的人,可能会条件反射地想到是否可以拦截到这个类的加载呢,这样我们就可以做一些譬如内存溢出的监控啥的,哈哈,我要告诉你的是NO WAY,因为通过agent的方式来监听类加载过程是在vm初始化完成之后才开始的,而这个类的加载是在vm初始化过程中,因此不可能拦截到这个类的加载,于此类似的还有java.lang.Object,java.lang.Class等。

为什么要在vm启动过程中加载这个类

这个问题或许看了后面的内容你会有所体会,先卖个关子。包括为什么要预先创建这几个实例对象后面也会解释。

何时抛出OutOfMemoryError

要抛出OutOfMemoryError,那肯定是有地方需要进行内存分配,可能是heap里,也可能是metsapce里(如果是在JDK8之前的会是Perm里),不同地方的分配,其策略也不一样,简单来说就是尝试分配,实在没办法就gc,gc还是不能分配就抛出异常。

不过还是以Heap里的分配为例说一下具体的过程:

正确情况下对象创建需要分配的内存是来自于Heap的Eden区域里,当Eden内存不够用的时候,某些情况下会尝试到Old里进行分配(比如说要分配的内存很大),如果还是没有分配成功,于是会触发一次ygc的动作,而ygc完成之后我们会再次尝试分配,如果仍不足以分配此时的内存,那会接着做一次full gc(不过此时的soft reference不会被强制回收),将老生代也回收一下,接着再做一次分配,仍然不够分配那会做一次强制将soft reference也回收的full gc,如果还是不能分配,那这个时候就不得不抛出OutOfMemoryError了。这就是Heap里分配内存抛出OutOfMemoryError的具体过程了。

OutOfMemoryError对象可能会很多吗

想象有这么一种场景,我们的代码写得足够烂,并且存在内存泄漏,这意味着系统跑到一定程度之后,只要我们创建对象要分配内存的时候就会进行gc,但是gc没啥效果,进而抛出OutOfMemoryError的异常,那意味着每发生此类情况就应该创建一个OutOfMemoryError对象,并且抛出来,也就是说我们会看到一个带有堆栈的OutOfMemoryError异常被抛出,那事实是如此吗?如果真是如此,那为什么在VM启动的时候会创建那几个OutOfMemoryError对象呢?

抛出异常的java代码位置需要我们关心吗

这个问题或许你仔细想想就清楚了,如果没想清楚,请在这里停留一分钟仔细想想再往后面看。

抛出OutOfMemoryError异常的java方法其实只是临门一脚而已,导致内存泄漏的不一定就是这个方法,当然也不排除可能是这个方法,不过这种情况的可能性真的非常小。所以你大可不必去关心抛出这个异常的堆栈。

既然可以不关心其异常堆栈,那意味着这个异常其实没必要每次都创建一个不一样的了,因为不需要堆栈的话,其他的东西都可以完全相同,这样一来回到我们前面提到的那个问题,为什么要在vm启动过程中加载这个类,或许你已经有答案了,在vm启动过程中我们把类加载起来,并创建几个没有堆栈的对象缓存起来,只需要设置下不同的提示信息即可,当需要抛出特定类型的OutOfMemoryError异常的时候,就直接拿出缓存里的这几个对象就可以了。

所以OutOfMemoryError的对象其实并不会太多,哪怕你代码写得再烂,当然,如果你代码里要不断new OutOfMemoryError(),那我就无话可说啦。

为什么我们有时候还是可以看到有堆栈的OutOfMemoryError

如果都是用jvm启动的时候创建的那几个OutOfMemoryError对象,那不应该再出现有堆栈的OutOfMemoryError异常,但是实际上我们偶尔还是能看到有堆栈的异常,如果你细心点的话,可能会总结出一个规律,发现最多出现4次有堆栈的OutOfMemoryError异常,当4次过后,你都将看到无堆栈的OutOfMemoryError异常。

这个其实在我们上面贴的代码里也有体现,最后有一个for循环,这个循环里会创建几个OutOfMemoryError对象,如果我们将StackTraceInThrowable设置为true的话(默认就是true的),意味着我们抛出来的异常正确情况下都将是有堆栈的,那根据PreallocatedOutOfMemoryErrorCount这个参数来决定预先创建几个OutOfMemoryError异常对象,但是这个参数除非在debug版本下可以被设置之外,正常release出来的版本其实是无法设置这个参数的,它会是一个常量,值为4,因此在jvm启动的时候会预先创建4个OutOfMemoryError异常对象,但是这几个异常对象的堆栈,是可以动态设置的,比如说某个地方要抛出OutOfMemoryError异常了,于是先从预存的OutOfMemoryError里取出一个(其他是预存的对象还有),将此时的堆栈填上,然后抛出来,并且这个对象的使用是一次性的,也就是这个对象被抛出之后将不会再次被利用,直到预设的这几个OutOfMemoryError对象被用完了,那接下来抛出的异常都将是一开始缓存的那几个无栈的OutOfMemoryError对象。

这就是我们看到的最多出现4次有堆栈的OutOfMemoryError异常及大部分情况下都将看到没有堆栈的OutOfMemoryError对象的原因。

如何分析OutOfMemoryError异常

既然看堆栈也没什么意义,那只能从提示上入手了,我们看到这类异常,首先要确定的到底是哪块内存何种情况导致的内存溢出,比如说是Perm导致的,那抛出来的异常信息里会带有Perm的关键信息,那我们应该重点看Perm的大小,以及Perm里的内容;如果是Heap的,那我们就必须做内存Dump,然后分析为什么会发生这样的情况,内存里到底存了什么对象,至于内存分析的最佳的分析工具自然是MAT啦,不了解的请google之。

点赞收藏
分类:标签:
你假笨

通过创新的技术肯定可以让这个世界变得更美好,让我们为技术而狂吧

请先登录,查看1条精彩评论吧
快去登录吧,你将获得
  • 浏览更多精彩评论
  • 和开发者讨论交流,共同进步

为你推荐

【译】一次Docker 中的 Java 内存消耗问题的排查之旅

【译】一次Docker 中的 Java 内存消耗问题的排查之旅

JVM 常见线上问题:CPU100%、内存泄露的问题排查

JVM 常见线上问题:CPU100%、内存泄露的问题排查

FullGC没及时处理,差点造成P0事故

FullGC没及时处理,差点造成P0事故

使用JDK中自带的JVM分析工具解决内存溢出问题

使用JDK中自带的JVM分析工具解决内存溢出问题

一文深入分析 ZGC

一文深入分析 ZGC

【全网首发】一次想不到的 Bootstrap 类加载器带来的 Native 内存泄露分析

【全网首发】一次想不到的 Bootstrap 类加载器带来的 Native 内存泄露分析

10
1