一般常见OOM的原因及其解决办法

350 阅读8分钟

文章转载公众号链接:mp.weixin.qq.com/s/VEUcsNxJw… 当JVM内存严重不足时,就会抛出java.lang.OutOfMemoryError错误。如下给出了常见的OOM原因及其方法。

 

一、 Java heap space

  当堆内存(Heap Space)没有足够空间存放新创建的对象时,就会抛出 Java.lang.OutOfMemoryError:  Javaheap space错误(根据网上经验,可以对程序日志中的OutOfMemoryError配置相关字段警告,已经发现,立即处理)。

  原因分析

Javaheap Space错误产生的常见原因主要可以分为下面几类:

  1、 请求创建一个超大对象,通常是一个大数组。

2、 超出预期的访问量(数据量),通常是上游系统请求流量大幅增多,常见各类促销或秒杀活动,可以结合业务流量指标排查是否有尖状峰值。

3、 过度使用终结器(Finalizer),该对象没有立即被GC。

4、 内存泄漏(Memory Leak),大量对象引用没有释放,JVM无法对其自动回收,常见于使用了File等资源没有回收。

解决方案

针对大部分情况,通常只需要通过 –Xmx参数调高JVM堆内存空间即可。如果仍没有解决,可以参考以下情况做进一步处理:

1、 如果是超大对象,可以检查其合理性,比如是否一次性查询了数据库全部结果,而没有做结果数目限制。

2、 如果是业务峰值压力,可以考虑添加机器资源,或者做限流降级。

3、 如果是内存泄漏,需要找到持有的对象,修改代码设计,比如关闭没有释放的连接。

 

二、 GC overhead limit exceeded

当Java进程花费98%以上的时间执行GC,但只恢复了不到2%的内存,且该动作连续重复了5次,就会抛出 java.lang.OutOfMemoryError : GC overhead limit exceeded错误。简单地说,就是应用程序已经基本耗尽了所有可用内存,GC也无法回收。

  此类问题的原因与解决方案跟Javaheap Space非常相似,可以参考上文。

  三、Permgen Space

该错误表示永久代(Permanent Generation)已用满,通常是因为加载的class数目太多或者体积太大。

原因分析

永久代 对象主要包括以下几类:

1、加载/缓存到内存中的class定义,包括类的名称,字段,方法和字节码;

2、常量池;

3、对象数组/类型数组所关联的class;

4、JIT编辑器优化后的class信息;

PermGen的使用量与加载到内存的class的数量/大小正相关。

解决方案

根据Permgen Space报错的时机,可以采用不同的解决方案,如下所示:

1、程序启动报错,修改 –XX: MaxPermSize启动参数,调大永久代内存;

2、应用重新部署时报错,很可能是应用重启,导致了多加载了多份class信息,只需重启JVM可以解决;

3、运行时报错,应用程序可能会动态创建大量class,而这些class的生命周期很短暂,但是JVM默认不会卸载class,可以设置 –XX:+CMSClassUnloadingEnabled和-XX:+UseConcMarkSweepGC 这两个参数允许JVM卸载class;

如果上述方法无法解决,可以通过jmap命令dump内存对象

Jmap-dump:format=b,file=dump,hprof,然后利用Eclipse MAT

www.eclipse.org/mat功能逐一分析开销最大的classloader和重复class。

  四、Metaspace

JDK1.8使用Metaspace替代了永久代(Permanent Generation),该错误表示Metaspace以被用满,通常是因为加载的class数目太多或体积太大。

此类问题的原因与解决方法跟Permgen Space非常类似, 可以参考上文。需要特别注意的是调整Meta Space空间大小的启动参数为 –XX:MaxMetaspaceSize。

五、Unable to create new native thread

每个Java线程都需要占用一定的内存空间,当JVM向底层操作系统请求创建一个新的native线程时,如果没有足够的资源分配就会报此类错误。

原因分析

JVM向OS请求创建native线程失败,就会 Unable to create native thread,常见的原因包括以下几类:

1、线程数超过操作系统最大线程数ulimit限制;

2、线程数超过Kernel.pid_max (只能重启);

3、native内存不足;

该问题发生的常见过程主要包括以下几步:

1、JVM内部的应用 请求创建一个新的Java线程;

2、JVM native方法代理了该次请求,并向操作系统请求创建一个native 线程;

3、操作系统尝试创建一个新的native线程并为其分配内存;

4、如果操作系统的虚拟内存已耗尽,或是受到32位进程的地址空间限制,操作系统就会拒绝本次native内存分配‘;

5、JVM将抛出 java.lang.OutOfMemoryError : Unable to create new native thread错误。

解决方案

1、升级配置,为机器提供更多的内存;

2、降低Java Heap Space大小;

3、修复应用程序的线程泄漏问题;

4、限制线程池大小;

5、使用 –Xss参数减少线程栈的大小;

6、调高OS层面的线程最大数:执行 ulimit-a查看最大线程数限制,使用ulimit –u xxx调整最大线程数限制。

Ulimit –a …省略部分内容…max user processes (-u) 16384

  六、Out of swap space?

该错误表示所有可用的虚拟内存已被耗尽。虚拟内存(Virtual Memory)由物理内存(Physical Memory)和交换空间(Swap Space)两部分组成。当运行时程序请求虚拟内存溢出时就会报 Out of swap space?错误。

原因分析

该错误出现的常见原因包括以下几类:

1、地址空间不足;

2、物理内存已耗光;

3、应用程序的本地内存泄漏(native leak),例如不断申请本地内存,却不释放。

4、执行jmap-histo: live命令,强制执行Full GC;如果几次执行后内存明显下降,则基本确认为 Direct ByteBuffer问题。

解决方案

根据错误原因可以采取如下解决方案:

1、升级地址空间为64bit;

2、使用Arthas检查是否为Inflater/Deflater解压缩问题,如果是,则显示调用end方法。

3、Direct ByteBuffer问题可以通过启动参数 –XX: MaxDirectMemorySize调低阈值。

4、升级服务器配置/隔离部署,避免争用。

  七、Kill process or sacrifice child

有一种内核作业(Kernel Job)名为Out of Memory Killer,它会在可用内存极低的情况下“杀死”(kill)某些进程。OOM Killer会对所有进程进行打分,然后将评分较低的进程“杀死”,具体的评分规则可以参考Surviving the Linux OOM Killera。

不同于其他的OOM错误,Kill process or sacrifice child错误不是由JVM层面触发的,而是由操作系统层面触发的。

原因分析

默认情况下,Linux内核允许进程申请的内存总量大于系统可用内存,通过这种”错峰复用”的方式可以更有效的利用系统资源。然而,这种方式也会无可避免地带来一定的“超卖”风险。例如某些进程持续 系统内存,然后导致其他进程没有可用内存。此时,系统将自动激活OOM Killer, 寻找评分低的进程,并将其“杀死”,释放内存资源。

解决方案

1、升级服务器配置/隔离部署,避免争用;

2、OOM Killer调优;

八、Requested array size exceeds VM limit

JVM 限制了数组的最大长度,该错误表示程序请求创建的数组超过最大长度限制。

JVM在为数组分配内存前,会检查要分配的数据结构在系统中是否可寻址,通常为Integer.MAX_VALUE-2。此类问题比较罕见,通常需要检查代码,确认业务是否需要创建如此大的数组,是否可以拆分为多个块,分批执行。

  九、Direct buffer memory

Java允许应程序通过Direct ByteBuffer直接访问堆外内存,许多高性能程序通过Direct ByteBuffer结合内存映射文件(Memory Mapped File)实现高速IO。

原因分析

Direct ByteBuffer的默认大小为64MB,一旦使用超出限制,就会抛出 Direct buffer memory错误。

解决方案

1、Java只能通过ByteBuffer.allocateDirect方法使用Direct ByteBuffer,因此,可以通过Arthas等在线诊断工具拦截该方法进行排查。

2、检查是否直接或间接使用了NIO,如netty,jetty等。

3、通过启动参数 –XX: MaxDirectMemorySize t调整Direct ByteBuffer的上限值。

4、检查JVM参数是否具有 –XX : +DisableExplicit GC选项,如果有就去掉,因为该参数会使System.gc()失效。

5、检查堆外内存使用代码,确认是否存在内存泄漏;或者通过反射调用sun.misc.Cleaner的clean()方法来主动释放被Direct ByteBuffer持有的内存空间。

6、内存空间确实不足,升级配置。

  推荐工具&产品

JVM内存分析工具 MAT

1、Eclipse Memory Analyzer

www.eclipse.org/mat

阿里云APM产品,支持OOM异常关键字告警

2、ARMS

help.aliyun.com/document_de…

阿里Java在线诊断工具Arthas(阿尔萨斯)

3、alibaba Arthas

github.com/alibaba/art…