0
点赞
收藏
分享

微信扫一扫

当java程序出现oom如何解决,什么场景下会出现oom

OOM

oom就是我们常说的内存溢出,它是指需要的内存空间大于系统分配的内存空间,oomp的后果就是会使项目crash。

1、Java heap space

当堆内存(Heap Space)没有足够的空间存放新创建的对象时,这会就会抛出java.lang.OutOfMemoryError:Javaheap space 错误(可以根据实际中生产经验,可以把程序中的日志的OutOfMemoryError关键字设置为告警,当告警了就可以方便立即处理)。
出现的原因分析:
Java heap space错误产生的常见原因可以分为以下几方面:

  1. 请求创建一个超大的对象,通常是一个大的数据组;
  2. 超出预期的访问量或数据量,通常是上游的系统请求流量飙升,常见于各类的促销或秒杀活动,可以结合业务流量的指标来排查是否有尖状的峰值;
  3. 过渡使用终结器(Finalizer),该对象没有立即被GC;
  4. 内存的泄漏(Memory Leak),大量对象引用没有释放,JVM无法对其自动回收,常见于使用了File等资源没有回收。

解决的方案:
针对大部分情况,通常可以通过-Xmx 参数稍微调高点JVM堆内存空间就可以了,如果还是没解决的话,就可以尝试下面的情况来处理:

  1. 如果是超大对象的话,可以检查其合理性,比如是否一次性查询了数据库全部内容,而没有做内容的数量限制;
  2. 如果是业务的峰值压力,可以考虑添几件机器资源,或者限制流量;
  3. 如果是内存泄漏的话,需要找到持有的对象,修改代码设计,比如关闭没有释放的连接。

    2、GC overhead limit exceeded

    当Java进程花费8%以上的时间执行GC,但只恢复了不到2%的内存,且该动作连续重复了5次,就会抛出java.lang.OutOfMemoryError:GC overhead limit exceeded错误。简单地说,就是应用程序已经基本耗尽了所有可用内存,GC也无法回收。
    这类的问题原因和解决方法和上面Java heap space的差不多,可以参考上面的步骤试试。

    3、Permgen space

    该错误表示永久代(Permanent Generation)已用满,通常是因为加载的class数目太多或体积太大。
    出现的原因分析:
    永久代存储对象主要包括以下几类:

  4. 加载/缓存到内存中的 class 定义,包括类的名称,字段,方法和字节码;
  5. 常量池;
  6. 对象数组/类型数组所关联的 class;
  7. 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 https://www.eclipse.org/mat 功能逐一分析开销最大的 classloader 和重复 class。

4、Metaspace

JDK1.8使用Metaspace替换了永久代(Permanent Generation),该错误表示Metaspace已被用满,通常是因为加载的class数目太多或体积太大。
此类问题的原因与解决方法跟Permgenspace非常类似,可以参考上文。需要特别注意的是调整Metaspace空间大小的启动参数为-XX:MaxMetaspaceSize。

5、Unable to create new native thread

每个Java线程都需要占用一定的内存空间,当JVM向底层操作系统请求创建一个新的native线程时,如果没有足够的资源分配就会报此类错误。
出现的原因分析:
JVM向OS请求创建native线程失败,就会抛出Unableto createnewnativethread,常见的原因包括以下几类:

  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:Unableto createnewnativethread错误。

6、Out of swap space

该错误表示所有可用的虚拟内存已被耗尽。虚拟内存(Virtual Memory)由物理内存(Physical Memory)和交换空间(Swap Space)两部分组成。当运行时程序请求的虚拟内存溢出时就会报 Outof swap space? 错误。
出现的原因分析:
该错误出现的常见原因包括以下几类:

  1. 地址空间不足;
  2. 物理内存已耗光;
  3. 应用程序的本地内存泄漏(native leak),例如不断申请本地内存,却不释放。
  4. 执行jmap-histo:live命令,强制执行Full GC;如果几次执行后内存明显下降,则基本确认为Direct ByteBuffer问题。

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

  1. 升级地址空间为 64 bit;
  2. 使用 Arthas 检查是否为 Inflater/Deflater 解压缩问题,如果是,则显式调用 end 方法。
  3. Direct ByteBuffer 问题可以通过启动参数 -XX:MaxDirectMemorySize 调低阈值。
  4. 升级服务器配置/隔离部署,避免争用。

7、Kill process or sacrifice child

有一种内核作业(Kernel Job)名为Out of Memory Killer,它会在可用内存极低的情况下“杀死”(kill)某些进程。OOM Killer会对所有进程进行打分,然后将评分较低的进程“杀死”,具体的评分规则可以参考Surviving the Linux OOM Killer。
不同于其他的 OOM 错误, Killprocessorsacrifice child 错误不是由 JVM 层面触发的,而是由操作系统层面触发的。
出现的原因分析:
默认情况下,Linux 内核允许进程申请的内存总量大于系统可用内存,通过这种“错峰复用”的方式可以更有效的利用系统资源。
然而,这种方式也会无可避免地带来一定的“超卖”风险。例如某些进程持续占用系统内存,然后导致其他进程没有可用内存。此时,系统将自动激活 OOM Killer,寻找评分低的进程,并将其“杀死”,释放内存资源。
解决的方案:

  1. 升级服务器配置/隔离部署,避免争用。
  2. OOM Killer 调优。

8、Requested array size exceeds VM limit

JVM 限制了数组的最大长度,该错误表示程序请求创建的数组超过最大长度限制。
JVM 在为数组分配内存前,会检查要分配的数据结构在系统中是否可寻址,通常为 Integer.MAX_VALUE-2。
此类问题比较罕见,通常需要检查代码,确认业务是否需要创建如此大的数组,是否可以拆分为多个块,分批执行。

9、Direct buffer memory

Java允许应用程序通过Direct ByteBuffer直接访问堆外内存,许多高性能程序通过Direct ByteBuffer结合内存映射文件(Memory Mapped File)实现高速IO。
出现的原因分析:
Direct ByteBuffer的默认大小为64MB,一旦使用超出限制,就会抛出Directbuffer memory错误。
解决的方案:

  1. Java只能通过ByteBuffer.allocateDirect方法使用Direct ByteBuffer,因此,可以通过Arthas等在线诊断工具拦截该方法进行排查。
  2. 检查是否直接或间接使用了 NIO,如 netty,jetty 等。
  3. 通过启动参数 -XX:MaxDirectMemorySize 调整 Direct ByteBuffer 的上限值。
  4. 检查 JVM 参数是否有 -XX:+DisableExplicitGC 选项,如果有就去掉,因为该参数会使 System.gc() 失效。
  5. 检查堆外内存使用代码,确认是否存在内存泄漏;或者通过反射调用 sun.misc.Cleaner 的 clean() 方法来主动释放被 Direct ByteBuffer 持有的内存空间。
  6. 内存容量确实不足,升级配置。
举报
0 条评论