当前位置: 首页>编程语言>正文

Java NIO为何导致堆外内存OOM了?

Java NIO为何导致堆外内存OOM了?

描述

  • 某天报警:某台机器部署的一个服务突然无法访问。谨记第一反应登录机器查看日志,因为服务挂掉,很可能因OOM。这个时候在机器的日志中发现了如下的一些信息:
nio handle failed java.lang.OutOfMemoryError: Direct buffer memory at org.eclipse.jetty.io.nio.xxxx
at org.eclipse.jetty.io.nio.xxxx at org.eclipse.jetty.io.nio.xxxx
  • 表明确实为OOM,问题是哪个区导致的呢?可以看到是:Direct buffer memory,还看到一大堆jetty相关方法调用栈,仅凭这些日志,就能分析OOM原因。

Direct buffer memory

  • 堆外内存,JVM堆内存之外的一块内存,不是由JVM管理,但Java代码却能在JVM堆外使用一些内存空间。这些空间就是Direct buffer memory,即直接内存,这块内存由os直接管理。但称其为直接内存有些奇怪,我没更爱称其为“堆外内存”。
  • Jetty作为JVM进程运行我们写好的系统的流程:

Java NIO为何导致堆外内存OOM了?,Java NIO为何导致堆外内存OOM了?_服务器,第1张

  • 这次OOM是Jetty在使用堆外内存时导致。可推算得,Jetty可能在不停使用堆外内存,然后堆外内存空间不足,没法使用更多堆外内存,就OOM了。
  • Jetty不停使用堆外内存:

Java NIO为何导致堆外内存OOM了?,Java NIO为何导致堆外内存OOM了?_运维_02,第2张

解决OOM的底层技术

  • Jetty既然是用Java写的,那他是如何通过Java代码申请堆外内存的?然后这个堆外内存空间又如何释放呢?这涉及Java的NIO底层。
  • JVM的性能优化相对还是较为容易一些的,但若是解决OOM,除了一些弱智和简单的,如有人在代码里不停创建对象。其他很多生产的OOM问题,都有点技术难度,需要扎实技术。

堆外内存是如何申请的,又是如何释放的?

  • 如在Java代码里要申请使用一块堆外内存空间,是使用DirectByteBuffer这个类,你可以通过这个类构建一个DirectByteBuffer的对象,这个对象本身是在JVM堆内存里的。
  • 但是你在构建这个对象的同时,就会在堆外内存中划出来一块内存空间跟这个对象关联起来,我们看看下面的图,你就对他们俩的关系很清楚了。

Java NIO为何导致堆外内存OOM了?,Java NIO为何导致堆外内存OOM了?_java_03,第3张

  • 因此在分配堆外内存时,基本就这思路。

如何释放堆外内存

  • 当你的DirectByteBuffer对象无人引用,成垃圾后,就会在某次YGC或Full GC时被回收。
  • 只要回收一个DirectByteBuffer对象,就会释放其关联的堆外内存:

Java NIO为何导致堆外内存OOM了?,Java NIO为何导致堆外内存OOM了?_运维_04,第4张

那为何还出现堆外内存溢出?

  • 若你创建很多DirectByteBuffer对象,占了大量堆外内存,然后这些DirectByteBuffer对象还无GC线程来回收,那就不会释放呀!
  • 当堆外内存都被大量DirectByteBuffer对象关联使用,若你再要使用额外堆外内存,就报内存溢出!何时会出现大量DirectByteBuffer对象一直存活,导致大量堆外内存无法释放?
  • 还可能是系统高并发,创建过多DirectByteBuffer,占用大量堆外内存,此时再继续想要使用堆外内存,就会OOM!但该系统显然不是这种情况。

真正的堆外内存溢出原因

  • 可以用jstat观察线上系统运行情况,同时根据日志看看一些请求的处理耗时,分析过往gc日志,还看了一下系统各个接口的调用耗时后,分析思路如下。
  • 首先看接口调用耗时,系统并发量不高,但他每个请求处理较耗时,平均每个请求需1s。
  • 然后jstat发现,随系统不停被调用,会一直创建各种对象,包括Jetty本身不停创建DirectByteBuffer对象去申请堆外内存空间,接着直到Eden满,就会触发YGC:

Java NIO为何导致堆外内存OOM了?,Java NIO为何导致堆外内存OOM了?_运维_05,第5张

  • 但往往在进行GC的一瞬间,可能有的请求还没处理完,此时就有不少DirectByteBuffer对象处于存活状态,还没被回收,当然之前不少DirectByteBuffer对象对应的请求可能处理完毕了,他们就可以被回收了。
  • 此时肯定会有一些DirectByteBuffer对象以及一些其他的对象是处于存活状态的,就需转入Survivor区。记得该系统上线时,内存分配极不合理,就给了年轻代一两百M,老年代却给七八百M,导致年轻代中的Survivor只有10M。因此往往在YGC后,一些存活下的对象(包括了一些DirectByteBuffer)会超过10M,没法放入Survivor,直接进入Old:

Java NIO为何导致堆外内存OOM了?,Java NIO为何导致堆外内存OOM了?_java_06,第6张

  • 于是反复的执行这样的过程,导致一些DirectByteBuffer对象慢慢进入Old,Old的DirectByteBuffer 对象越来越多,而且这些DirectByteBuffer都关联很多堆外内存:

Java NIO为何导致堆外内存OOM了?,Java NIO为何导致堆外内存OOM了?_服务器_07,第7张

  • 这些老年代里的DirectByteBuffer其实很多都是可以回收的状态了,但是因为老年代一直没塞满,所以没触发full gc,也就自然不会回收老年代里的这些DirectByteBuffer了!当然老年代里这些没有被回收的DirectByteBuffer就一直关联占据了大量的堆外内存空间了!
  • 直到最后,当你要继续使用堆外内存时,所有堆外内存都被老年代里大量的DirectByteBuffer给占用了,虽然他们可以被回收,但是无奈因为始终没有触发老年代的full gc,所以堆外内存也始终无法被回收掉。最后导致OOM!

这Java NIO怎么看起来这么沙雕?

  • Java NIO没考虑过会发生这种事吗?
  • 考虑了!他知道可能很多DirectByteBuffer对象也许没人用了,但因未触发gc就导致他们一直占据堆外内存。Java NIO做了如下处理,每次分配新的堆外内存时,都调用System.gc(),提醒JVM主动执行以下GC,去回收掉一些垃圾没人引用的DirectByteBuffer对象,释放堆外内存空间。
  • 只要能触发GC去回收掉一些没人引用的DirectByteBuffer,就会释放一些堆外内存,自然就可以分配更多对象到堆外内存。但因为我们又在JVM设置了:
-XX:+DisableExplicitGC
  • 导致这System.gc()不生效,因此导致OOM。

终极优化

  • 项目有如下问题:
  • 内存设置不合理,导致DirectByteBuffer对象一直慢慢进入老年代,堆外内存一直无法释放
  • 设置了-XX:+DisableExplicitGC,导致Java NIO无法主动提醒去回收掉一些垃圾DIrectByteBuffer对象,也导致了无法释放堆外内存
  • 对此就该:
  • 合理分配内存,给年轻代更多内存,让Survivor区域有更大的空间
  • 放开-XX:+DisableExplicitGC这个限制,让System.gc()生效
  • 优化后,DirectByteBuffer一般就不会不断进入老年代了。只要他停留在年轻代,随着young gc就会正常回收释放堆外内存了。
  • 只要放开-XX:+DisableExplicitGC限制,Java NIO发现堆外内存不足了,自然会通过System.gc()提醒JVM去主动垃圾回收,回收掉一些DirectByteBuffer,进而释放堆外内存。


https://www.xamrdz.com/lan/5x21939515.html

相关文章: