©2020-2024 ioDraw All rights reserved,
Privacy Policy
某天报警：某台机器部署的一个服务突然无法访问。谨记第一反应登录机器查看日志，因为服务挂掉，很可能因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进程运行我们写好的系统的流程：
这次OOM是Jetty在使用堆外内存时导致。可推算得，Jetty可能在不停使用堆外内存，然后堆外内存空间不足，没法使用更多堆外内存，就OOM了。
Jetty不停使用堆外内存：
<>解决OOM的底层技术
Jetty既然是用Java写的，那他是如何通过Java代码申请堆外内存的？然后这个堆外内存空间又如何释放呢？这涉及Java的NIO底层。
JVM的性能优化相对还是较为容易一些的，但若是解决OOM，除了一些弱智和简单的，如有人在代码里不停创建对象。其他很多生产的OOM问题，都有点技术难度，需要扎实技术。
<>堆外内存是如何申请的，又是如何释放的？
如在Java代码里要申请使用一块堆外内存空间，是使用DirectByteBuffer这个类，你可以通过这个类构建一个DirectByteBuffer的对象，这个对象本身是在JVM堆内存里的。
但是你在构建这个对象的同时，就会在堆外内存中划出来一块内存空间跟这个对象关联起来，我们看看下面的图，你就对他们俩的关系很清楚了。
因此在分配堆外内存时，基本就这思路。
<>如何释放堆外内存
当你的DirectByteBuffer对象无人引用，成垃圾后，就会在某次YGC或Full GC时被回收。
只要回收一个DirectByteBuffer对象，就会释放其关联的堆外内存：
<>那为何还出现堆外内存溢出？
若你创建很多DirectByteBuffer对象，占了大量堆外内存，然后这些DirectByteBuffer对象还无GC线程来回收，那就不会释放呀！
当堆外内存都被大量DirectByteBuffer对象关联使用，若你再要使用额外堆外内存，就报内存溢出！何时会出现大量DirectByteBuffer对象一直存活，导致大量堆外内存无法释放？
还可能是系统高并发，创建过多DirectByteBuffer，占用大量堆外内存，此时再继续想要使用堆外内存，就会OOM！但该系统显然不是这种情况。
<>真正的堆外内存溢出原因
可以用jstat观察线上系统运行情况，同时根据日志看看一些请求的处理耗时，分析过往gc日志，还看了一下系统各个接口的调用耗时后，分析思路如下。
首先看接口调用耗时，系统并发量不高，但他每个请求处理较耗时，平均每个请求需1s。
然后jstat发现，随系统不停被调用，会一直创建各种对象，包括Jetty本身不停创建DirectByteBuffer对象去申请堆外内存空间，接着直到Eden满，就会触发YGC：
但往往在进行GC的一瞬间，可能有的请求还没处理完，此时就有不少DirectByteBuffer对象处于存活状态，还没被回收，当然之前不少DirectByteBuffer对象对应的请求可能处理完毕了，他们就可以被回收了。
此时肯定会有一些DirectByteBuffer对象以及一些其他的对象是处于存活状态的，就需转入Survivor区。记得该系统上线时，内存分配极不合理，就给了年轻代一两百M，老年代却给七八百M，导致年轻代中的Survivor只有10M。因此往往在YGC后，一些存活下的对象（包括了一些DirectByteBuffer）会超过10M，没法放入Survivor，直接进入Old：
于是反复的执行这样的过程，导致一些DirectByteBuffer对象慢慢进入Old，Old的DirectByteBuffer
对象越来越多，而且这些DirectByteBuffer都关联很多堆外内存：
这些老年代里的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，进而释放堆外内存。