Sun JDK OOM
jvm jvm, oom, sun jdk oom No Comments
Java的自动内存管理机制给开发人员带来了很多的便利,在设计、开发时可以完全不用考虑要分配多少内存,要记得回收内存等,但同时也带来了各种各样的问题,其中最典型的问题就是OOM,大部分Java开发人员估计都看到过java.lang.OutOfMemoryError这样的错误信息,在这篇文章中,就来介绍下Sun JDK中有哪几种OOM、OOM示例、造成OOM的原因的查找、解决以及Sun JDK代码中处理OOM的方式。
PDF版本请从此下载:http://blog.bluedavy.com/open/Sun-JDK-OOM.pdf
1 OOM的种类
在Sun JDK中运行时,Java程序有可能出现如下几种OOM错误:
l java.lang.OutOfMemoryError: unable to create new native thread
当调用new Thread时,如已创建不了线程了,则会抛出此错误,如果是JDK内部必须创建成功的线程,那么会造成Java进程退出,如果是用户线程,则仅抛出OOM,创建不了的原因通常是创建了太多线程,耗尽了内存,通常可通过减少创建的线程数,或通过-Xss调小线程所占用的栈大小来减少对Java 对外内存的消耗。
l java.lang.OutOfMemoryError: request bytes for . Out of swap space?
当JNI模块或JVM内部进行malloc操作(例如GC时做mark)时,需要消耗堆外的内存,如此时Java进程所占用的地址空间超过限制(例如windows: 2G,linux: 3G),或物理内存、swap区均使用完毕,那么则会出现此错误,当出现此错误时,Java进程将会退出。
l java.lang.OutOfMemoryError: Java heap space
这是最常见的OOM错误,当通过new创建对象或数组时,如Java Heap空间不足(新生代不足,触发minor GC,还是不够,触发Full GC,还是不够),则抛出此错误。
l java.lang.OutOfMemoryError: GC overhead limit execeeded
当通过new创建对象或数组时,如Java Heap空间不足,且GC所使用的时间占了程序总时间的98%,且Heap剩余空间小于2%,则抛出此错误,以避免Full GC一直执行,可通过UseGCOverheadLimit来决定是否开启这种策略,可通过GCTimeLimit和GCHeapFreeLimit来控制百分比。
l java.lang.OutOfMemoryError: PermGen space
当加载class时,在进行了Full GC后如PermGen空间仍然不足,则抛出此错误。
对于以上几种OOM错误,其中容易造成严重后果的是Out of swap space这种,因为这种会造成Java进程退出,而其他几种只要不是在main线程抛出的,就不会造成Java进程退出。
2 OOM示例、原因查找和解决
这些示例的class以及源码请从http://blog.bluedavy.com/jvm/cases/oom/OOMCases.zip下载,建议在运行前不要看源码,毕竟源码是简单的例子,如果直接看源码的话,可能会少了查找原因的乐趣。
当Java程序运行时,会有很多种造成OOM的现象,这里面有些会比较容易查找出原因,而有些会非常困难,下面是来看一些OOM的Example。
l Example 1
以-Xms20m -Xmx20m -Xmn10m -XX:+UseParallelGC参数运行com.bluedavy.oom.JavaHeapSpaceCase1
运行后在输出的日志中可看到大量的Full GC信息,以及:
java.lang.OutOfMemoryError: GC overhead limit exceeded
和java.lang.OutOfMemoryError: Java heap space
根据上面所说的OOM种类,可以知道这是在new对象或数组时Java Heap Space不足造成的,对于这种OOM,需要知道的是程序中哪些部分占用了Java Heap。
要知道程序中哪些部分占用了Java Heap,首先必须拿到Java Heap中的信息,尤其是OOM时的内存信息,在Sun JDK中可通过在启动参数上加上-XX:+ HeapDumpOnOutOfMemoryError来获得OOM时的Java Heap中的信息,当出现OOM时,会自动生成一个java_pid[pid].hprof的文件。
于是在启动参数上加上上面的参数,再次运行JavaHeapSpaceCase1,可看到在当前运行的路径下生成了一个java_pid10852.hprof(由于pid不同,你看到的可能是不一样的文件名)的文件,在拿到这个文件后,就可通过mat(http://www.eclipse.org/mat/)来进行分析了。
用mat打开上面的文件(默认情况下mat认为heap dump文件应以.bin结尾,因此请改名或以open file方式打开),打开后点击dominator_tree,可看到sun.misc.Launcher$AppClassLoader占据了大部分的内存,继续点开看,则可看到是由于com.bluedavy.oom.Caches中有一个ArrayList,其中存放的对象占据了大部分的内存,因此解决这个OOM的办法是,让Caches类中放的对象总大小是有限制的,或者限制放入Caches的ArrayList中的对象个数。
这种情况造成的OOM,在实际的场景中当使用缓存时很容易产生,对于所有的缓存、集合大小都应给定限制的最大大小,以避免出现缓存或集合太大,导致消耗了过多的内存,从而导致OOM。
l Example 2
以-Xms20m -Xmx20m -Xmn10m -XX:+HeapDumpOnOutOfMemoryError执行com.bluedavy.oom.JavaHeapSpaceCase2
运行后在输出的日志中可看到大量的Full GC和java.lang.OutOfMemoryError: Java heap space。
同样,首先用mat打开需要分析的hprof文件,很惊讶的发现什么都看不出来,Java Heap Space还很充足,这就奇怪了,还好除了能在OOM时自动dump出Heap的信息外,还可通过jmap命令手工dump,于是,在运行期出现频繁Full GC、OOM的时候,手工通过jmap –dump:file=heap.bin,format=b [pid]生成一个heap.bin文件,把这个heap.bin文件也拿到mat中分析,杯具,还是什么都看不出来,还好,还有一招,就是直接用jmap –histo看看到底什么对象占用了大多数的内存,执行一次,看到[I占用了最多的内存,没用,因为没法知道这个[I到底是代码中哪个部分创建的,不甘心,多执行几次,很幸运,突然看到com.bluedavy.oom.Case2Object占据了最大的内存,于是查找代码中哪些地方创建了这个对象,发现了代码中有一个线程创建了大量的Case2Object,修改即可。
从这个例子中,可以看到,在分析OOM问题时,一方面是依赖OOM时dump出来的文件,但这个文件其实只会在Java进程中第一次出现OOM时生成,之后再OOM就不会生成了,这有可能出现真实的OOM的原因被假的OOM原因给掩盖掉;另一方面是依赖在出现OOM时的人工操作,这种人肉方式其实比较杯具,因为只能先等到频繁Full GC、OOM,首先通过jmap –histo来看看到底什么对象占用了大部分的内存(需要多执行几次,以确保正确性),上面的例子比较幸运,因为刚好是自定义的对象,如果是原生的类型,那就只能借助dump文件来分析了,通过jmap –dump手工dump出Heap文件,然后用MAT分析,但有可能会出现上面例子中的状况,就是mat分析上也看不出什么,顶多只能看到unreachable objects里某些对象占用了大部分的内存,而通常情况看到的可能都是原生类型,一旦真的碰到jmap –histo看到的是原生类型占用较多,jmap dump看到的是Java Heap Space也不满的话,那只能说杯具了,在这种情况下,唯一能做的是捕捉所有的异常,然后打印,从而判断OOM是在哪行代码抛出的。
l Example 3
以-Xms20m -Xmx20m -Xmn10m -XX:+HeapDumpOnOutOfMemoryError执行com.bluedavy.oom.JavaHeapSpaceCase3
在控制台中可看到大量的java.lang.OutOfMemoryError: Java heap space,把生成的hprof文件放入MAT中进行分析,还好看到确实是Java Heap Space满了,这就好办了,点开Dominator Tree视图,可看到有一堆的线程,每个都占用了一定的内存,从而导致了OOM,要解决这个例子中的OOM,有四种办法:一是减少处理的线程数;二是处理线程需要消耗的内存;三是提升线程的处理速度;四是增加机器,减少单台机器所需承担的请求量。
上面这种状况在系统处理慢的时候比较容易出现。
l Example 4
以-Xms20m -Xmx20m -Xmn10m -XX:+HeapDumpOnOutOfMemoryError执行com.bluedavy.oom.JavaHeapSpaceCase4
在控制台可看到大量的java.lang.OutOfMemoryError: Java heap space,把生成的hprof文件放入MAT中进行分析,可看到TaskExecutor中的handlers占据了大量的内存,分析代码,发现是由于在task处理完后没有清除掉对应的handler造成的,修改即可解决此OOM问题。
这是个典型的内存泄露的例子,如果不小心持有了本应释放引用的对象,那么就会造成内存泄露,这是在编写Java程序时需要特别注意的地方。
l Example 5
以-Xms1536m -Xmx1536m -Xss100m执行com.bluedavy.oom.CannotCreateThreadCase
在控制台可看到java.lang.OutOfMemoryError: unable to create new native thread。
对于这种情况,一需要查看目前-Xss的大小,例如在这个例子中-Xss太大,导致连20个线程都无法创建,因此可解决的方法是降低-Xss的大小;如果Xss使用的是默认值,那么可通过jstack来查看下目前Java进程中是不是创建了过多的线程,或者是java heap太大,导致os没剩多少内存,从而创建不出线程。
l Example 6
Out of swap的例子实在太难举了,就没在此列出了,对于Out of swap的OOM,需要首先观察是否因为Java Heap设置太大,导致物理内存+swap区不够用;如果不是的话,则需关注到底是哪些地方占用了堆外的内存,可通过google-perftools来跟踪是哪些代码在调用malloc,以及所耗的内存比例,在跟踪到后可继续查找原因。
总体来说,Out of swap通常是最难查的OOM,由于其是直接退出java进程的,因此需要结合core dump文件和hs_err_pid[pid].log进行分析,最关键的还是像查java heap那样,要查出到底是什么代码造成了native heap的消耗。
l Example 7
PermGen空间满造成OOM的情况通常采取的解决方法是简单的扩大PermSize。
总结上面的例子来看,对于OOM的情况,最重要的是根据OOM的种类查找到底是代码中的什么部分造成的消耗。
对于Java Heap Space OOM和GC overhead limit exceeded这两种类型,可通过heap dump文件以及jmap –histo来进行分析,多数情况下可通过heap dump分析出原因,但也有少数情况会出现heap dump分析不出原因,而jmap –histo看到某原生类型占据了大部分的内存,这种情况就非常复杂了,只能是仔细查看代码,并捕捉OutOfMemoryError,从而来逐渐定位到代码中哪部分抛出的。
对于Out of swap这种类型,其主要是地址空间超过了限制或者对外内存不够用了造成的,首先需要查看Java Heap设置是否过大,然后可结合google-perftools来查看到底是哪些代码调用了malloc,在堆外分配内存。
3 Sun JDK代码中处理OOM的方式
在Sun JDK代码中,在不同的OOM时,会调用不同的处理方式来进行处理,下面就来看看JDK中几个典型的处理OOM的代码。
l 创建线程失败
compiler_thread = new CompilerThread(queue, counters);
if (compiler_thread == NULL || compiler_thread->osthread() == NULL){
vm_exit_during_initialization(“java.lang.OutOfMemoryError”,
“unable to create new native thread”);
}
对于JDK中必须创建成功的线程,如失败会通过调用vm_exit_during_initialization打印出OOM错误,并退出Java进程。
对于非必须创建成功的线程,通常会调用
THROW_MSG(vmSymbols::java_lang_OutOfMemoryError(),
“unable to create new native thread”);
抛出OOM错误信息。
l 调用os:malloc失败
void *p = os::malloc(bytes);
if (p == NULL)
vm_exit_out_of_memory(bytes, “Chunk::new”);
return p;
当os:malloc或os:commit_memory失败时,会直接输出错误信息,并退出Java进程。
l Java Heap上分配失败后
report_java_out_of_memory(“Java heap space”);
调用这个就表明了不会退出vm,而只是抛出OOM错误。
例如PermGen分配失败时的代码更为直观:
HeapWord* result = Universe::heap()->permanent_mem_allocate(size);
if (result != NULL) {
NOT_PRODUCT(Universe::heap()->
check_for_non_bad_heap_word_value(result, size));
assert(!HAS_PENDING_EXCEPTION,
“Unexpected exception, will result in uninitialized storage”);
return result;
}
// -XX:+HeapDumpOnOutOfMemoryError and -XX:OnOutOfMemoryError support
report_java_out_of_memory(“PermGen space”);
总体而言,对于一个大型系统而言,通常OOM是难以避免的现象,最重要的还是一旦出现OOM,要掌握排查的方法,另外就是,随着现在内存越来越便宜,CMS GC越来越成熟,采用64 bit操作系统,开启大内存也是一种可选方式,基本上可以避免内存成为大问题,毕竟在Java中完全可能随便写几行代码就不知不觉消耗了很多内存。
ps: 感兴趣的同学还可参考sun官方的这篇关于OOM的文章:
http://java.sun.com/javase/6/webnotes/trouble/TSG-VM/html/memleaks.html